* Re: Setting cursor-type does not trigger redisplay of cursor [not found] ` <87vez91uc7.fsf@xemacs.org> @ 2005-11-05 23:43 ` Richard M. Stallman 2005-11-09 16:08 ` Kim F. Storm 0 siblings, 1 reply; 6+ messages in thread From: Richard M. Stallman @ 2005-11-05 23:43 UTC (permalink / raw) Cc: emacs-devel > 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? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Setting cursor-type does not trigger redisplay of cursor 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 0 siblings, 2 replies; 6+ messages in thread From: Kim F. Storm @ 2005-11-09 16:08 UTC (permalink / raw) Cc: Hrvoje Niksic, emacs-devel "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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Setting cursor-type does not trigger redisplay of cursor 2005-11-09 16:08 ` Kim F. Storm @ 2005-11-09 17:59 ` Juri Linkov 2005-11-10 2:09 ` Richard M. Stallman 1 sibling, 0 replies; 6+ messages in thread From: Juri Linkov @ 2005-11-09 17:59 UTC (permalink / raw) Cc: hniksic, rms, emacs-devel > 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/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Setting cursor-type does not trigger redisplay of cursor 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 1 sibling, 1 reply; 6+ messages in thread From: Richard M. Stallman @ 2005-11-10 2:09 UTC (permalink / raw) Cc: hniksic, emacs-devel 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Setting cursor-type does not trigger redisplay of cursor 2005-11-10 2:09 ` Richard M. Stallman @ 2005-11-10 8:30 ` Kim F. Storm 2005-11-10 20:49 ` Richard M. Stallman 0 siblings, 1 reply; 6+ messages in thread From: Kim F. Storm @ 2005-11-10 8:30 UTC (permalink / raw) Cc: hniksic, emacs-devel "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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Setting cursor-type does not trigger redisplay of cursor 2005-11-10 8:30 ` Kim F. Storm @ 2005-11-10 20:49 ` Richard M. Stallman 0 siblings, 0 replies; 6+ messages in thread From: Richard M. Stallman @ 2005-11-10 20:49 UTC (permalink / raw) Cc: hniksic, emacs-devel 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? ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2005-11-10 20:49 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [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 2005-11-10 20:49 ` Richard M. Stallman
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).