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

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?