emacs-devel
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]