bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point

bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point

[Philipp Stephani]

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.

bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point

[Clément Pit--Claudel]

[-- 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 --]

bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point

[Eli Zaretskii]

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

bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point

[Philipp Stephani]

[-- 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 --]

bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point

[Eli Zaretskii]

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

bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point

[Philipp Stephani]

[-- 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 --]

bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point

[Philipp Stephani]

[-- 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 --]

bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point

[Philipp Stephani]

[-- 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 --]

bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point

[Philipp Stephani]

[-- 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 --]

bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point

[Eli Zaretskii]

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

bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point

[Philipp Stephani]

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

bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point

[Eli Zaretskii]

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

bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point

[Philipp Stephani]

[-- 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 --]

bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point

[Eli Zaretskii]

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

bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point

[Eli Zaretskii]

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

bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point

[Philipp Stephani]

[-- 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 --]

bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point

[Eli Zaretskii]

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

bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point

[Philipp Stephani]

[-- 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 --]

bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point

[Eli Zaretskii]

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

bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point

[Philipp Stephani]

[-- 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 --]

bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point

[Philipp Stephani]

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

bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point

[Eli Zaretskii]

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

bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point

[Eli Zaretskii]

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

bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point

[Philipp Stephani]

[-- 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 --]