From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point Date: Sat, 01 Oct 2016 11:25:11 +0300 Message-ID: <831t00mq6w.fsf@gnu.org> References: <83a8flaud3.fsf@gnu.org> <831t0t83br.fsf@gnu.org> <83mvjg8bk2.fsf@gnu.org> <8360q2be2b.fsf@gnu.org> <83twdm9re9.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1475310389 14234 195.159.176.226 (1 Oct 2016 08:26:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 1 Oct 2016 08:26:29 +0000 (UTC) Cc: 24372@debbugs.gnu.org To: Philipp Stephani Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Oct 01 10:26:25 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 1bqFcc-0001tY-MN for geb-bug-gnu-emacs@m.gmane.org; Sat, 01 Oct 2016 10:26:14 +0200 Original-Received: from localhost ([::1]:48724 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bqFca-0007oQ-F2 for geb-bug-gnu-emacs@m.gmane.org; Sat, 01 Oct 2016 04:26:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59718) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bqFcT-0007o7-67 for bug-gnu-emacs@gnu.org; Sat, 01 Oct 2016 04:26:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bqFcP-0003C0-RH for bug-gnu-emacs@gnu.org; Sat, 01 Oct 2016 04:26:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:34036) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bqFcP-0003Bw-OX for bug-gnu-emacs@gnu.org; Sat, 01 Oct 2016 04:26:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bqFcP-0000Pw-Ju for bug-gnu-emacs@gnu.org; Sat, 01 Oct 2016 04:26:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 01 Oct 2016 08:26: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.14753103141540 (code B ref 24372); Sat, 01 Oct 2016 08:26:01 +0000 Original-Received: (at 24372) by debbugs.gnu.org; 1 Oct 2016 08:25:14 +0000 Original-Received: from localhost ([127.0.0.1]:40226 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bqFbe-0000Om-DV for submit@debbugs.gnu.org; Sat, 01 Oct 2016 04:25:14 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:40435) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bqFbd-0000Ob-Qe for 24372@debbugs.gnu.org; Sat, 01 Oct 2016 04:25:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bqFbV-0002md-Gp for 24372@debbugs.gnu.org; Sat, 01 Oct 2016 04:25:08 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33003) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bqFbV-0002mG-Dc; Sat, 01 Oct 2016 04:25:05 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1533 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bqFbT-0006Sd-6w; Sat, 01 Oct 2016 04:25:03 -0400 In-reply-to: (message from Philipp Stephani on Sun, 25 Sep 2016 19:09:52 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:123820 Archived-At: > From: Philipp Stephani > Date: Sun, 25 Sep 2016 19:09:52 +0000 > Cc: 24372@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. > > > 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. Is there anything left to do about this, or can we close this bug? Thanks.