[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Setting cursor-type does not trigger redisplay of cursor
From: |
Kim F. Storm |
Subject: |
Re: Setting cursor-type does not trigger redisplay of cursor |
Date: |
Thu, 10 Nov 2005 09:30:24 +0100 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) |
"Richard M. Stallman" <address@hidden> writes:
> The problem is that the sit-for runs redisplay before the
> post-command-hook, so the cursor type is displayed based on the
> previous buffer position rather than the current position when moving
> the cursor upwards.
>
> Isn't there another redisplay after running post-command-hook?
> How come it doesn't show the new cursor type?
I think it is because sit-for markes the display of the window
accurate, and since the post-command-hook doesn't change the buffer
(but only sets a variable), that does not trigger a new redisplay.
The work-around to call force-window-update clears the "accurate"
state of the window.
This problem is not limited to cursor-type variable, but any variable
which influences redisplay, e.g. mode-line-format, header-line-format,
cursor-type, frame-parameters (cursor color), and other stuff
For example, this example works even worse than the cursor-type bug:
(progn
(defun set-header-line-adaptive ()
(setq header-line-format (if header-line-format nil "xxx")))
(add-hook 'post-command-hook 'set-header-line-adaptive))
Perhaps the simple fix is to avoid marking windows accurate when
redisplay is caused while executing lisp code, e.g. by calling
sit-for, and only when redisplay is called from the top-level
read-eval loop.
Alternatively, we need to find all the variables that may influence
display, and store previous/current value for each window -- which
is not as trivial as you may think, e.g. some text properties may
depend on arbitrary variables, so there is no definite list.
> Isn't that a bug?
>
> Anyway, the other problem cases just reported are certainly bugs.
Actually, I don't think so. I much rather state in the documentation
that: if a variable has influence on how contents of a window is
displayed / formatted, you should call force-window-update after
changing(!) such variables (emphasize "changing" for efficiency),
particularly if you change them in the post-command-hook.
> The right thing to do is to make every redisplay detect when this
> has changed, and DTRT if so. It won't cost much time either to
> implement or when running. We should not even consider suggesting
> a work-around for a bug we can fix.
IMO, the GENERIC bug is not trivial to fix.
--
Kim F. Storm <address@hidden> http://www.cua.dk