* bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point @ 2016-09-05 19:16 Philipp Stephani 2016-09-05 21:29 ` Clément Pit--Claudel 2016-09-06 16:03 ` Eli Zaretskii 0 siblings, 2 replies; 24+ messages in thread From: Philipp Stephani @ 2016-09-05 19:16 UTC (permalink / raw To: 24372 I've tested this with a GTK build on GNU/Linux; other toolkits and OSes might also be affected (but terminal mode doesn't seem to be affected). emacs -Q -eval '(setq blink-cursor-delay 0.0)' Move point around in the scratch buffer (e.g. press C-b a couple of times): the cursor stays visible, as it should be. Then put the mouse focus on a different GTK window (not Emacs window), put the mouse focus back on Emacs, and move point again: the cursor is hidden, making it impossible to see until you stop moving. In GNU Emacs 25.1.50.4 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8) of 2016-09-05 built on unknown Repository revision: 6acff25280dbb97b5e9ddfd872b33ceb36b0470a Windowing system distributor 'The X.Org Foundation', version 11.0.11501000 System Description: Ubuntu 14.04 LTS Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. Configured using: 'configure --with-modules' Configured features: XPM JPEG TIFF GIF PNG SOUND GSETTINGS NOTIFY GNUTLS FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 MODULES Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t global-eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message subr-x puny seq byte-opt gv bytecomp byte-compile cl-extra help-mode cconv cl-loaddefs pcase cl-lib dired dired-loaddefs format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote inotify dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty make-network-process emacs) Memory information: ((conses 16 97852 8736) (symbols 48 20654 0) (miscs 40 325 194) (strings 32 17964 4666) (string-bytes 1 589251) (vectors 16 13794) (vector-slots 8 452872 5883) (floats 8 183 107) (intervals 56 211 0) (buffers 976 12) (heap 1024 48215 1026)) -- Google Germany GmbH Erika-Mann-Straße 33 80636 München Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat sind, leiten Sie diese bitte nicht weiter, informieren Sie den Absender und löschen Sie die E-Mail und alle Anhänge. Vielen Dank. This e-mail is confidential. If you are not the right addressee please do not forward it, please inform the sender, and please erase this e-mail including any attachments. Thanks. ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point 2016-09-05 19:16 bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point Philipp Stephani @ 2016-09-05 21:29 ` Clément Pit--Claudel 2016-09-06 16:03 ` Eli Zaretskii 1 sibling, 0 replies; 24+ messages in thread From: Clément Pit--Claudel @ 2016-09-05 21:29 UTC (permalink / raw To: 24372 [-- Attachment #1.1: Type: text/plain, Size: 434 bytes --] On 2016-09-05 15:16, Philipp Stephani wrote: > emacs -Q -eval '(setq blink-cursor-delay 0.0)' Indeed, I can reproduce this too. Clément. In GNU Emacs 25.1.50.7 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9) of 2016-07-20 built on clem-w50-mint Repository revision: a1a0c208e3e895a6ea0942e8e5c4077faf12c7ad Windowing system distributor 'The X.Org Foundation', version 11.0.11803000 System Description: Linux Mint 18 Sarah [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point 2016-09-05 19:16 bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point Philipp Stephani 2016-09-05 21:29 ` Clément Pit--Claudel @ 2016-09-06 16:03 ` Eli Zaretskii 2016-09-09 15:59 ` Philipp Stephani 1 sibling, 1 reply; 24+ messages in thread From: Eli Zaretskii @ 2016-09-06 16:03 UTC (permalink / raw To: Philipp Stephani; +Cc: 24372 > From: Philipp Stephani <p.stephani2@gmail.com> > Date: Mon, 05 Sep 2016 21:16:40 +0200 > > emacs -Q -eval '(setq blink-cursor-delay 0.0)' > > Move point around in the scratch buffer (e.g. press C-b a couple of > times): the cursor stays visible, as it should be. Then put the mouse > focus on a different GTK window (not Emacs window), put the mouse focus > back on Emacs, and move point again: the cursor is hidden, making it > impossible to see until you stop moving. Does it happen even if you wait with cursor motion until after the cursor blinks one time, i.e. if you start moving point with the cursor already visible after Emacs gets focus? ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point 2016-09-06 16:03 ` Eli Zaretskii @ 2016-09-09 15:59 ` Philipp Stephani 2016-09-09 16:07 ` Eli Zaretskii 0 siblings, 1 reply; 24+ messages in thread From: Philipp Stephani @ 2016-09-09 15:59 UTC (permalink / raw To: Eli Zaretskii; +Cc: 24372 [-- Attachment #1: Type: text/plain, Size: 871 bytes --] Eli Zaretskii <eliz@gnu.org> schrieb am Di., 6. Sep. 2016 um 18:03 Uhr: > > From: Philipp Stephani <p.stephani2@gmail.com> > > Date: Mon, 05 Sep 2016 21:16:40 +0200 > > > > emacs -Q -eval '(setq blink-cursor-delay 0.0)' > > > > Move point around in the scratch buffer (e.g. press C-b a couple of > > times): the cursor stays visible, as it should be. Then put the mouse > > focus on a different GTK window (not Emacs window), put the mouse focus > > back on Emacs, and move point again: the cursor is hidden, making it > > impossible to see until you stop moving. > > Does it happen even if you wait with cursor motion until after the > cursor blinks one time, i.e. if you start moving point with the cursor > already visible after Emacs gets focus? > Yes. No matter what state the cursor is in and how often it has already blinked, it becomes invisible when moving. [-- Attachment #2: Type: text/html, Size: 1565 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point 2016-09-09 15:59 ` Philipp Stephani @ 2016-09-09 16:07 ` Eli Zaretskii 2016-09-09 16:20 ` Philipp Stephani 0 siblings, 1 reply; 24+ messages in thread From: Eli Zaretskii @ 2016-09-09 16:07 UTC (permalink / raw To: Philipp Stephani; +Cc: 24372 > From: Philipp Stephani <p.stephani2@gmail.com> > Date: Fri, 09 Sep 2016 15:59:02 +0000 > Cc: 24372@debbugs.gnu.org > > Eli Zaretskii <eliz@gnu.org> schrieb am Di., 6. Sep. 2016 um 18:03 Uhr: > > > From: Philipp Stephani <p.stephani2@gmail.com> > > Date: Mon, 05 Sep 2016 21:16:40 +0200 > > > > emacs -Q -eval '(setq blink-cursor-delay 0.0)' > > > > Move point around in the scratch buffer (e.g. press C-b a couple of > > times): the cursor stays visible, as it should be. Then put the mouse > > focus on a different GTK window (not Emacs window), put the mouse focus > > back on Emacs, and move point again: the cursor is hidden, making it > > impossible to see until you stop moving. > > Does it happen even if you wait with cursor motion until after the > cursor blinks one time, i.e. if you start moving point with the cursor > already visible after Emacs gets focus? > > Yes. No matter what state the cursor is in and how often it has already blinked, it becomes invisible when > moving. So what is the importance of moving focus out of the Emacs frame and then back into it? Is the problem reproducible without that? Or are you saying that focus-out followed by focus-in event somehow changes the behavior wrt displaying the cursor? ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point 2016-09-09 16:07 ` Eli Zaretskii @ 2016-09-09 16:20 ` Philipp Stephani 2016-09-09 16:29 ` Philipp Stephani 0 siblings, 1 reply; 24+ messages in thread From: Philipp Stephani @ 2016-09-09 16:20 UTC (permalink / raw To: Eli Zaretskii; +Cc: 24372 [-- Attachment #1: Type: text/plain, Size: 1671 bytes --] Eli Zaretskii <eliz@gnu.org> schrieb am Fr., 9. Sep. 2016 um 18:07 Uhr: > > From: Philipp Stephani <p.stephani2@gmail.com> > > Date: Fri, 09 Sep 2016 15:59:02 +0000 > > Cc: 24372@debbugs.gnu.org > > > > Eli Zaretskii <eliz@gnu.org> schrieb am Di., 6. Sep. 2016 um 18:03 Uhr: > > > > > From: Philipp Stephani <p.stephani2@gmail.com> > > > Date: Mon, 05 Sep 2016 21:16:40 +0200 > > > > > > emacs -Q -eval '(setq blink-cursor-delay 0.0)' > > > > > > Move point around in the scratch buffer (e.g. press C-b a couple of > > > times): the cursor stays visible, as it should be. Then put the mouse > > > focus on a different GTK window (not Emacs window), put the mouse > focus > > > back on Emacs, and move point again: the cursor is hidden, making it > > > impossible to see until you stop moving. > > > > Does it happen even if you wait with cursor motion until after the > > cursor blinks one time, i.e. if you start moving point with the cursor > > already visible after Emacs gets focus? > > > > Yes. No matter what state the cursor is in and how often it has already > blinked, it becomes invisible when > > moving. > > So what is the importance of moving focus out of the Emacs frame and > then back into it? Is the problem reproducible without that? Or are > you saying that focus-out followed by focus-in event somehow changes > the behavior wrt displaying the cursor? > Yes. The cursor only become invisible after a focus-out/focus-in event. This isn't surprising given that blink-cursor-mode changes focus-in-hook and focus-out-hook. Probably the bug is hidden somewhere in the complex interaction between the various blink-cursor timers and hooks. [-- Attachment #2: Type: text/html, Size: 2972 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point 2016-09-09 16:20 ` Philipp Stephani @ 2016-09-09 16:29 ` Philipp Stephani 2016-09-09 17:18 ` Philipp Stephani 0 siblings, 1 reply; 24+ messages in thread From: Philipp Stephani @ 2016-09-09 16:29 UTC (permalink / raw To: Eli Zaretskii; +Cc: 24372 [-- Attachment #1: Type: text/plain, Size: 1961 bytes --] Philipp Stephani <p.stephani2@gmail.com> schrieb am Fr., 9. Sep. 2016 um 18:20 Uhr: > Eli Zaretskii <eliz@gnu.org> schrieb am Fr., 9. Sep. 2016 um 18:07 Uhr: > > > From: Philipp Stephani <p.stephani2@gmail.com> > > Date: Fri, 09 Sep 2016 15:59:02 +0000 > > Cc: 24372@debbugs.gnu.org > > > > Eli Zaretskii <eliz@gnu.org> schrieb am Di., 6. Sep. 2016 um 18:03 Uhr: > > > > > From: Philipp Stephani <p.stephani2@gmail.com> > > > Date: Mon, 05 Sep 2016 21:16:40 +0200 > > > > > > emacs -Q -eval '(setq blink-cursor-delay 0.0)' > > > > > > Move point around in the scratch buffer (e.g. press C-b a couple of > > > times): the cursor stays visible, as it should be. Then put the mouse > > > focus on a different GTK window (not Emacs window), put the mouse > focus > > > back on Emacs, and move point again: the cursor is hidden, making it > > > impossible to see until you stop moving. > > > > Does it happen even if you wait with cursor motion until after the > > cursor blinks one time, i.e. if you start moving point with the cursor > > already visible after Emacs gets focus? > > > > Yes. No matter what state the cursor is in and how often it has already > blinked, it becomes invisible when > > moving. > > So what is the importance of moving focus out of the Emacs frame and > then back into it? Is the problem reproducible without that? Or are > you saying that focus-out followed by focus-in event somehow changes > the behavior wrt displaying the cursor? > > > Yes. The cursor only become invisible after a focus-out/focus-in event. > This isn't surprising given that blink-cursor-mode changes focus-in-hook > and focus-out-hook. Probably the bug is hidden somewhere in the complex > interaction between the various blink-cursor timers and hooks. > A simpler recipe that doesn't need explicit focus events is emacs -Q -eval '(progn (setq blink-cursor-delay 0.0) (blink-cursor-suspend) (blink-cursor-check))' and then start moving point. [-- Attachment #2: Type: text/html, Size: 3834 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point 2016-09-09 16:29 ` Philipp Stephani @ 2016-09-09 17:18 ` Philipp Stephani 2016-09-09 18:59 ` Philipp Stephani 2016-09-10 7:21 ` Eli Zaretskii 0 siblings, 2 replies; 24+ messages in thread From: Philipp Stephani @ 2016-09-09 17:18 UTC (permalink / raw To: Eli Zaretskii; +Cc: 24372 [-- Attachment #1: Type: text/plain, Size: 3011 bytes --] Philipp Stephani <p.stephani2@gmail.com> schrieb am Fr., 9. Sep. 2016 um 18:29 Uhr: > Philipp Stephani <p.stephani2@gmail.com> schrieb am Fr., 9. Sep. 2016 um > 18:20 Uhr: > > Eli Zaretskii <eliz@gnu.org> schrieb am Fr., 9. Sep. 2016 um 18:07 Uhr: > > > From: Philipp Stephani <p.stephani2@gmail.com> > > Date: Fri, 09 Sep 2016 15:59:02 +0000 > > Cc: 24372@debbugs.gnu.org > > > > Eli Zaretskii <eliz@gnu.org> schrieb am Di., 6. Sep. 2016 um 18:03 Uhr: > > > > > From: Philipp Stephani <p.stephani2@gmail.com> > > > Date: Mon, 05 Sep 2016 21:16:40 +0200 > > > > > > emacs -Q -eval '(setq blink-cursor-delay 0.0)' > > > > > > Move point around in the scratch buffer (e.g. press C-b a couple of > > > times): the cursor stays visible, as it should be. Then put the mouse > > > focus on a different GTK window (not Emacs window), put the mouse > focus > > > back on Emacs, and move point again: the cursor is hidden, making it > > > impossible to see until you stop moving. > > > > Does it happen even if you wait with cursor motion until after the > > cursor blinks one time, i.e. if you start moving point with the cursor > > already visible after Emacs gets focus? > > > > Yes. No matter what state the cursor is in and how often it has already > blinked, it becomes invisible when > > moving. > > So what is the importance of moving focus out of the Emacs frame and > then back into it? Is the problem reproducible without that? Or are > you saying that focus-out followed by focus-in event somehow changes > the behavior wrt displaying the cursor? > > > Yes. The cursor only become invisible after a focus-out/focus-in event. > This isn't surprising given that blink-cursor-mode changes focus-in-hook > and focus-out-hook. Probably the bug is hidden somewhere in the complex > interaction between the various blink-cursor timers and hooks. > > > A simpler recipe that doesn't need explicit focus events is > > emacs -Q -eval '(progn (setq blink-cursor-delay 0.0) > (blink-cursor-suspend) (blink-cursor-check))' > > and then start moving point. > OK, I guess one issue is that setting blink-cursor-delay doesn't restart blink-cursor-idle-timer. (Similarly, changing blink-cursor-interval doesn't restart blink-cursor-timer.) While obviously we can't fix that when using setq, I'd suggest adding custom setters to the variables nevertheless. The direct cause of the issue seems to be that, when blink-cursor-delay is idle, after every command blink-cursor-start is called immediately, which hides the cursor. I guess that is so that in the default case where blink-cursor-delay = blink-cursor-interval the cursor frequency is constant. However, this causes the cursor to be hidden very quickly when blink-cursor-delay < blink-cursor-interval. Maybe in that case blink-cursor-start should show instead of hide the cursor, and run-with-timer should be called with an argument of (blink-cursor-interval - blink-cursor-delay), so that the cursor is at least shown for blink-cursor-interval. WDYT? [-- Attachment #2: Type: text/html, Size: 5525 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point 2016-09-09 17:18 ` Philipp Stephani @ 2016-09-09 18:59 ` Philipp Stephani 2016-09-10 7:21 ` Eli Zaretskii 1 sibling, 0 replies; 24+ messages in thread From: Philipp Stephani @ 2016-09-09 18:59 UTC (permalink / raw To: Eli Zaretskii; +Cc: 24372 [-- Attachment #1: Type: text/plain, Size: 3309 bytes --] Philipp Stephani <p.stephani2@gmail.com> schrieb am Fr., 9. Sep. 2016 um 19:18 Uhr: > Philipp Stephani <p.stephani2@gmail.com> schrieb am Fr., 9. Sep. 2016 um > 18:29 Uhr: > > Philipp Stephani <p.stephani2@gmail.com> schrieb am Fr., 9. Sep. 2016 um > 18:20 Uhr: > > Eli Zaretskii <eliz@gnu.org> schrieb am Fr., 9. Sep. 2016 um 18:07 Uhr: > > > From: Philipp Stephani <p.stephani2@gmail.com> > > Date: Fri, 09 Sep 2016 15:59:02 +0000 > > Cc: 24372@debbugs.gnu.org > > > > Eli Zaretskii <eliz@gnu.org> schrieb am Di., 6. Sep. 2016 um 18:03 Uhr: > > > > > From: Philipp Stephani <p.stephani2@gmail.com> > > > Date: Mon, 05 Sep 2016 21:16:40 +0200 > > > > > > emacs -Q -eval '(setq blink-cursor-delay 0.0)' > > > > > > Move point around in the scratch buffer (e.g. press C-b a couple of > > > times): the cursor stays visible, as it should be. Then put the mouse > > > focus on a different GTK window (not Emacs window), put the mouse > focus > > > back on Emacs, and move point again: the cursor is hidden, making it > > > impossible to see until you stop moving. > > > > Does it happen even if you wait with cursor motion until after the > > cursor blinks one time, i.e. if you start moving point with the cursor > > already visible after Emacs gets focus? > > > > Yes. No matter what state the cursor is in and how often it has already > blinked, it becomes invisible when > > moving. > > So what is the importance of moving focus out of the Emacs frame and > then back into it? Is the problem reproducible without that? Or are > you saying that focus-out followed by focus-in event somehow changes > the behavior wrt displaying the cursor? > > > Yes. The cursor only become invisible after a focus-out/focus-in event. > This isn't surprising given that blink-cursor-mode changes focus-in-hook > and focus-out-hook. Probably the bug is hidden somewhere in the complex > interaction between the various blink-cursor timers and hooks. > > > A simpler recipe that doesn't need explicit focus events is > > emacs -Q -eval '(progn (setq blink-cursor-delay 0.0) > (blink-cursor-suspend) (blink-cursor-check))' > > and then start moving point. > > > OK, I guess one issue is that setting blink-cursor-delay doesn't restart > blink-cursor-idle-timer. (Similarly, changing blink-cursor-interval doesn't > restart blink-cursor-timer.) While obviously we can't fix that when using > setq, I'd suggest adding custom setters to the variables nevertheless. > > The direct cause of the issue seems to be that, when blink-cursor-delay is > idle, after every command blink-cursor-start is called immediately, which > hides the cursor. I guess that is so that in the default case where > blink-cursor-delay = blink-cursor-interval the cursor frequency is > constant. However, this causes the cursor to be hidden very quickly when > blink-cursor-delay < blink-cursor-interval. Maybe in that case > blink-cursor-start should show instead of hide the cursor, and > run-with-timer should be called with an argument of (blink-cursor-interval > - blink-cursor-delay), so that the cursor is at least shown for > blink-cursor-interval. WDYT? > I just realized that this is equivalent to treating blink-cursor-interval as a lower bound to blink-cursor-delay. Not sure whether that's the intention of blink-cursor-delay. [-- Attachment #2: Type: text/html, Size: 6350 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point 2016-09-09 17:18 ` Philipp Stephani 2016-09-09 18:59 ` Philipp Stephani @ 2016-09-10 7:21 ` Eli Zaretskii 2016-09-11 9:15 ` Philipp Stephani 1 sibling, 1 reply; 24+ messages in thread From: Eli Zaretskii @ 2016-09-10 7:21 UTC (permalink / raw To: Philipp Stephani; +Cc: 24372 > From: Philipp Stephani <p.stephani2@gmail.com> > Date: Fri, 09 Sep 2016 17:18:12 +0000 > Cc: 24372@debbugs.gnu.org > > A simpler recipe that doesn't need explicit focus events is > > emacs -Q -eval '(progn (setq blink-cursor-delay 0.0) (blink-cursor-suspend) (blink-cursor-check))' > > and then start moving point. > > OK, I guess one issue is that setting blink-cursor-delay doesn't restart blink-cursor-idle-timer. (Similarly, > changing blink-cursor-interval doesn't restart blink-cursor-timer.) While obviously we can't fix that when using > setq, I'd suggest adding custom setters to the variables nevertheless. > > The direct cause of the issue seems to be that, when blink-cursor-delay is idle, after every command > blink-cursor-start is called immediately, which hides the cursor. Thanks. Does the patch below fix the issue, without introducing any adverse side effects? diff --git a/lisp/frame.el b/lisp/frame.el index cfd40bf..e10f0ce 100644 --- a/lisp/frame.el +++ b/lisp/frame.el @@ -2068,7 +2068,10 @@ blink-cursor-start (run-with-timer blink-cursor-interval blink-cursor-interval 'blink-cursor-timer-function)) (add-hook 'pre-command-hook 'blink-cursor-end) - (internal-show-cursor nil nil))) + ;; Start by showing the cursor, so that even if they set + ;; blink-cursor-delay to zero, they still see the cursor during + ;; the execution of the Emacs commands. + (internal-show-cursor nil t))) (defun blink-cursor-timer-function () "Timer function of timer `blink-cursor-timer'." ^ permalink raw reply related [flat|nested] 24+ messages in thread
* bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point 2016-09-10 7:21 ` Eli Zaretskii @ 2016-09-11 9:15 ` Philipp Stephani 2016-09-11 16:23 ` Eli Zaretskii 0 siblings, 1 reply; 24+ messages in thread From: Philipp Stephani @ 2016-09-11 9:15 UTC (permalink / raw To: Eli Zaretskii; +Cc: 24372 [-- Attachment #1.1: Type: text/plain, Size: 1368 bytes --] Eli Zaretskii <eliz@gnu.org> schrieb am Sa., 10. Sep. 2016 um 09:21 Uhr: > > From: Philipp Stephani <p.stephani2@gmail.com> > > Date: Fri, 09 Sep 2016 17:18:12 +0000 > > Cc: 24372@debbugs.gnu.org > > > > A simpler recipe that doesn't need explicit focus events is > > > > emacs -Q -eval '(progn (setq blink-cursor-delay 0.0) > (blink-cursor-suspend) (blink-cursor-check))' > > > > and then start moving point. > > > > OK, I guess one issue is that setting blink-cursor-delay doesn't restart > blink-cursor-idle-timer. (Similarly, > > changing blink-cursor-interval doesn't restart blink-cursor-timer.) > While obviously we can't fix that when using > > setq, I'd suggest adding custom setters to the variables nevertheless. > I've attached a patch for this. It shouldn't be controversial because it only reduces the possibility for surprises, but doesn't change any behavior. > > > > The direct cause of the issue seems to be that, when blink-cursor-delay > is idle, after every command > > blink-cursor-start is called immediately, which hides the cursor. > > Thanks. Does the patch below fix the issue, without introducing any > adverse side effects? > > It does introduce the adverse side effect that now the first blink takes one second (the sum of cursor-blink-delay and cursor-blink-interval). I've attached another patch with the change I have in mind. [-- Attachment #1.2: Type: text/html, Size: 2448 bytes --] [-- Attachment #2: 0001-Avoid-hiding-the-blinking-cursor-too-fast.patch --] [-- Type: application/octet-stream, Size: 2392 bytes --] From 095920029806b1c599c9618818105e22e25321f5 Mon Sep 17 00:00:00 2001 From: Philipp Stephani <phst@google.com> Date: Sun, 11 Sep 2016 11:07:18 +0200 Subject: [PATCH] Avoid hiding the blinking cursor too fast If `blink-cursor-delay' is smaller than `blink-cursor-delay', the cursor is hidden to quickly after a command; see Bug#24372. This change uses `blink-cursor-interval' as lower bound for `blink-cursor-delay'. * lisp/frame.el (blink-cursor-check, blink-cursor-mode): Use `blink-cursor-interval' as lower bound to `blink-cursor-delay'. (blink-cursor-delay): Document changed behavior of `blink-cursor-delay'. --- lisp/frame.el | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/lisp/frame.el b/lisp/frame.el index cfd40bf..ebc5cc1 100644 --- a/lisp/frame.el +++ b/lisp/frame.el @@ -2027,7 +2027,11 @@ cursor :group 'frames) (defcustom blink-cursor-delay 0.5 - "Seconds of idle time after which cursor starts to blink." + "Seconds of idle time after which cursor starts to blink. +This is the interval between the end of an user action and the +time when the cursor first becomes invisible due to blinking. If +this is shorter than `blink-cursor-interval', the value of +`blink-cursor-interval' is used instead." :type 'number :group 'cursor) @@ -2114,9 +2118,8 @@ blink-cursor-check (not blink-cursor-idle-timer)) (remove-hook 'post-command-hook 'blink-cursor-check) (setq blink-cursor-idle-timer - (run-with-idle-timer blink-cursor-delay - blink-cursor-delay - 'blink-cursor-start)))) + (let ((delay (max blink-cursor-delay blink-cursor-interval))) + (run-with-idle-timer delay delay #'blink-cursor-start))))) (define-obsolete-variable-alias 'blink-cursor 'blink-cursor-mode "22.1") @@ -2148,9 +2151,8 @@ blink-cursor-mode (add-hook 'focus-in-hook #'blink-cursor-check) (add-hook 'focus-out-hook #'blink-cursor-suspend) (setq blink-cursor-idle-timer - (run-with-idle-timer blink-cursor-delay - blink-cursor-delay - #'blink-cursor-start)))) + (let ((delay (max blink-cursor-delay blink-cursor-interval))) + (run-with-idle-timer delay delay #'blink-cursor-start))))) \f ;; Frame maximization/fullscreen -- 2.9.0 [-- Attachment #3: 0001-Restart-blink-cursor-timers-on-interval-changes.patch --] [-- Type: application/octet-stream, Size: 3899 bytes --] From 06445b3e6fee4ab1c680ab4d9aedb75eddf85352 Mon Sep 17 00:00:00 2001 From: Philipp Stephani <phst@google.com> Date: Sat, 10 Sep 2016 10:16:32 +0200 Subject: [PATCH] Restart blink cursor timers on interval changes This prevents surprising behavior when timer interval customizations are only applied whenever the timers happen to be restarted (see Bug#24372). * lisp/frame.el (blink-cursor--start-idle-timer) (blink-cursor--start-timer): New functions. (blink-cursor-start, blink-cursor-check, blink-cursor-mode): Use the new helper functions. (blink-cursor-delay, blink-cursor-interval): Restart timers when the value is changed. --- lisp/frame.el | 38 +++++++++++++++++++++++++------------- 1 file changed, 25 insertions(+), 13 deletions(-) diff --git a/lisp/frame.el b/lisp/frame.el index cfd40bf..b32ba7a 100644 --- a/lisp/frame.el +++ b/lisp/frame.el @@ -2029,12 +2029,18 @@ cursor (defcustom blink-cursor-delay 0.5 "Seconds of idle time after which cursor starts to blink." :type 'number - :group 'cursor) + :group 'cursor + :set (lambda (symbol value) + (set-default symbol value) + (when blink-cursor-idle-timer (blink-cursor--start-idle-timer)))) (defcustom blink-cursor-interval 0.5 "Length of cursor blink interval in seconds." :type 'number - :group 'cursor) + :group 'cursor + :set (lambda (symbol value) + (set-default symbol value) + (when blink-cursor-timer (blink-cursor--start-timer)))) (defcustom blink-cursor-blinks 10 "How many times to blink before using a solid cursor on NS, X, and MS-Windows. @@ -2055,6 +2061,20 @@ blink-cursor-timer This timer calls `blink-cursor-timer-function' every `blink-cursor-interval' seconds.") +(defun blink-cursor--start-idle-timer () + "Start the `blink-cursor-idle-timer'." + (when blink-cursor-idle-timer (cancel-timer blink-cursor-idle-timer)) + (setq blink-cursor-idle-timer + (run-with-idle-timer blink-cursor-delay blink-cursor-delay + #'blink-cursor-start))) + +(defun blink-cursor--start-timer () + "Start the `blink-cursor-timer'." + (when blink-cursor-timer (cancel-timer blink-cursor-timer)) + (setq blink-cursor-timer + (run-with-timer blink-cursor-interval blink-cursor-interval + #'blink-cursor-timer-function))) + (defun blink-cursor-start () "Timer function called from the timer `blink-cursor-idle-timer'. This starts the timer `blink-cursor-timer', which makes the cursor blink @@ -2064,9 +2084,7 @@ blink-cursor-start ;; Set up the timer first, so that if this signals an error, ;; blink-cursor-end is not added to pre-command-hook. (setq blink-cursor-blinks-done 1) - (setq blink-cursor-timer - (run-with-timer blink-cursor-interval blink-cursor-interval - 'blink-cursor-timer-function)) + (blink-cursor--start-timer) (add-hook 'pre-command-hook 'blink-cursor-end) (internal-show-cursor nil nil))) @@ -2113,10 +2131,7 @@ blink-cursor-check (when (and blink-cursor-mode (not blink-cursor-idle-timer)) (remove-hook 'post-command-hook 'blink-cursor-check) - (setq blink-cursor-idle-timer - (run-with-idle-timer blink-cursor-delay - blink-cursor-delay - 'blink-cursor-start)))) + (blink-cursor--start-idle-timer))) (define-obsolete-variable-alias 'blink-cursor 'blink-cursor-mode "22.1") @@ -2147,10 +2162,7 @@ blink-cursor-mode (when blink-cursor-mode (add-hook 'focus-in-hook #'blink-cursor-check) (add-hook 'focus-out-hook #'blink-cursor-suspend) - (setq blink-cursor-idle-timer - (run-with-idle-timer blink-cursor-delay - blink-cursor-delay - #'blink-cursor-start)))) + (blink-cursor--start-idle-timer))) \f ;; Frame maximization/fullscreen -- 2.9.0 ^ permalink raw reply related [flat|nested] 24+ messages in thread
* bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point 2016-09-11 9:15 ` Philipp Stephani @ 2016-09-11 16:23 ` Eli Zaretskii 2016-09-11 17:37 ` Philipp Stephani 0 siblings, 1 reply; 24+ messages in thread From: Eli Zaretskii @ 2016-09-11 16:23 UTC (permalink / raw To: Philipp Stephani; +Cc: 24372 > From: Philipp Stephani <p.stephani2@gmail.com> > Date: Sun, 11 Sep 2016 09:15:49 +0000 > Cc: 24372@debbugs.gnu.org > > > OK, I guess one issue is that setting blink-cursor-delay doesn't restart blink-cursor-idle-timer. > (Similarly, > > changing blink-cursor-interval doesn't restart blink-cursor-timer.) While obviously we can't fix that > when using > > setq, I'd suggest adding custom setters to the variables nevertheless. > > I've attached a patch for this. It shouldn't be controversial because it only reduces the possibility for surprises, > but doesn't change any behavior. Using the maximum of blink-cursor-delay and blink-cursor-interval effectively removes the user's ability of controlling the delay before the cursor starts blinking when Emacs becomes idle, doesn't it? If so, I don't think this could qualify as not changing any behavior. Plus, if the user sets the interval to a very small value, we have the same problem again. How about a variant of this below? It uses a fixed limitation from below on the delay, but only for the first blink. (The value 0.2 was found by experimentation, not sure if we need to add yet another defcustom for that.) > It does introduce the adverse side effect that now the first blink takes one second (the sum of > cursor-blink-delay and cursor-blink-interval). Right. > I've attached another patch with the change I have in mind. This has a disadvantage of creating a new timer object each time, which I think we'd like to avoid: too much consing. (Also, don't you need to set the timer variable to nil when the timer is disabled?) I'd prefer something along the lines of the first idea, the patch below or some variant of it. It is simpler. diff --git a/lisp/frame.el b/lisp/frame.el index cfd40bf..4540172 100644 --- a/lisp/frame.el +++ b/lisp/frame.el @@ -2114,7 +2114,7 @@ blink-cursor-check (not blink-cursor-idle-timer)) (remove-hook 'post-command-hook 'blink-cursor-check) (setq blink-cursor-idle-timer - (run-with-idle-timer blink-cursor-delay + (run-with-idle-timer (max 0.2 blink-cursor-delay) blink-cursor-delay 'blink-cursor-start)))) @@ -2148,7 +2148,7 @@ blink-cursor-mode (add-hook 'focus-in-hook #'blink-cursor-check) (add-hook 'focus-out-hook #'blink-cursor-suspend) (setq blink-cursor-idle-timer - (run-with-idle-timer blink-cursor-delay + (run-with-idle-timer (max 0.2 blink-cursor-delay) blink-cursor-delay #'blink-cursor-start)))) ^ permalink raw reply related [flat|nested] 24+ messages in thread
* bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point 2016-09-11 16:23 ` Eli Zaretskii @ 2016-09-11 17:37 ` Philipp Stephani 2016-09-11 19:18 ` Eli Zaretskii 0 siblings, 1 reply; 24+ messages in thread From: Philipp Stephani @ 2016-09-11 17:37 UTC (permalink / raw To: Eli Zaretskii; +Cc: 24372 [-- Attachment #1: Type: text/plain, Size: 3813 bytes --] Eli Zaretskii <eliz@gnu.org> schrieb am So., 11. Sep. 2016 um 18:23 Uhr: > > From: Philipp Stephani <p.stephani2@gmail.com> > > Date: Sun, 11 Sep 2016 09:15:49 +0000 > > Cc: 24372@debbugs.gnu.org > > > > > OK, I guess one issue is that setting blink-cursor-delay doesn't > restart blink-cursor-idle-timer. > > (Similarly, > > > changing blink-cursor-interval doesn't restart blink-cursor-timer.) > While obviously we can't fix that > > when using > > > setq, I'd suggest adding custom setters to the variables nevertheless. > > > > I've attached a patch for this. It shouldn't be controversial because it > only reduces the possibility for surprises, > > but doesn't change any behavior. > > Using the maximum of blink-cursor-delay and blink-cursor-interval > effectively removes the user's ability of controlling the delay before > the cursor starts blinking when Emacs becomes idle, doesn't it? Yes. I tried to figure out what the intention of blink-cursor-delay was, but couldn't find anything (the commit where it was introduced doesn't provide any motivation). I don't think that blink-cursor-delay < blink-cursor-interval ever makes sense. The other way round (delay > interval) is useful if you want to keep the cursor visible for a bit longer after a command. > If > so, I don't think this could qualify as not changing any behavior. > My comment is about the other patch, the one that fixes the customization options. > Plus, if the user sets the interval to a very small value, we have the > same problem again. > True, but so far that hasn't happened. Also it seems less surprising: if you increase the frequency, the cursor blinks faster, as expected. > > How about a variant of this below? It uses a fixed limitation from > below on the delay, but only for the first blink. (The value 0.2 was > found by experimentation, not sure if we need to add yet another > defcustom for that.) > I don't think we should introduce magic numbers or further customization options. (TBH, I already doubt the usefulness of blink-cursor-delay, but that's already there.) > > > It does introduce the adverse side effect that now the first blink takes > one second (the sum of > > cursor-blink-delay and cursor-blink-interval). > > Right. > > > I've attached another patch with the change I have in mind. > > This has a disadvantage of creating a new timer object each time, > which I think we'd like to avoid: too much consing. (Also, don't you > need to set the timer variable to nil when the timer is disabled?) > I don't understand - the patch doesn't create any additional timers, it only changes the initial delay of the idle-timer. > > I'd prefer something along the lines of the first idea, the patch > below or some variant of it. It is simpler. > > diff --git a/lisp/frame.el b/lisp/frame.el > index cfd40bf..4540172 100644 > --- a/lisp/frame.el > +++ b/lisp/frame.el > @@ -2114,7 +2114,7 @@ blink-cursor-check > (not blink-cursor-idle-timer)) > (remove-hook 'post-command-hook 'blink-cursor-check) > (setq blink-cursor-idle-timer > - (run-with-idle-timer blink-cursor-delay > + (run-with-idle-timer (max 0.2 blink-cursor-delay) > blink-cursor-delay > 'blink-cursor-start)))) > > @@ -2148,7 +2148,7 @@ blink-cursor-mode > (add-hook 'focus-in-hook #'blink-cursor-check) > (add-hook 'focus-out-hook #'blink-cursor-suspend) > (setq blink-cursor-idle-timer > - (run-with-idle-timer blink-cursor-delay > + (run-with-idle-timer (max 0.2 blink-cursor-delay) > blink-cursor-delay > #'blink-cursor-start)))) > > My patch is identical, except is uses blink-cursor-interval as lower bound. [-- Attachment #2: Type: text/html, Size: 6554 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point 2016-09-11 17:37 ` Philipp Stephani @ 2016-09-11 19:18 ` Eli Zaretskii 2016-09-23 14:28 ` Eli Zaretskii 2016-09-25 19:09 ` Philipp Stephani 0 siblings, 2 replies; 24+ messages in thread From: Eli Zaretskii @ 2016-09-11 19:18 UTC (permalink / raw To: Philipp Stephani; +Cc: 24372 > From: Philipp Stephani <p.stephani2@gmail.com> > Date: Sun, 11 Sep 2016 17:37:36 +0000 > Cc: 24372@debbugs.gnu.org > > Using the maximum of blink-cursor-delay and blink-cursor-interval > effectively removes the user's ability of controlling the delay before > the cursor starts blinking when Emacs becomes idle, doesn't it? > > Yes. I tried to figure out what the intention of blink-cursor-delay was, but couldn't find anything (the commit > where it was introduced doesn't provide any motivation). I don't think that blink-cursor-delay < > blink-cursor-interval ever makes sense. The other way round (delay > interval) is useful if you want to keep the > cursor visible for a bit longer after a command. I don't understand the nature of your difficulty. blink-cursor-delay is obviously how soon the user want the cursor to start blinking after Emacs becomes idle. That is orthogonal to the blink interval, which is in effect once the blinking begins. > Plus, if the user sets the interval to a very small value, we have the > same problem again. > > True, but so far that hasn't happened. Also it seems less surprising: if you increase the frequency, the cursor > blinks faster, as expected. The problem is not with a faster blinking, the problem is with the cursor almost invisible. E.g., try to set blink-cursor-delay to a very small, but non-zero value with today's sources, and then repeat your recipe, with and without the focus-out/in dance. > How about a variant of this below? It uses a fixed limitation from > below on the delay, but only for the first blink. (The value 0.2 was > found by experimentation, not sure if we need to add yet another > defcustom for that.) > > I don't think we should introduce magic numbers or further customization options. It solves the problem, doesn't it? I don't mind very much if it were a defcustom, I just think no one would want to change it. > > I've attached another patch with the change I have in mind. > > This has a disadvantage of creating a new timer object each time, > which I think we'd like to avoid: too much consing. (Also, don't you > need to set the timer variable to nil when the timer is disabled?) > > I don't understand - the patch doesn't create any additional timers, it only changes the initial delay of the > idle-timer. Each time blink-cursor--start-timer or blink-cursor--start-idle-timer is called, they create a new timer, right? And your patch makes us call these functions each time blinking is started or ended, right? > My patch is identical, except is uses blink-cursor-interval as lower bound. Of course. That's why I said it's a minor variant. There's another difference, though: in my patch we only limit the first argument to run-with-timer/run-with-idle-timer, not the second. So only the first blink cycle is affected. ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point 2016-09-11 19:18 ` Eli Zaretskii @ 2016-09-23 14:28 ` Eli Zaretskii 2016-09-25 19:09 ` Philipp Stephani 1 sibling, 0 replies; 24+ messages in thread From: Eli Zaretskii @ 2016-09-23 14:28 UTC (permalink / raw To: p.stephani2; +Cc: 24372-done > Date: Sun, 11 Sep 2016 22:18:38 +0300 > From: Eli Zaretskii <eliz@gnu.org> > Cc: 24372@debbugs.gnu.org > > > How about a variant of this below? It uses a fixed limitation from > > below on the delay, but only for the first blink. (The value 0.2 was > > found by experimentation, not sure if we need to add yet another > > defcustom for that.) > > > > I don't think we should introduce magic numbers or further customization options. > > It solves the problem, doesn't it? I don't mind very much if it were > a defcustom, I just think no one would want to change it. > > > > I've attached another patch with the change I have in mind. > > > > This has a disadvantage of creating a new timer object each time, > > which I think we'd like to avoid: too much consing. (Also, don't you > > need to set the timer variable to nil when the timer is disabled?) > > > > I don't understand - the patch doesn't create any additional timers, it only changes the initial delay of the > > idle-timer. > > Each time blink-cursor--start-timer or blink-cursor--start-idle-timer > is called, they create a new timer, right? And your patch makes us > call these functions each time blinking is started or ended, right? > > > My patch is identical, except is uses blink-cursor-interval as lower bound. > > Of course. That's why I said it's a minor variant. > > There's another difference, though: in my patch we only limit the > first argument to run-with-timer/run-with-idle-timer, not the second. > So only the first blink cycle is affected. No further comments, so I pushed my last proposed patch to the emacs-25 branch, and I'm marking this bug done. Thanks. ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point 2016-09-11 19:18 ` Eli Zaretskii 2016-09-23 14:28 ` Eli Zaretskii @ 2016-09-25 19:09 ` Philipp Stephani 2016-10-01 8:25 ` Eli Zaretskii 1 sibling, 1 reply; 24+ messages in thread From: Philipp Stephani @ 2016-09-25 19:09 UTC (permalink / raw To: Eli Zaretskii; +Cc: 24372 [-- Attachment #1: Type: text/plain, Size: 3193 bytes --] Eli Zaretskii <eliz@gnu.org> schrieb am So., 11. Sep. 2016 um 21:19 Uhr: > > From: Philipp Stephani <p.stephani2@gmail.com> > > Date: Sun, 11 Sep 2016 17:37:36 +0000 > > Cc: 24372@debbugs.gnu.org > > > > Using the maximum of blink-cursor-delay and blink-cursor-interval > > effectively removes the user's ability of controlling the delay before > > the cursor starts blinking when Emacs becomes idle, doesn't it? > > > > Yes. I tried to figure out what the intention of blink-cursor-delay was, > but couldn't find anything (the commit > > where it was introduced doesn't provide any motivation). I don't think > that blink-cursor-delay < > > blink-cursor-interval ever makes sense. The other way round (delay > > interval) is useful if you want to keep the > > cursor visible for a bit longer after a command. > > I don't understand the nature of your difficulty. blink-cursor-delay > is obviously how soon the user want the cursor to start blinking after > Emacs becomes idle. That is orthogonal to the blink interval, which > is in effect once the blinking begins. > Having the cursor hidden faster than it blinks sounds weird to me, but I guess it's OK since it's easy enough to change the option, so your interpretation sounds good to me as well. > > > How about a variant of this below? It uses a fixed limitation from > > below on the delay, but only for the first blink. (The value 0.2 was > > found by experimentation, not sure if we need to add yet another > > defcustom for that.) > > > > I don't think we should introduce magic numbers or further customization > options. > > It solves the problem, doesn't it? I don't mind very much if it were > a defcustom, I just think no one would want to change it. > OK, then it would be great to document the new behavior in the documentation of `blink-cursor-delay' and also clarify what "starting to blink" means. > > > > I've attached another patch with the change I have in mind. > > > > This has a disadvantage of creating a new timer object each time, > > which I think we'd like to avoid: too much consing. (Also, don't you > > need to set the timer variable to nil when the timer is disabled?) > > > > I don't understand - the patch doesn't create any additional timers, it > only changes the initial delay of the > > idle-timer. > > Each time blink-cursor--start-timer or blink-cursor--start-idle-timer > is called, they create a new timer, right? And your patch makes us > call these functions each time blinking is started or ended, right? > No, the other patch is that it restarts the timers when the customization options are set. Otherwise the options only become effective after a focus-out/focus-in event or something similar that restarts the cursor. > > > My patch is identical, except is uses blink-cursor-interval as lower > bound. > > Of course. That's why I said it's a minor variant. > > There's another difference, though: in my patch we only limit the > first argument to run-with-timer/run-with-idle-timer, not the second. > So only the first blink cycle is affected. > Doesn't that mean that the adjusted delay is applied only after the first command, but not after subsequent commands? [-- Attachment #2: Type: text/html, Size: 5262 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point 2016-09-25 19:09 ` Philipp Stephani @ 2016-10-01 8:25 ` Eli Zaretskii 2016-10-01 16:11 ` Philipp Stephani 0 siblings, 1 reply; 24+ messages in thread From: Eli Zaretskii @ 2016-10-01 8:25 UTC (permalink / raw To: Philipp Stephani; +Cc: 24372 > From: Philipp Stephani <p.stephani2@gmail.com> > Date: Sun, 25 Sep 2016 19:09:52 +0000 > Cc: 24372@debbugs.gnu.org > > > How about a variant of this below? It uses a fixed limitation from > > below on the delay, but only for the first blink. (The value 0.2 was > > found by experimentation, not sure if we need to add yet another > > defcustom for that.) > > > > I don't think we should introduce magic numbers or further customization options. > > It solves the problem, doesn't it? I don't mind very much if it were > a defcustom, I just think no one would want to change it. > > OK, then it would be great to document the new behavior in the documentation of `blink-cursor-delay' and also > clarify what "starting to blink" means. Done. > > > I've attached another patch with the change I have in mind. > > > > This has a disadvantage of creating a new timer object each time, > > which I think we'd like to avoid: too much consing. (Also, don't you > > need to set the timer variable to nil when the timer is disabled?) > > > > I don't understand - the patch doesn't create any additional timers, it only changes the initial delay of > the > > idle-timer. > > Each time blink-cursor--start-timer or blink-cursor--start-idle-timer > is called, they create a new timer, right? And your patch makes us > call these functions each time blinking is started or ended, right? > > No, the other patch is that it restarts the timers when the customization options are set. Otherwise the options > only become effective after a focus-out/focus-in event or something similar that restarts the cursor. > > > My patch is identical, except is uses blink-cursor-interval as lower bound. > > Of course. That's why I said it's a minor variant. > > There's another difference, though: in my patch we only limit the > first argument to run-with-timer/run-with-idle-timer, not the second. > So only the first blink cycle is affected. > > Doesn't that mean that the adjusted delay is applied only after the first command, but not after subsequent > commands? No, not AFAIK. The idle time starts anew after each command. Is there anything left to do about this, or can we close this bug? Thanks. ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point 2016-10-01 8:25 ` Eli Zaretskii @ 2016-10-01 16:11 ` Philipp Stephani 2016-10-01 17:29 ` Eli Zaretskii 2016-10-01 18:16 ` Philipp Stephani 0 siblings, 2 replies; 24+ messages in thread From: Philipp Stephani @ 2016-10-01 16:11 UTC (permalink / raw To: Eli Zaretskii; +Cc: 24372 [-- Attachment #1: Type: text/plain, Size: 2727 bytes --] Eli Zaretskii <eliz@gnu.org> schrieb am Sa., 1. Okt. 2016 um 10:25 Uhr: > > From: Philipp Stephani <p.stephani2@gmail.com> > > Date: Sun, 25 Sep 2016 19:09:52 +0000 > > Cc: 24372@debbugs.gnu.org > > > > > How about a variant of this below? It uses a fixed limitation from > > > below on the delay, but only for the first blink. (The value 0.2 was > > > found by experimentation, not sure if we need to add yet another > > > defcustom for that.) > > > > > > I don't think we should introduce magic numbers or further > customization options. > > > > It solves the problem, doesn't it? I don't mind very much if it were > > a defcustom, I just think no one would want to change it. > > > > OK, then it would be great to document the new behavior in the > documentation of `blink-cursor-delay' and also > > clarify what "starting to blink" means. > > Done. > Thanks! > > > > > I've attached another patch with the change I have in mind. > > > > > > This has a disadvantage of creating a new timer object each time, > > > which I think we'd like to avoid: too much consing. (Also, don't you > > > need to set the timer variable to nil when the timer is disabled?) > > > > > > I don't understand - the patch doesn't create any additional timers, > it only changes the initial delay of > > the > > > idle-timer. > > > > Each time blink-cursor--start-timer or blink-cursor--start-idle-timer > > is called, they create a new timer, right? And your patch makes us > > call these functions each time blinking is started or ended, right? > > > > No, the other patch is that it restarts the timers when the > customization options are set. Otherwise the options > > only become effective after a focus-out/focus-in event or something > similar that restarts the cursor. > > > > > My patch is identical, except is uses blink-cursor-interval as lower > bound. > > > > Of course. That's why I said it's a minor variant. > > > > There's another difference, though: in my patch we only limit the > > first argument to run-with-timer/run-with-idle-timer, not the second. > > So only the first blink cycle is affected. > > > > Doesn't that mean that the adjusted delay is applied only after the > first command, but not after subsequent > > commands? > > No, not AFAIK. The idle time starts anew after each command. > Indeed, the repeat argument of run-with-idle-timer is only checked for nil-ness and otherwise ignored. I'd suggest to pass something like :repeat or t to that argument so that readers are less confused. > > Is there anything left to do about this, or can we close this bug? > > The second patch (restarting the timers after the customization options changed) is still open, what about that one? [-- Attachment #2: Type: text/html, Size: 4778 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point 2016-10-01 16:11 ` Philipp Stephani @ 2016-10-01 17:29 ` Eli Zaretskii 2016-10-01 18:10 ` Philipp Stephani 2016-10-01 18:16 ` Philipp Stephani 1 sibling, 1 reply; 24+ messages in thread From: Eli Zaretskii @ 2016-10-01 17:29 UTC (permalink / raw To: Philipp Stephani; +Cc: 24372 > From: Philipp Stephani <p.stephani2@gmail.com> > Date: Sat, 01 Oct 2016 16:11:05 +0000 > Cc: 24372@debbugs.gnu.org > > Is there anything left to do about this, or can we close this bug? > > The second patch (restarting the timers after the customization options changed) is still open, what about > that one? Why is it needed? what doesn't still work right, now that I committed my changes? ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point 2016-10-01 17:29 ` Eli Zaretskii @ 2016-10-01 18:10 ` Philipp Stephani 2016-10-02 7:12 ` Eli Zaretskii 0 siblings, 1 reply; 24+ messages in thread From: Philipp Stephani @ 2016-10-01 18:10 UTC (permalink / raw To: Eli Zaretskii; +Cc: 24372 [-- Attachment #1: Type: text/plain, Size: 844 bytes --] Eli Zaretskii <eliz@gnu.org> schrieb am Sa., 1. Okt. 2016 um 19:29 Uhr: > > From: Philipp Stephani <p.stephani2@gmail.com> > > Date: Sat, 01 Oct 2016 16:11:05 +0000 > > Cc: 24372@debbugs.gnu.org > > > > Is there anything left to do about this, or can we close this bug? > > > > The second patch (restarting the timers after the customization options > changed) is still open, what about > > that one? > > Why is it needed? what doesn't still work right, now that I committed > my changes? > After customizing the variables, they don't become active immediately, only the next time the timers are restarted (e.g. after a focus-out/in event). The patches restarts the timers when setting the customization variables so that the new settings become active immediately. This is the root cause for the "After losing focus" part of the bug title. [-- Attachment #2: Type: text/html, Size: 1540 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point 2016-10-01 18:10 ` Philipp Stephani @ 2016-10-02 7:12 ` Eli Zaretskii 0 siblings, 0 replies; 24+ messages in thread From: Eli Zaretskii @ 2016-10-02 7:12 UTC (permalink / raw To: Philipp Stephani; +Cc: 24372 > From: Philipp Stephani <p.stephani2@gmail.com> > Date: Sat, 01 Oct 2016 18:10:22 +0000 > Cc: 24372@debbugs.gnu.org > > > The second patch (restarting the timers after the customization options changed) is still open, what > about > > that one? > > Why is it needed? what doesn't still work right, now that I committed > my changes? > > After customizing the variables, they don't become active immediately, only the next time the timers are > restarted (e.g. after a focus-out/in event). The patches restarts the timers when setting the customization > variables so that the new settings become active immediately. This is the root cause for the "After losing > focus" part of the bug title. I'm okay with pushing this to the master branch. Thanks. ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point 2016-10-01 16:11 ` Philipp Stephani 2016-10-01 17:29 ` Eli Zaretskii @ 2016-10-01 18:16 ` Philipp Stephani 2016-10-02 7:14 ` Eli Zaretskii 1 sibling, 1 reply; 24+ messages in thread From: Philipp Stephani @ 2016-10-01 18:16 UTC (permalink / raw To: Eli Zaretskii; +Cc: 24372 [-- Attachment #1.1: Type: text/plain, Size: 343 bytes --] Philipp Stephani <p.stephani2@gmail.com> schrieb am Sa., 1. Okt. 2016 um 18:11 Uhr: > Indeed, the repeat argument of run-with-idle-timer is only checked for > nil-ness and otherwise ignored. I'd suggest to pass something like :repeat > or t to that argument so that readers are less confused. > > I've attached another patch that does this. [-- Attachment #1.2: Type: text/html, Size: 850 bytes --] [-- Attachment #2: 0001-Use-a-simple-keyword-for-a-non-nil-argument.txt --] [-- Type: text/plain, Size: 1645 bytes --] From 08b386db1f4212ce90f726442fcf356885fb31ae Mon Sep 17 00:00:00 2001 From: Philipp Stephani <phst@google.com> Date: Sat, 1 Oct 2016 20:13:53 +0200 Subject: [PATCH] Use a simple keyword for a non-nil argument The second argument of `run-with-idle-timer' is Boolean, i.e. only nil and non-nil values are distinguished. Passing a number here is confusing. Pass a descriptive symbol instead. * lisp/frame.el (blink-cursor-mode, blink-cursor-check): Use :repeat symbol instead of number for second argument of `run-with-idle-timer' --- lisp/frame.el | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/lisp/frame.el b/lisp/frame.el index b13621a..d3b6353 100644 --- a/lisp/frame.el +++ b/lisp/frame.el @@ -2119,8 +2119,7 @@ blink-cursor-check ;; during command execution) if they set blink-cursor-delay ;; to a very small or even zero value. (run-with-idle-timer (max 0.2 blink-cursor-delay) - blink-cursor-delay - 'blink-cursor-start)))) + :repeat #'blink-cursor-start)))) (define-obsolete-variable-alias 'blink-cursor 'blink-cursor-mode "22.1") @@ -2157,8 +2156,7 @@ blink-cursor-mode ;; during command execution) if they set blink-cursor-delay ;; to a very small or even zero value. (run-with-idle-timer (max 0.2 blink-cursor-delay) - blink-cursor-delay - #'blink-cursor-start)))) + :repeat #'blink-cursor-start)))) \f ;; Frame maximization/fullscreen -- 2.10.0 ^ permalink raw reply related [flat|nested] 24+ messages in thread
* bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point 2016-10-01 18:16 ` Philipp Stephani @ 2016-10-02 7:14 ` Eli Zaretskii 2016-10-02 17:56 ` Philipp Stephani 0 siblings, 1 reply; 24+ messages in thread From: Eli Zaretskii @ 2016-10-02 7:14 UTC (permalink / raw To: Philipp Stephani; +Cc: 24372 > From: Philipp Stephani <p.stephani2@gmail.com> > Date: Sat, 01 Oct 2016 18:16:30 +0000 > Cc: 24372@debbugs.gnu.org > > Indeed, the repeat argument of run-with-idle-timer is only checked for nil-ness and otherwise ignored. I'd > suggest to pass something like :repeat or t to that argument so that readers are less confused. > > I've attached another patch that does this. Thanks, please push to master. ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point 2016-10-02 7:14 ` Eli Zaretskii @ 2016-10-02 17:56 ` Philipp Stephani 0 siblings, 0 replies; 24+ messages in thread From: Philipp Stephani @ 2016-10-02 17:56 UTC (permalink / raw To: Eli Zaretskii; +Cc: 24372 [-- Attachment #1: Type: text/plain, Size: 520 bytes --] Eli Zaretskii <eliz@gnu.org> schrieb am So., 2. Okt. 2016 um 09:14 Uhr: > > From: Philipp Stephani <p.stephani2@gmail.com> > > Date: Sat, 01 Oct 2016 18:16:30 +0000 > > Cc: 24372@debbugs.gnu.org > > > > Indeed, the repeat argument of run-with-idle-timer is only checked for > nil-ness and otherwise ignored. I'd > > suggest to pass something like :repeat or t to that argument so that > readers are less confused. > > > > I've attached another patch that does this. > > Thanks, please push to master. > Both pushed. [-- Attachment #2: Type: text/html, Size: 1184 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2016-10-02 17:56 UTC | newest] Thread overview: 24+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-09-05 19:16 bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point Philipp Stephani 2016-09-05 21:29 ` Clément Pit--Claudel 2016-09-06 16:03 ` Eli Zaretskii 2016-09-09 15:59 ` Philipp Stephani 2016-09-09 16:07 ` Eli Zaretskii 2016-09-09 16:20 ` Philipp Stephani 2016-09-09 16:29 ` Philipp Stephani 2016-09-09 17:18 ` Philipp Stephani 2016-09-09 18:59 ` Philipp Stephani 2016-09-10 7:21 ` Eli Zaretskii 2016-09-11 9:15 ` Philipp Stephani 2016-09-11 16:23 ` Eli Zaretskii 2016-09-11 17:37 ` Philipp Stephani 2016-09-11 19:18 ` Eli Zaretskii 2016-09-23 14:28 ` Eli Zaretskii 2016-09-25 19:09 ` Philipp Stephani 2016-10-01 8:25 ` Eli Zaretskii 2016-10-01 16:11 ` Philipp Stephani 2016-10-01 17:29 ` Eli Zaretskii 2016-10-01 18:10 ` Philipp Stephani 2016-10-02 7:12 ` Eli Zaretskii 2016-10-01 18:16 ` Philipp Stephani 2016-10-02 7:14 ` Eli Zaretskii 2016-10-02 17:56 ` Philipp Stephani
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.