Setting cursor-type does not trigger redisplay of cursor

Setting cursor-type does not trigger redisplay of cursor

[Hrvoje Niksic]

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.4.1 (i386-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2005-03-17 on trouble, modified by Debian
configured using `configure '--build=i386-linux' '--host=i386-linux' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--with-x=yes' '--with-x-toolkit=athena' 'CFLAGS=-DDEBIAN -g -O2' 'build_alias=i386-linux' 'host_alias=i386-linux''
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US
  locale-coding-system: iso-latin-1
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

I wanted to set cursor-type off post-command-hook with the intention
of changing the cursor appearance depending on whether the point is at
the end of line/buffer or not.  (This emulates an XEmacs feature of
showing a thin cursor at the end of line.)  Something like:

(defun set-cursor-adaptive ()
  (setq cursor-type (if (eq (char-after (point)) ?\n) '(bar . 5) t)))
(add-hook 'post-command-hook 'set-cursor-adaptive)

However, it turns out that this doesn't work as well as it should --
apparently changing `cursor-type' does not affect the shape of the
cursor until after it is redrawn, either by changing the position of
point, or by redrawing the frame.  I can work around that by calling
(sit-for 0), but it seems wasteful to invoke redisplay after every
single command.  I ended up checking whether the cursor would actually
change, and calling (sit-for 0) then, like this:

(defun set-cursor-adaptive ()
  (let ((type (let ((c (char-after (point))))
		(if (or (eq c ?\n) (null c))
		    '(bar . 5)
		  t))))
    (if (not (equal cursor-type type))
	(progn
	  (setq cursor-type type)
	  (sit-for 0)))))
(add-hook 'post-command-hook 'set-cursor-adaptive)

To summarize, changing the cursor type should IMO automatically
refresh the cursor when the event loop is reentered, without the user
having to do anything special.  This would be consistent with the rest
of Emacs, which doesn't require Lisp code to explicitly trigger
redisplay -- it simply happens when necessary.

Re: Setting cursor-type does not trigger redisplay of cursor

[Juri Linkov]

> (defun set-cursor-adaptive ()
>   (setq cursor-type (if (eq (char-after (point)) ?\n) '(bar . 5) t)))
> (add-hook 'post-command-hook 'set-cursor-adaptive)
>
> However, it turns out that this doesn't work as well as it should --
> apparently changing `cursor-type' does not affect the shape of the
> cursor until after it is redrawn, either by changing the position of
> point, or by redrawing the frame.

As I see, this works correctly in the CVS version.

BTW, I use this code to change cursor type and color:

(defun my-change-cursor ()
  "Change cursor color and type depending on insertion mode and input method."
  (set-cursor-color
   (cond (current-input-method "OrangeRed4")
         (t                    "black")))
  (set-cursor-type
   (cond (overwrite-mode       'box)
         (t                    'bar))))
(add-hook 'post-command-hook 'my-change-cursor)

There is no function `set-cursor-type' in CVS.  I use the patch below.
Note that it changes frame parameters instead of the buffer-local
variable `cursor-type'.  I think this causes less trouble.  Perhaps
this patch could be installed in CVS.

Index: lisp/frame.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/frame.el,v
retrieving revision 1.230
diff -c -r1.230 frame.el
*** lisp/frame.el	21 Oct 2005 08:27:04 -0000	1.230
--- lisp/frame.el	1 Nov 2005 09:17:22 -0000
***************
*** 903,917 ****
--- 903,928 ----
    (modify-frame-parameters (selected-frame)
  			   (list (cons 'cursor-color color-name))))
  
+ (defun set-cursor-type (cursor-type)
+   "Set the text cursor type of the selected frame to CURSOR-TYPE.
+ When called interactively, prompt for the name of the type to use.
+ To get the frame's current cursor type, use `frame-parameters'."
+   (interactive (list (intern (completing-read
+ 			      "Cursor type: "
+ 			      '("box" "hollow" "bar" "hbar" nil)))))
+   (modify-frame-parameters (selected-frame)
+ 			   (list (cons 'cursor-type cursor-type))))
+ 
  (defun set-mouse-color (color-name)
    "Set the color of the mouse pointer of the selected frame to COLOR-NAME.
  When called interactively, prompt for the name of the color to use.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Setting cursor-type does not trigger redisplay of cursor

[Hrvoje Niksic]

Juri Linkov <juri@jurta.org> writes:

>> (defun set-cursor-adaptive ()
>>   (setq cursor-type (if (eq (char-after (point)) ?\n) '(bar . 5) t)))
>> (add-hook 'post-command-hook 'set-cursor-adaptive)
>>
>> However, it turns out that this doesn't work as well as it should --
>> apparently changing `cursor-type' does not affect the shape of the
>> cursor until after it is redrawn, either by changing the position of
>> point, or by redrawing the frame.
>
> As I see, this works correctly in the CVS version.

Are you sure?  It sometimes requires a bit more testing for the bug to
appear.  Also, if you modify frame parameters off post-command-hook
with your code, that might trigger redisplay in its own right.

> There is no function `set-cursor-type' in CVS.  I use the patch
> below.  Note that it changes frame parameters instead of the
> buffer-local variable `cursor-type'.  I think this causes less
> trouble.

Why?  If anything, cursor type should be *window*-local.  Then, if you
change the cursor based on buffer contents (as my hook does), it is
wrong to modify it for the entire frame.  After all, frames can and do
have more than one window.

> + (defun set-cursor-type (cursor-type)
> +   "Set the text cursor type of the selected frame to CURSOR-TYPE.
> + When called interactively, prompt for the name of the type to use.
> + To get the frame's current cursor type, use `frame-parameters'."
> +   (interactive (list (intern (completing-read
> + 			      "Cursor type: "
> + 			      '("box" "hollow" "bar" "hbar" nil)))))
> +   (modify-frame-parameters (selected-frame)
> + 			   (list (cons 'cursor-type cursor-type))))
> + 

Setting the cursor type interactively does not appear useful.  This
command would IMHO needlessly clutter the command namespace.

Re: Setting cursor-type does not trigger redisplay of cursor

[Juri Linkov]

>>> (defun set-cursor-adaptive ()
>>>   (setq cursor-type (if (eq (char-after (point)) ?\n) '(bar . 5) t)))
>>> (add-hook 'post-command-hook 'set-cursor-adaptive)
>>>
>>> However, it turns out that this doesn't work as well as it should --
>>> apparently changing `cursor-type' does not affect the shape of the
>>> cursor until after it is redrawn, either by changing the position of
>>> point, or by redrawing the frame.
>>
>> As I see, this works correctly in the CVS version.
>
> Are you sure?  It sometimes requires a bit more testing for the bug to
> appear.

Have you tested it in Emacs CVS?  I tried your recipe in Emacs 21.4
where I can reproduce this bug.  But in Emacs CVS the same recipe
works correctly.

>> There is no function `set-cursor-type' in CVS.  I use the patch
>> below.  Note that it changes frame parameters instead of the
>> buffer-local variable `cursor-type'.  I think this causes less
>> trouble.
>
> Why?  If anything, cursor type should be *window*-local.  Then, if you
> change the cursor based on buffer contents (as my hook does), it is
> wrong to modify it for the entire frame.  After all, frames can and do
> have more than one window.

Maybe, window-local is a better scope, but currently cursor type can
be either buffer-local or frame-local.

> Setting the cursor type interactively does not appear useful.
> This command would IMHO needlessly clutter the command namespace.

It is not very useful, but there is already a similar interactive
command `set-cursor-color', and I see no reason to have
`set-cursor-color', and not to have `set-cursor-type'.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Setting cursor-type does not trigger redisplay of cursor

[Hrvoje Niksic]

Juri Linkov <juri@jurta.org> writes:

> Have you tested it in Emacs CVS?

Sorry, not yet.  However, a friend of mine tested it with the Debian
emacs-snapshot package which is supposed to be based on Emacs CVS, and
reports a similar problem -- even with the (sit-for 0) workaround.
But I haven't checked for myself yet.

But if you see the problem with 21 and don't see it with CVS, then I
guess the bug was really fixed.  I was previously under the impression
that you *only* tried it in CVS and didn't see the bug.

Re: Setting cursor-type does not trigger redisplay of cursor

[Juri Linkov]

> However, a friend of mine tested it with the Debian emacs-snapshot
> package which is supposed to be based on Emacs CVS, and reports
> a similar problem -- even with the (sit-for 0) workaround.
> But I haven't checked for myself yet.
>
> But if you see the problem with 21 and don't see it with CVS, then I
> guess the bug was really fixed.  I was previously under the impression
> that you *only* tried it in CVS and didn't see the bug.

First I tried it under Emacs 21.4, and after that I tried with the same
point movements in CVS, and didn't notice this bug.  However, now after
I tried more in Emacs CVS, I can reproduce this bug.  Its behavior is
different in Emacs 21.4 and CVS.  In Emacs 21.4 it failed to update the
cursor on horizontal point movements, but in Emacs CVS it doesn't update
the cursor on vertical point movements.  And yes, even (sit-for 0) doesn't
help.  So the bug is still here.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Setting cursor-type does not trigger redisplay of cursor

[Richard M. Stallman]

I see no need for a set-cursor-type.  It seems easy enough for people
to do that using modify-frame-parameters.

Do a lot of people really want to change this?

Re: Setting cursor-type does not trigger redisplay of cursor

[Hrvoje Niksic]

"Richard M. Stallman" <rms@gnu.org> writes:

> I see no need for a set-cursor-type.

Note that my original bug report does not request a set-cursor-type.
I would just like Emacs to automatically "notice" a change (of any
kind) to cursor-type at the next redisplay.

Re: Setting cursor-type does not trigger redisplay of cursor

[Juri Linkov]

> I see no need for a set-cursor-type.  It seems easy enough for people
> to do that using modify-frame-parameters.

There are other functions that use modify-frame-parameters like
set-cursor-color, set-mouse-color, etc.  And why not to add
set-cursor-type too?  The only difference is that there is
a buffer-local variable cursor-type, but no cursor-color.

> Do a lot of people really want to change this?

This is an addition rather than a change.  People might want to use it
instead of (setq cursor-type ...).

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Setting cursor-type does not trigger redisplay of cursor

[Juri Linkov]

> "Richard M. Stallman" <rms@gnu.org> writes:
>
>> I see no need for a set-cursor-type.
>
> Note that my original bug report does not request a set-cursor-type.
> I would just like Emacs to automatically "notice" a change (of any
> kind) to cursor-type at the next redisplay.

If the bug you reported will not get fixed until the next release,
then it makes sense to add a new special function and suggest users
to use it instead of (setq cursor-type ...).

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Setting cursor-type does not trigger redisplay of cursor

[Richard M. Stallman]

    Note that my original bug report does not request a set-cursor-type.
    I would just like Emacs to automatically "notice" a change (of any
    kind) to cursor-type at the next redisplay.

Right now, what is it that you need to do
to make Emacs really display the new cursor type?

Re: Setting cursor-type does not trigger redisplay of cursor

[Hrvoje Niksic]

"Richard M. Stallman" <rms@gnu.org> writes:

>     Note that my original bug report does not request a set-cursor-type.
>     I would just like Emacs to automatically "notice" a change (of any
>     kind) to cursor-type at the next redisplay.
>
> Right now, what is it that you need to do to make Emacs really
> display the new cursor type?

In Emacs 21, I need to call (sit-for 0) to force a redisplay.  In
Emacs 22 CVS, I am told, that doesn't work.

Both apply to setting cursor-type in post-command-hook, not to setting
it interactively with `M-: (setq cursor-type ...) RET'.

Re: Setting cursor-type does not trigger redisplay of cursor

[Richard M. Stallman]

    > I see no need for a set-cursor-type.  It seems easy enough for people
    > to do that using modify-frame-parameters.

    There are other functions that use modify-frame-parameters like
    set-cursor-color, set-mouse-color, etc.  And why not to add
    set-cursor-type too?

To save our time.  To keep the manual smaller.

If there is no positive reason to add something,
then we don't add it.

Re: Setting cursor-type does not trigger redisplay of cursor

[Richard M. Stallman]

    > Right now, what is it that you need to do to make Emacs really
    > display the new cursor type?

    In Emacs 21, I need to call (sit-for 0) to force a redisplay.  In
    Emacs 22 CVS, I am told, that doesn't work.

That is clearly a bug.

It seems to me that it should not be terribly hard to make redisplay
record the last cursor-type used for redisplay in a given frame, and
DTRT when it has changed.  So why do anything less convenient?

Would someone like to implement that, please?

Re: Setting cursor-type does not trigger redisplay of cursor

[Kim F. Storm]

"Richard M. Stallman" <rms@gnu.org> writes:

>     > Right now, what is it that you need to do to make Emacs really
>     > display the new cursor type?
>
>     In Emacs 21, I need to call (sit-for 0) to force a redisplay.  In
>     Emacs 22 CVS, I am told, that doesn't work.
>
> That is clearly a bug.
>
> It seems to me that it should not be terribly hard to make redisplay
> record the last cursor-type used for redisplay in a given frame, and
> DTRT when it has changed.  So why do anything less convenient?
>
> Would someone like to implement that, please?

I looked at the bug, and the reason why it works for right-left and
down movement, but not for up movement (sometimes) is the call to
sit-for in line-move:

	  (when (line-move-1 arg noerror to-end)
	    (when (not forward)
	      ;; Update display before calling pos-visible-in-window-p,
	      ;; because it depends on window-start being up-to-date.
	      (sit-for 0)


The reason for this update is to handle scrolling in large images.
(This is something which need to be improved after the release).

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.

The simple "fix" is to explicitly call force-window-update when
changing the cursor type in the post-command-hook.  IMO, that
work-around is ok for 22.1:

  (defun set-cursor-adaptive ()
    (let ((ocursor cursor-type))
      (setq cursor-type (if (eq (char-after (point)) ?\n) '(bar . 5) t))
      (if (not (equal ocursor cursor-type))
        (force-window-update (current-buffer)))))


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Setting cursor-type does not trigger redisplay of cursor

[Juri Linkov]

> I looked at the bug, and the reason why it works for right-left and
> down movement, but not for up movement (sometimes) is the call to
> sit-for in line-move

Please also note that cursor updating doesn't work not only for
up-down movement, but also in other cases like switching buffers.

Here is one test case:

`M-x cua-mode RET'
`M-: (setq cua-enable-cursor-indications t) RET'

Initially the cursor is black in the *scratch* buffer.

Type <insert> - cursor is yellow in the *scratch* buffer (GOOD)

`C-h i' - cursor is green in the *Info* buffer (GOOD)

`q' - cursor remains green in the *scratch* buffer (WRONG)

`C-l' - cursor is updated to yellow in the *scratch* buffer

`M-: (add-to-list 'same-window-buffer-names "*Help*") RET'

Now with the yellow cursor in the *scratch* buffer (due to <insert>):

`C-h f car RET' - cursor is yellow in the *Help* buffer (WRONG)

`C-l' - cursor is updated to green in the *Help* buffer

> The simple "fix" is to explicitly call force-window-update when
> changing the cursor type in the post-command-hook.  IMO, that
> work-around is ok for 22.1

This fix works for up-down movements, but after cursor movements, the
delay before the cursor changes its shape on the new location is
too noticeable.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Setting cursor-type does not trigger redisplay of cursor

[Richard M. Stallman]

    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?

Isn't that a bug?

Anyway, the other problem cases just reported are certainly bugs.
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.

Re: Setting cursor-type does not trigger redisplay of cursor

[Kim F. Storm]

"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

Re: Setting cursor-type does not trigger redisplay of cursor

[Richard M. Stallman]

    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
    ...

    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.

Indeed, it seems too difficult to fix.  I guess all we can do
is to document the need to call force-window-update in such cases.
The explanations of the variables that this situation exists for could
mention force-window-update with a cross reference.

Would you like to do that?