From: storm@cua.dk (Kim F. Storm)
Cc: hniksic@xemacs.org, emacs-devel@gnu.org
Subject: Re: Setting cursor-type does not trigger redisplay of cursor
Date: Thu, 10 Nov 2005 09:30:24 +0100 [thread overview]
Message-ID: <m3ek5o3nxb.fsf@kfs-l.imdomain.dk> (raw)
In-Reply-To: <E1Ea1sy-0004sb-51@fencepost.gnu.org> (Richard M. Stallman's message of "Wed, 09 Nov 2005 21:09:56 -0500")
"Richard M. Stallman" <rms@gnu.org> 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 <storm@cua.dk> http://www.cua.dk
next prev parent reply other threads:[~2005-11-10 8:30 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-31 15:49 Setting cursor-type does not trigger redisplay of cursor Hrvoje Niksic
2005-11-01 9:18 ` Juri Linkov
2005-11-01 13:51 ` Hrvoje Niksic
2005-11-01 20:03 ` Juri Linkov
2005-11-01 21:07 ` Hrvoje Niksic
2005-11-01 22:08 ` Juri Linkov
2005-11-02 10:27 ` Richard M. Stallman
2005-11-02 14:18 ` Hrvoje Niksic
2005-11-03 7:54 ` Juri Linkov
2005-11-03 13:50 ` Richard M. Stallman
2005-11-03 18:04 ` Hrvoje Niksic
2005-11-05 23:43 ` Richard M. Stallman
2005-11-09 16:08 ` Kim F. Storm
2005-11-09 17:59 ` Juri Linkov
2005-11-10 2:09 ` Richard M. Stallman
2005-11-10 8:30 ` Kim F. Storm [this message]
2005-11-10 20:49 ` Richard M. Stallman
2005-11-03 7:54 ` Juri Linkov
2005-11-03 21:41 ` Richard M. Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3ek5o3nxb.fsf@kfs-l.imdomain.dk \
--to=storm@cua.dk \
--cc=emacs-devel@gnu.org \
--cc=hniksic@xemacs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.