unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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

  reply	other threads:[~2005-11-10  8:30 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87mzkpbs9v.fsf@xemacs.org>
     [not found] ` <874q6wn313.fsf@jurta.org>
     [not found]   ` <E1EXFq5-0001EP-AH@fencepost.gnu.org>
     [not found]     ` <877jbrdtfc.fsf@xemacs.org>
     [not found]       ` <E1EXfUF-0007cr-DS@fencepost.gnu.org>
     [not found]         ` <87vez91uc7.fsf@xemacs.org>
2005-11-05 23:43           ` Setting cursor-type does not trigger redisplay of cursor 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

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

  List information: https://www.gnu.org/software/emacs/

* 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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).