From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.bugs Subject: bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point Date: Sun, 25 Sep 2016 19:09:52 +0000 Message-ID: References: <83a8flaud3.fsf@gnu.org> <831t0t83br.fsf@gnu.org> <83mvjg8bk2.fsf@gnu.org> <8360q2be2b.fsf@gnu.org> <83twdm9re9.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114b30662cb752053d59c210 X-Trace: blaine.gmane.org 1474830692 4572 195.159.176.226 (25 Sep 2016 19:11:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 25 Sep 2016 19:11:32 +0000 (UTC) Cc: 24372@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Sep 25 21:11:28 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1boEpX-00079I-CB for geb-bug-gnu-emacs@m.gmane.org; Sun, 25 Sep 2016 21:11:15 +0200 Original-Received: from localhost ([::1]:40089 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1boEpU-00007B-Sb for geb-bug-gnu-emacs@m.gmane.org; Sun, 25 Sep 2016 15:11:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51753) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1boEpO-000075-Cn for bug-gnu-emacs@gnu.org; Sun, 25 Sep 2016 15:11:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1boEpK-0000UG-2M for bug-gnu-emacs@gnu.org; Sun, 25 Sep 2016 15:11:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57831) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1boEpJ-0000U9-Ux for bug-gnu-emacs@gnu.org; Sun, 25 Sep 2016 15:11:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1boEpJ-0000tG-Of for bug-gnu-emacs@gnu.org; Sun, 25 Sep 2016 15:11:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 25 Sep 2016 19:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24372 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 24372-submit@debbugs.gnu.org id=B24372.14748306113357 (code B ref 24372); Sun, 25 Sep 2016 19:11:01 +0000 Original-Received: (at 24372) by debbugs.gnu.org; 25 Sep 2016 19:10:11 +0000 Original-Received: from localhost ([127.0.0.1]:35788 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1boEoU-0000s5-MD for submit@debbugs.gnu.org; Sun, 25 Sep 2016 15:10:11 -0400 Original-Received: from mail-wm0-f48.google.com ([74.125.82.48]:33741) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1boEoS-0000rr-Jf for 24372@debbugs.gnu.org; Sun, 25 Sep 2016 15:10:09 -0400 Original-Received: by mail-wm0-f48.google.com with SMTP id d66so18652663wmf.0 for <24372@debbugs.gnu.org>; Sun, 25 Sep 2016 12:10:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9mpFotPO2c0RAAGax5qL/CDPqzy9+2zJTqGFJAKJUHQ=; b=X79FXJMwvg8wfAXbEP/12rRs6h4RTrT/8kBNp6n/R3uaF7n52cZNA7BobM5UPb9UWw FN/yJwZuDW90qyJs5Kc291z5l23VQKQpKxADTFwEIBqFMxy1ZbRnNum0NXRG0BcO0zaT 8F4B+mTtk5z+KiyEtQbgzpDiiEmEpdhujuuZ9ixkQl4fMQ63uzxvR5w4PW8V7/etYjZr Uj5OcMQMT89bg6XdwCMd0/iLqp7xIcJ33fnEf8ouepnocTDrLqKFiRz98+uSpU47Jmxs TmlVHivQ7PIHGI3gXZKBDtTnzbuugxlnquSCXJ2YXdIxH6fezzefZQk66GoTBEG1I0l1 KvxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9mpFotPO2c0RAAGax5qL/CDPqzy9+2zJTqGFJAKJUHQ=; b=RJhK7PTAU0/NUuxZjkSz0OtowiP8FtpGue0pMY1hBV3pz+Qa/3fwKRP92K27FyjmRY iz6eDROWMxyTstsmM1U9DTLgBEqmLrrGX3+8z+UqlahHjLXxGW/T6Vvd76RoBtvHsbuE /ZCI/Z0898UbGH6UU+0zkxvU0qzh/O1rWZIy/P9loybB3qMBjwJock15Mk16AIIf6KED KMPZUmPByKXJ3cUGImTWUaHAJsBXY6q3pJ4rxsE3GrS4nNyE5QLupr6z5IK9AaiWN0w2 cQTQFBaDmQwUDJdmrfggSuzBgfmmwSYb6Da+x7F/62UU5I9wP6vd2OV3sIRgZkW0O5jK ctJw== X-Gm-Message-State: AA6/9RlLPftEAg4MjsHF7L+pwO47tog5sOFkCXU+GNX2hyaHWEbJDJr3FwX8FYH75o6WSRteXO+ccQuULkvs8w== X-Received: by 10.28.72.10 with SMTP id v10mr11838590wma.52.1474830602645; Sun, 25 Sep 2016 12:10:02 -0700 (PDT) In-Reply-To: <83twdm9re9.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:123690 Archived-At: --001a114b30662cb752053d59c210 Content-Type: text/plain; charset=UTF-8 Eli Zaretskii schrieb am So., 11. Sep. 2016 um 21:19 Uhr: > > From: Philipp Stephani > > Date: Sun, 11 Sep 2016 17:37:36 +0000 > > Cc: 24372@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? --001a114b30662cb752053d59c210 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Eli Za= retskii <eliz@gnu.org> schrieb am= So., 11. Sep. 2016 um 21:19=C2=A0Uhr:
> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Sun, 11 Sep 2016 17:37:36 +0000
> Cc: 24372@debbugs.gnu.org
>
>=C2=A0 Using the maximum of blink-cursor-delay and blink-cursor-interva= l
>=C2=A0 effectively removes the user's ability of controlling the de= lay before
>=C2=A0 the cursor starts blinking when Emacs becomes idle, doesn't = it?
>
> Yes. I tried to figure out what the intention of blink-cursor-delay wa= s, 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.=C2=A0 blink-cursor-de= lay
is obviously how soon the user want the cursor to start blinking after
Emacs becomes idle.=C2=A0 That is orthogonal to the blink interval, which is in effect once the blinking begins.
=

Having the cursor hidden faster than it blinks sounds w= eird to me, but I guess it's OK since it's easy enough to change th= e option, so your interpretation sounds good to me as well.
=C2= =A0

>=C2=A0 How about a variant of this below? It uses a fixed limitation fr= om
>=C2=A0 below on the delay, but only for the first blink. (The value 0.2= was
>=C2=A0 found by experimentation, not sure if we need to add yet another=
>=C2=A0 defcustom for that.)
>
> I don't think we should introduce magic numbers or further customi= zation options.

It solves the problem, doesn't it?=C2=A0 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 docume= nt the new behavior in the documentation of `blink-cursor-delay' and al= so clarify what "starting to blink" means.
=C2=A0
=

>=C2=A0 > I've attached another patch with the change I have in m= ind.
>
>=C2=A0 This has a disadvantage of creating a new timer object each time= ,
>=C2=A0 which I think we'd like to avoid: too much consing. (Also, d= on't you
>=C2=A0 need to set the timer variable to nil when the timer is disabled= ?)
>
> I don't understand - the patch doesn't create any additional t= imers, 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?=C2=A0 And your patch makes us call these functions each time blinking is started or ended, right?

No, the other patch is tha= t it restarts the timers when the customization options are set. Otherwise = the options only become effective after a focus-out/focus-in event or somet= hing similar that restarts the cursor.
=C2=A0

> My patch is identical, except is uses blink-cursor-interval as lower b= ound.

Of course.=C2=A0 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 ap= plied only after the first command, but not after subsequent commands?=C2= =A0
--001a114b30662cb752053d59c210--