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