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

Previous Next

Full log

View this message in rfc822 format

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24372 <at> debbugs.gnu.org
Subject: bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point
Date: Sat, 01 Oct 2016 16:11:05 +0000

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> schrieb am Sa., 1. Okt. 2016 um 10:25 Uhr:

> > From: Philipp Stephani <p.stephani2 <at> gmail.com>
> > Date: Sun, 25 Sep 2016 19:09:52 +0000
> > Cc: 24372 <at> 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?

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