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

Previous Next

Full log

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

Previous Next

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