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.