bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Philipp Stephani
Subject: bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point
Date: Fri, 09 Sep 2016 18:59:50 +0000



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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]