GNU bug report logs - #24372
25.1.50; After losing focus, cursor is hidden when moving point

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 24372 in the body.
You can then email your comments to 24372 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.1.50; After losing focus, cursor is hidden when moving point
Date: Mon, 05 Sep 2016 21:16:40 +0200

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.

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Clément Pit--Claudel <clement.pit <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#24372: 25.1.50; After losing focus, cursor is hidden when
 moving point
Date: Mon, 5 Sep 2016 17:29:07 -0400

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, attachment)]

Message #11 received at 24372 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 24372 <at> debbugs.gnu.org
Subject: Re: bug#24372: 25.1.50;
 After losing focus, cursor is hidden when moving point
Date: Tue, 06 Sep 2016 19:03:20 +0300

> From: Philipp Stephani <p.stephani2 <at> 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?

Message #14 received at 24372 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24372 <at> debbugs.gnu.org
Subject: Re: bug#24372: 25.1.50; After losing focus, cursor is hidden when
 moving point
Date: Fri, 09 Sep 2016 15:59:02 +0000

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> schrieb am Di., 6. Sep. 2016 um 18:03 Uhr:

> > From: Philipp Stephani <p.stephani2 <at> 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.

[Message part 2 (text/html, inline)]

Message #17 received at 24372 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 24372 <at> debbugs.gnu.org
Subject: Re: bug#24372: 25.1.50; After losing focus, cursor is hidden when
 moving point
Date: Fri, 09 Sep 2016 19:07:04 +0300

> From: Philipp Stephani <p.stephani2 <at> gmail.com>
> Date: Fri, 09 Sep 2016 15:59:02 +0000
> Cc: 24372 <at> debbugs.gnu.org
> 
> Eli Zaretskii <eliz <at> gnu.org> schrieb am Di., 6. Sep. 2016 um 18:03 Uhr:
> 
>  > From: Philipp Stephani <p.stephani2 <at> 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?

Message #20 received at 24372 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24372 <at> debbugs.gnu.org
Subject: Re: bug#24372: 25.1.50; After losing focus, cursor is hidden when
 moving point
Date: Fri, 09 Sep 2016 16:20:19 +0000

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> schrieb am Fr., 9. Sep. 2016 um 18:07 Uhr:

> > From: Philipp Stephani <p.stephani2 <at> gmail.com>
> > Date: Fri, 09 Sep 2016 15:59:02 +0000
> > Cc: 24372 <at> debbugs.gnu.org
> >
> > Eli Zaretskii <eliz <at> gnu.org> schrieb am Di., 6. Sep. 2016 um 18:03 Uhr:
> >
> >  > From: Philipp Stephani <p.stephani2 <at> 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.

[Message part 2 (text/html, inline)]

Message #23 received at 24372 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24372 <at> debbugs.gnu.org
Subject: Re: bug#24372: 25.1.50; After losing focus, cursor is hidden when
 moving point
Date: Fri, 09 Sep 2016 16:29:23 +0000

[Message part 1 (text/plain, inline)]

Philipp Stephani <p.stephani2 <at> gmail.com> schrieb am Fr., 9. Sep. 2016 um
18:20 Uhr:

> Eli Zaretskii <eliz <at> gnu.org> schrieb am Fr., 9. Sep. 2016 um 18:07 Uhr:
>
> > From: Philipp Stephani <p.stephani2 <at> gmail.com>
> > Date: Fri, 09 Sep 2016 15:59:02 +0000
> > Cc: 24372 <at> debbugs.gnu.org
> >
> > Eli Zaretskii <eliz <at> gnu.org> schrieb am Di., 6. Sep. 2016 um 18:03 Uhr:
> >
> >  > From: Philipp Stephani <p.stephani2 <at> 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.

[Message part 2 (text/html, inline)]

Message #26 received at 24372 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24372 <at> debbugs.gnu.org
Subject: Re: bug#24372: 25.1.50; After losing focus, cursor is hidden when
 moving point
Date: Fri, 09 Sep 2016 17:18:12 +0000

[Message part 1 (text/plain, inline)]

Philipp Stephani <p.stephani2 <at> gmail.com> schrieb am Fr., 9. Sep. 2016 um
18:29 Uhr:

> Philipp Stephani <p.stephani2 <at> gmail.com> schrieb am Fr., 9. Sep. 2016 um
> 18:20 Uhr:
>
> Eli Zaretskii <eliz <at> gnu.org> schrieb am Fr., 9. Sep. 2016 um 18:07 Uhr:
>
> > From: Philipp Stephani <p.stephani2 <at> gmail.com>
> > Date: Fri, 09 Sep 2016 15:59:02 +0000
> > Cc: 24372 <at> debbugs.gnu.org
> >
> > Eli Zaretskii <eliz <at> gnu.org> schrieb am Di., 6. Sep. 2016 um 18:03 Uhr:
> >
> >  > From: Philipp Stephani <p.stephani2 <at> 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?

[Message part 2 (text/html, inline)]

Message #29 received at 24372 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24372 <at> debbugs.gnu.org
Subject: Re: bug#24372: 25.1.50; After losing focus, cursor is hidden when
 moving point
Date: Fri, 09 Sep 2016 18:59:50 +0000

[Message part 1 (text/plain, inline)]

Philipp Stephani <p.stephani2 <at> gmail.com> schrieb am Fr., 9. Sep. 2016 um
19:18 Uhr:

> Philipp Stephani <p.stephani2 <at> gmail.com> schrieb am Fr., 9. Sep. 2016 um
> 18:29 Uhr:
>
> Philipp Stephani <p.stephani2 <at> gmail.com> schrieb am Fr., 9. Sep. 2016 um
> 18:20 Uhr:
>
> Eli Zaretskii <eliz <at> gnu.org> schrieb am Fr., 9. Sep. 2016 um 18:07 Uhr:
>
> > From: Philipp Stephani <p.stephani2 <at> gmail.com>
> > Date: Fri, 09 Sep 2016 15:59:02 +0000
> > Cc: 24372 <at> debbugs.gnu.org
> >
> > Eli Zaretskii <eliz <at> gnu.org> schrieb am Di., 6. Sep. 2016 um 18:03 Uhr:
> >
> >  > From: Philipp Stephani <p.stephani2 <at> 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.

[Message part 2 (text/html, inline)]

Message #32 received at 24372 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 24372 <at> debbugs.gnu.org
Subject: Re: bug#24372: 25.1.50; After losing focus, cursor is hidden when
 moving point
Date: Sat, 10 Sep 2016 10:21:33 +0300

> From: Philipp Stephani <p.stephani2 <at> gmail.com>
> Date: Fri, 09 Sep 2016 17:18:12 +0000
> Cc: 24372 <at> 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'."

Message #35 received at 24372 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24372 <at> debbugs.gnu.org
Subject: Re: bug#24372: 25.1.50; After losing focus, cursor is hidden when
 moving point
Date: Sun, 11 Sep 2016 09:15:49 +0000

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> schrieb am Sa., 10. Sep. 2016 um 09:21 Uhr:

> > From: Philipp Stephani <p.stephani2 <at> gmail.com>
> > Date: Fri, 09 Sep 2016 17:18:12 +0000
> > Cc: 24372 <at> 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.

[Message part 2 (text/html, inline)]

[0001-Avoid-hiding-the-blinking-cursor-too-fast.patch (application/octet-stream, attachment)]

[0001-Restart-blink-cursor-timers-on-interval-changes.patch (application/octet-stream, attachment)]

Message #38 received at 24372 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 24372 <at> debbugs.gnu.org
Subject: Re: bug#24372: 25.1.50; After losing focus, cursor is hidden when
 moving point
Date: Sun, 11 Sep 2016 19:23:40 +0300

> From: Philipp Stephani <p.stephani2 <at> gmail.com>
> Date: Sun, 11 Sep 2016 09:15:49 +0000
> Cc: 24372 <at> 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))))
 

Message #41 received at 24372 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24372 <at> debbugs.gnu.org
Subject: Re: bug#24372: 25.1.50; After losing focus, cursor is hidden when
 moving point
Date: Sun, 11 Sep 2016 17:37:36 +0000

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> schrieb am So., 11. Sep. 2016 um 18:23 Uhr:

> > From: Philipp Stephani <p.stephani2 <at> gmail.com>
> > Date: Sun, 11 Sep 2016 09:15:49 +0000
> > Cc: 24372 <at> 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.

[Message part 2 (text/html, inline)]

Message #44 received at 24372 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 24372 <at> debbugs.gnu.org
Subject: Re: bug#24372: 25.1.50; After losing focus, cursor is hidden when
 moving point
Date: Sun, 11 Sep 2016 22:18:38 +0300

> From: Philipp Stephani <p.stephani2 <at> gmail.com>
> Date: Sun, 11 Sep 2016 17:37:36 +0000
> Cc: 24372 <at> 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.

Message #49 received at 24372-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: p.stephani2 <at> gmail.com
Cc: 24372-done <at> debbugs.gnu.org
Subject: Re: bug#24372: 25.1.50; After losing focus, cursor is hidden when
 moving point
Date: Fri, 23 Sep 2016 17:28:22 +0300

> Date: Sun, 11 Sep 2016 22:18:38 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 24372 <at> 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.

Message #52 received at 24372 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24372 <at> debbugs.gnu.org
Subject: Re: bug#24372: 25.1.50; After losing focus, cursor is hidden when
 moving point
Date: Sun, 25 Sep 2016 19:09:52 +0000

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> schrieb am So., 11. Sep. 2016 um 21:19 Uhr:

> > From: Philipp Stephani <p.stephani2 <at> gmail.com>
> > Date: Sun, 11 Sep 2016 17:37:36 +0000
> > Cc: 24372 <at> 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?

[Message part 2 (text/html, inline)]

Message #55 received at 24372 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 24372 <at> debbugs.gnu.org
Subject: Re: bug#24372: 25.1.50; After losing focus, cursor is hidden when
 moving point
Date: Sat, 01 Oct 2016 11:25:11 +0300

> From: Philipp Stephani <p.stephani2 <at> gmail.com>
> Date: Sun, 25 Sep 2016 19:09:52 +0000
> Cc: 24372 <at> 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.

Message #58 received at 24372 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24372 <at> debbugs.gnu.org
Subject: Re: bug#24372: 25.1.50; After losing focus, cursor is hidden when
 moving point
Date: Sat, 01 Oct 2016 16:11:05 +0000

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> schrieb am Sa., 1. Okt. 2016 um 10:25 Uhr:

> > From: Philipp Stephani <p.stephani2 <at> gmail.com>
> > Date: Sun, 25 Sep 2016 19:09:52 +0000
> > Cc: 24372 <at> 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?

[Message part 2 (text/html, inline)]

Message #61 received at 24372 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 24372 <at> debbugs.gnu.org
Subject: Re: bug#24372: 25.1.50; After losing focus, cursor is hidden when
 moving point
Date: Sat, 01 Oct 2016 20:29:35 +0300

> From: Philipp Stephani <p.stephani2 <at> gmail.com>
> Date: Sat, 01 Oct 2016 16:11:05 +0000
> Cc: 24372 <at> 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?

Message #64 received at 24372 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24372 <at> debbugs.gnu.org
Subject: Re: bug#24372: 25.1.50; After losing focus, cursor is hidden when
 moving point
Date: Sat, 01 Oct 2016 18:10:22 +0000

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> schrieb am Sa., 1. Okt. 2016 um 19:29 Uhr:

> > From: Philipp Stephani <p.stephani2 <at> gmail.com>
> > Date: Sat, 01 Oct 2016 16:11:05 +0000
> > Cc: 24372 <at> 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.

[Message part 2 (text/html, inline)]

Message #67 received at 24372 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24372 <at> debbugs.gnu.org
Subject: Re: bug#24372: 25.1.50; After losing focus, cursor is hidden when
 moving point
Date: Sat, 01 Oct 2016 18:16:30 +0000

[Message part 1 (text/plain, inline)]

Philipp Stephani <p.stephani2 <at> 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.

[Message part 2 (text/html, inline)]

[0001-Use-a-simple-keyword-for-a-non-nil-argument.txt (text/plain, attachment)]

Message #70 received at 24372 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 24372 <at> debbugs.gnu.org
Subject: Re: bug#24372: 25.1.50; After losing focus, cursor is hidden when
 moving point
Date: Sun, 02 Oct 2016 10:12:24 +0300

> From: Philipp Stephani <p.stephani2 <at> gmail.com>
> Date: Sat, 01 Oct 2016 18:10:22 +0000
> Cc: 24372 <at> 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.

Message #73 received at 24372 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 24372 <at> debbugs.gnu.org
Subject: Re: bug#24372: 25.1.50; After losing focus, cursor is hidden when
 moving point
Date: Sun, 02 Oct 2016 10:14:18 +0300

> From: Philipp Stephani <p.stephani2 <at> gmail.com>
> Date: Sat, 01 Oct 2016 18:16:30 +0000
> Cc: 24372 <at> 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.

Message #76 received at 24372 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24372 <at> debbugs.gnu.org
Subject: Re: bug#24372: 25.1.50; After losing focus, cursor is hidden when
 moving point
Date: Sun, 02 Oct 2016 17:56:27 +0000

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> schrieb am So., 2. Okt. 2016 um 09:14 Uhr:

> > From: Philipp Stephani <p.stephani2 <at> gmail.com>
> > Date: Sat, 01 Oct 2016 18:16:30 +0000
> > Cc: 24372 <at> 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.

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.