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: Sat, 01 Oct 2016 16:11:05 +0000 Message-ID: References: <83a8flaud3.fsf@gnu.org> <831t0t83br.fsf@gnu.org> <83mvjg8bk2.fsf@gnu.org> <8360q2be2b.fsf@gnu.org> <83twdm9re9.fsf@gnu.org> <831t00mq6w.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e0122f07cdca867053dcff51a X-Trace: blaine.gmane.org 1475338353 23899 195.159.176.226 (1 Oct 2016 16:12:33 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 1 Oct 2016 16:12:33 +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 Sat Oct 01 18:12:29 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 1bqMta-00046v-TO for geb-bug-gnu-emacs@m.gmane.org; Sat, 01 Oct 2016 18:12:15 +0200 Original-Received: from localhost ([::1]:56416 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bqMta-0000gm-AV for geb-bug-gnu-emacs@m.gmane.org; Sat, 01 Oct 2016 12:12:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37773) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bqMtU-0000gQ-ES for bug-gnu-emacs@gnu.org; Sat, 01 Oct 2016 12:12:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bqMtO-0004G7-FT for bug-gnu-emacs@gnu.org; Sat, 01 Oct 2016 12:12:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35105) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bqMtO-0004Fw-Bt for bug-gnu-emacs@gnu.org; Sat, 01 Oct 2016 12:12:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bqMtO-0006uT-2f for bug-gnu-emacs@gnu.org; Sat, 01 Oct 2016 12:12:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 01 Oct 2016 16:12:02 +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.147533828426517 (code B ref 24372); Sat, 01 Oct 2016 16:12:02 +0000 Original-Received: (at 24372) by debbugs.gnu.org; 1 Oct 2016 16:11:24 +0000 Original-Received: from localhost ([127.0.0.1]:41295 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bqMsl-0006tc-Rq for submit@debbugs.gnu.org; Sat, 01 Oct 2016 12:11:24 -0400 Original-Received: from mail-wm0-f54.google.com ([74.125.82.54]:34082) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bqMsj-0006tO-Jw for 24372@debbugs.gnu.org; Sat, 01 Oct 2016 12:11:22 -0400 Original-Received: by mail-wm0-f54.google.com with SMTP id 197so14763961wmk.1 for <24372@debbugs.gnu.org>; Sat, 01 Oct 2016 09:11:21 -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=nz3TCZygJr1almkSJohJ8WAAZDR152+TKcZwDecqf/c=; b=oB5W3ay8l1f77RwracMrys6mMruKIGeYlhTp5o690fmOb4OgfjMsCdcew4XizNMf7L j4rlNHTDlT4S9Zb4Fad6mhdSd1jW77++Oz5iLavklmjFk2hP+i7iJgTzP2DAgR8m5W/V 2TulzYToYNZWVOrdB8TeuBX3aAtJKwbCccU8jOo3lb+ZnasWKIBDCvUPtZC/SM1/QEkW UlKOzfXPedBLFzEpeIDn0xYwZ+VNb+PF2JRgZOgDgB+s3Qxsd5Y3EGcu8WE34fsv/Q29 UDhbeT48KsVnTXzNphgH8G+yFK7FWmKtWS6nL67KaOc5s2CHK9/XVjZ4iHaz/Ah2rXRO F8zg== 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=nz3TCZygJr1almkSJohJ8WAAZDR152+TKcZwDecqf/c=; b=VQsWHosh+y3Fe9p3yMLbSWnimAVQdYp+ulJ3m9Sm3cs+fIC8lzu09TkseSkQT4TL+p ZbkI3qTctlPaYfDMpsjcaWaRSkQzuiVlJIqgCar/pNJeWtdw6bH4lWHNU35F6myFTlot fq3ldE6cgd4jZ9Oql3XZ0RMAGpsPlXNUGwy/fk2BT+/NAGBfWMdQVK1MfNOvWJAnxBIV XhJyU1ex90oAjyT1+A3mRUvxkr1RNsfKhPzSsGOr0Jf2tVF2t1vCq5BrfqvYI1lReqIw 61Jp4EWGqnp1Fn1Ac2tCtnsOTmgiZzMeBJNRjVX1M5Hzj2ImXha8GGGhfD4/W4xbsFJR 5evA== X-Gm-Message-State: AA6/9RnYcZbMo4vEvOiANX0rE1oUodEEkoKMmHCbby7dC209qwICrh8WPKciKRKiQ1f0vMLeFIEmEIoFR1Dl9A== X-Received: by 10.194.170.163 with SMTP id an3mr11274451wjc.73.1475338275955; Sat, 01 Oct 2016 09:11:15 -0700 (PDT) In-Reply-To: <831t00mq6w.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:123861 Archived-At: --089e0122f07cdca867053dcff51a Content-Type: text/plain; charset=UTF-8 Eli Zaretskii schrieb am Sa., 1. Okt. 2016 um 10:25 Uhr: > > 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. > 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? --089e0122f07cdca867053dcff51a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Eli Za= retskii <eliz@gnu.org> schrieb am= Sa., 1. Okt. 2016 um 10:25=C2=A0Uhr:
> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Sun, 25 Sep 2016 19:09:52 +0000
> Cc: 24372@debbugs.gnu.org
>
>=C2=A0 > How about a variant of this below? It uses a fixed limitati= on from
>=C2=A0 > below on the delay, but only for the first blink. (The valu= e 0.2 was
>=C2=A0 > found by experimentation, not sure if we need to add yet an= other
>=C2=A0 > defcustom for that.)
>=C2=A0 >
>=C2=A0 > I don't think we should introduce magic numbers or furt= her customization options.
>
>=C2=A0 It solves the problem, doesn't it? I don't mind very muc= h if it were
>=C2=A0 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 documen= tation of `blink-cursor-delay' and also
> clarify what "starting to blink" means.

Done.

Thanks!
=
=C2=A0

>=C2=A0 > > I've attached another patch with the change I have= in mind.
>=C2=A0 >
>=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. (Al= so, don't you
>=C2=A0 > need to set the timer variable to nil when the timer is dis= abled?)
>=C2=A0 >
>=C2=A0 > I don't understand - the patch doesn't create any a= dditional timers, it only changes the initial delay of
>=C2=A0 the
>=C2=A0 > idle-timer.
>
>=C2=A0 Each time blink-cursor--start-timer or blink-cursor--start-idle-= timer
>=C2=A0 is called, they create a new timer, right? And your patch makes = us
>=C2=A0 call these functions each time blinking is started or ended, rig= ht?
>
> No, the other patch is that it restarts the timers when the customizat= ion options are set. Otherwise the options
> only become effective after a focus-out/focus-in event or something si= milar that restarts the cursor.
>
>=C2=A0 > My patch is identical, except is uses blink-cursor-interval= as lower bound.
>
>=C2=A0 Of course. That's why I said it's a minor variant.
>
>=C2=A0 There's another difference, though: in my patch we only limi= t the
>=C2=A0 first argument to run-with-timer/run-with-idle-timer, not the se= cond.
>=C2=A0 So only the first blink cycle is affected.
>
> Doesn't that mean that the adjusted delay is applied only after th= e first command, but not after subsequent
> commands?

No, not AFAIK.=C2=A0 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 th= at readers are less confused.
=C2=A0

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 ope= n, what about that one?=C2=A0
--089e0122f07cdca867053dcff51a--