From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: jit-lock-antiblink-grace Date: Sat, 12 Oct 2019 22:55:29 +0100 Message-ID: References: <834l0enw8c.fsf@gnu.org> <83y2xqm6m4.fsf@gnu.org> <83o8ymlzkk.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000034ff8a0594bdb2df" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="156854"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Stefan Monnier , emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 12 23:55:59 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iJPMk-000eah-Ow for ged-emacs-devel@m.gmane.org; Sat, 12 Oct 2019 23:55:59 +0200 Original-Received: from localhost ([::1]:36240 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iJPMi-00045s-Vt for ged-emacs-devel@m.gmane.org; Sat, 12 Oct 2019 17:55:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36994) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iJPMc-00045g-Ef for emacs-devel@gnu.org; Sat, 12 Oct 2019 17:55:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iJPMa-0008GR-Gf for emacs-devel@gnu.org; Sat, 12 Oct 2019 17:55:50 -0400 Original-Received: from mail-io1-xd35.google.com ([2607:f8b0:4864:20::d35]:40286) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iJPMW-0008Fx-SN; Sat, 12 Oct 2019 17:55:46 -0400 Original-Received: by mail-io1-xd35.google.com with SMTP id h144so28925608iof.7; Sat, 12 Oct 2019 14:55:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+FN0NX3n8Z/3o0VIdh1t3im80aGmYaWrfBpDV8m6Ky4=; b=fAKj8FyvGqHr0vaCTug0T+xNpwx4BiK/AK7dHj1gK3RiW6VUn+vH/Z708lkeHEgo0d ISO6LO2kDa3pCAVz+EFuW1v1D3azOmKCkXfZvi+X+1LGg1A0Q0pw3e2frO5DpNnnAf+P xLO+MdNsj7Mj/n5LQZG216x6qARxTUaVrl3e1aFLqmKLdBC3IAO7SH+2iHvkWXBGBw0C j4SL/CoEVKufZ2r+DmW9Ty/a0Tqfl70gwvPGgzZ5YYTZ8ea2TcQmXeFj7QTRqsxbfE4D UKrVUAUP78RQ5x+W9YXY8zeEPmhkfzRod+io48dVjVLVYp81Uc5O0VYXm69cXCafi8IS AHiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+FN0NX3n8Z/3o0VIdh1t3im80aGmYaWrfBpDV8m6Ky4=; b=VQn7TyZirEGkkdTooLydhfyua7/A2CJgbA931/rYjfBHpHR0vzOG7VQQqDXO6prAd0 pzUbABn9P03+kTDDMsS+xrxt1SpGvwGW3Q0po5J3xBBBwdOcbj5Heec974TD2Dz5Ch/B WHJ/HpPiVWdCzdxq7/cqbJGcRi9UgdY0nOOktqwZLc2QUOK+cyIx4PYt23Kt94HZuSym 7EwNQONrd4j+HufNXon3U8R7oQ2AggEL0IQBl6wudpci3gJp1UcKFWvUygLOZTPnflxm 3nxyVj+ByKqIM84McoHVkzUTDCjz/Sg2WMcRXKZkB/nPig2PFaK5Vin/f5Icf12L3TOf tD4A== X-Gm-Message-State: APjAAAX9jcAQnzjP4Qf82ROlBzWUTOTr1H5gUmcvEiAxF8ZKv+o5TrtV 7uiq0micA85tORH+q2Zn0EO/4gMHd6oEw2oER1ggefk5Ti4= X-Google-Smtp-Source: APXvYqw4ZvcOf8GJiy0AImSAhkiue415tXu/Ru/3OyO71PeFcTKU13xzVsRYR0X8CvEcgAm4NAmMQvNV5tB/6kBR4NA= X-Received: by 2002:a6b:4f03:: with SMTP id d3mr15849274iob.199.1570917343099; Sat, 12 Oct 2019 14:55:43 -0700 (PDT) In-Reply-To: <83o8ymlzkk.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::d35 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:240936 Archived-At: --00000000000034ff8a0594bdb2df Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Oct 12, 2019 at 5:05 PM Eli Zaretskii wrote: > > > From: Jo=C3=A3o T=C3=A1vora > > Date: Sat, 12 Oct 2019 15:23:08 +0100 > > Cc: emacs-devel , Stefan Monnier < monnier@iro.umontreal.ca> > > > > > The post-command-hook is notorious for slowing down cursor motion. > > Probably a fame unjustly inherited from functions that people put there= . > Not people: our own minor modes. Last I checked you and I were people too (else you give a damn good impression... :-) > > > I'm not sure I understand. What I wanted to suggest is that when the > > > new defcustom is nil (which seems to be the way to disable this > > > feature), the post-command-hook should not be added. > > > > If we do it like that, it will take effect only when jit-lock-mode is > > toggled. Therefore, if you set the variable to nil in a buffer you wil= l > > only see the desired effects in post-command-hook after additionally > > toggling jit-lock-mode on and off again. > > It doesn't have to be like that. It depends on how you arrange for > the hook not to be added. I can only see one reasonably hacky way to arrange for: * the feature to be controlled via this variable * the hook to disappear from p-c-h when the variable is nil and that's to use an "ensure hook present/gone" technique somewhere in the places of the jit mode that the code is guaranteed to pass before the feature would kick in. It would feel hacky and so unjustified before any kind of performance measurements. Did you mean something like that or something completely different that I'm not following? > All I wanted to say was that the goal is almost in reach, and that you > don't need to give up in this case. > But if you think it's too hard, then okay, I will write the text when > the time comes. And all I wanted to say is that something a little more constructive, like a concrete suggestion, is whitin reach. I will try again in the next iteration. Shorter, more to the point in NEWS and idiot-proof spec in the docstring. > > > It's a backward-incompatible behavior, and is not being developed due > > > to bug reports, so why make it the default right from the start? It > > > also slows down cursor motion (which should probably be in the doc > > > string as well). > > > > Regarding slowdown, we have to check by how much. Regarding the > > pertinence of the modificaiton, there are mode-specific modifications > > with (IMO much worse) backward-incompatible behaviour being made to > > modes like to c-mode to circumvent precisely this problem. Perhaps you > > could weigh in on the pertinence of those on-by-default (and moreover > > impossible-to-turn-off) alternatives, too. Although those other > > modifications target a reduced subset of modes, indeed precisely becaus= e > > of that fact, I think it's better that Emacs provides an effective and > > more generic solution to this problem. > > When I find a backward-incompatible change, I usually do try to see if > it's justified. So I think I already do what you ask me to do in > those other cases. >From what I can remember, you didn't weigh in on the specific case I was referring to (the one being brought up again in the side thread), where c-mode was modified in a truly backward-incompatible, uncustomizable way to address a related problem. Furthermore, calling my proposed change "backward-incompatible" is something I don't fully understand. Perhaps you can clarify: what behaviours, actions, etc. were observed before that aren't observed now? I only count the the hypothetical slowdown and the presumably benefic effects of the feature itself. > That's what I thought, but then I think we should rather talk about > "unbalanced quotes", which should catch both cases without involving > EOL. OK. > > > Why not just lose the message? > > > > Huh? If I lose the message the form becomes a noop. > > I meant lose the entire form. Why should a user care that there was > already a timer? Will that adversely affect the code in some way? > > Run-time consistency assertions are useful, right? > > Only as a debug option, Yes, I agree. But there is really no "debug" in Emacs, only debug-on-error. I also suggested 'warn' with a debug level. So that whoever refactors the code can be alerted to an inconsistency. Grepping for "internal error" in the Emacs source brings up many cases that I judge to have more or less the same causes. Anyway, if I'm going to try and rewrite the code again to get rid of post-command-hook perhaps the form goes away naturally and we can focus on something else. Jo=C3=A3o --00000000000034ff8a0594bdb2df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Oct 12, 2019 at 5:05 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > F= rom: Jo=C3=A3o T=C3=A1vora <joao= tavora@gmail.com>
> > Date: Sat, 12 Oct 2019 15:23:08 +0100=
> > Cc: emacs-devel <em= acs-devel@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca>
> >
> > &= gt; The post-command-hook is notorious for slowing down cursor motion.
&= gt; > Probably a fame unjustly inherited from functions that people put = there.
> Not people: our own minor modes.

Last I checked you a= nd I were people too (else you give a damn good
impression... :-)
> > > I'm not sure I understand.=C2=A0 What I wanted to sugg= est is that when the
> > > new defcustom is nil (which seems to= be the way to disable this
> > > feature), the post-command-ho= ok should not be added.
> >
> > If we do it like that, it= will take effect only when jit-lock-mode is
> > toggled.=C2=A0 Th= erefore, if you set the variable to nil in a buffer you will
> > o= nly see the desired effects in post-command-hook after additionally
>= > toggling jit-lock-mode on and off again.
>
> It doesn'= ;t have to be like that.=C2=A0 It depends on how you arrange for
> th= e hook not to be added.

I can only see one reasonably hacky way to a= rrange for:

* the feature to be controlled via this variable
* th= e hook to disappear from p-c-h when the variable is nil

and that'= ;s to use an "ensure hook present/gone" technique somewhere inthe places of the jit mode that the code is guaranteed to pass before
t= he feature would kick in.=C2=A0 It would feel hacky and so unjustified
b= efore any kind of performance measurements.=C2=A0 Did you mean somethinglike that or something completely different that I'm not following?
> All I wanted to say was that the goal is almost in reach, and tha= t you
> don't need to give up in this case.
> But if you th= ink it's too hard, then okay, I will write the text when
> the ti= me comes.

And all I wanted to say is that something a little more co= nstructive,
like a concrete suggestion, is whitin reach.=C2=A0 I will tr= y again in the
next iteration.=C2=A0 Shorter, more to the point in NEWS = and idiot-proof spec
in the docstring.

> > > It's a = backward-incompatible behavior, and is not being developed due
> >= > to bug reports, so why make it the default right from the start?=C2= =A0 It
> > > also slows down cursor motion (which should probab= ly be in the doc
> > > string as well).
> >
> &g= t; Regarding slowdown, we have to check by how much.=C2=A0 Regarding the> > pertinence of the modificaiton, there are mode-specific modifica= tions
> > with (IMO much worse) backward-incompatible behaviour be= ing made to
> > modes like to c-mode to circumvent precisely this = problem.=C2=A0 Perhaps you
> > could weigh in on the pertinence of= those on-by-default (and moreover
> > impossible-to-turn-off) alt= ernatives, too.=C2=A0 Although those other
> > modifications targe= t a reduced subset of modes, indeed precisely because
> > of that = fact, I think it's better that Emacs provides an effective and
> = > more generic solution to this problem.
>
> When I find a b= ackward-incompatible change, I usually do try to see if
> it's ju= stified.=C2=A0 So I think I already do what you ask me to do in
> tho= se other cases.

From what I can remember, you didn't weigh in on= the specific case I was
referring to (the one being brought up again in= the side thread), where
c-mode was modified in a truly backward-incompa= tible, uncustomizable way
to address a related problem.=C2=A0 Furthermor= e, calling my proposed change
"backward-incompatible" is somet= hing I don't fully understand.=C2=A0 Perhaps
you can clarify: what b= ehaviours, actions, etc. were observed before
that aren't observed n= ow?=C2=A0 I only count the the hypothetical slowdown
and the presumably = benefic effects of the feature itself.

> That's what I though= t, but then I think we should rather talk about
> "unbalanced qu= otes", which should catch both cases without involving
> EOL.
OK.

> > > Why not just lose the message?
> ><= br>> > Huh? If I lose the message the form becomes a noop.
>> I meant lose the entire form.=C2=A0 Why should a user care that there= was
> already a timer?=C2=A0 Will that adversely affect the code in = some way?

> > Run-time consistency assertions are useful, righ= t?
>
> Only as a debug option,

Yes, I agree.=C2=A0 But t= here is really no "debug" in Emacs, only
debug-on-error.=C2=A0= I also suggested 'warn' with a debug level.=C2=A0 So that
whoev= er refactors the code can be alerted to an inconsistency.=C2=A0 Greppingfor "internal error" in the Emacs source brings up many cases th= at I
judge to have more or less the same causes.

Anyway, if I'= ;m going to try and rewrite the code again to get rid of
post-command-ho= ok perhaps the form goes away naturally and we can focus
on something el= se.

Jo=C3=A3o
--00000000000034ff8a0594bdb2df--