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 15:23:08 +0100 Message-ID: References: <834l0enw8c.fsf@gnu.org> <83y2xqm6m4.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000006fd7ac0594b76019" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="195650"; 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 16:24:50 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 1iJIKA-000ojd-Fp for ged-emacs-devel@m.gmane.org; Sat, 12 Oct 2019 16:24:50 +0200 Original-Received: from localhost ([::1]:33532 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iJIK4-00068J-1f for ged-emacs-devel@m.gmane.org; Sat, 12 Oct 2019 10:24:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40306) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iJIIr-00068A-9N for emacs-devel@gnu.org; Sat, 12 Oct 2019 10:23:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iJIIo-0000q2-Kj for emacs-devel@gnu.org; Sat, 12 Oct 2019 10:23:29 -0400 Original-Received: from mail-io1-xd2a.google.com ([2607:f8b0:4864:20::d2a]:42307) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iJIIk-0000mr-Uh; Sat, 12 Oct 2019 10:23:23 -0400 Original-Received: by mail-io1-xd2a.google.com with SMTP id n197so27493639iod.9; Sat, 12 Oct 2019 07:23:22 -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=/se6Itshe3peDHfEi3KWgqCb0155ofgsYRjmhVffFeA=; b=XbHGYyUgjluFfzRKaCHhg55/9T20h+ruQ9gFlYgQuf3BbXobsCyyJGHovk4z1Ley2n JOHrdb3s1lm9uJuImuYoc/eQ1e+b1lLq03GxCrNA7XiG6jgwnljd7XypN0tZssb2ZevV 81By2gTQHZR3QOlpBWufEnAijmfF21tScWhekRuB2pWNkNkg/lcWYiY9kagwCT9h0T7O 1SsEX8Lhf9MT6J649oRFsoGABGRLIDowBSpPcVlJAJU1sF3QgM41Ab+NpJ41Pi/+H3+a 192SxcvnN5M+JAtEC1SpeH2nYVX9tLEAg5c5jxavzpUbfti6SqZVPL6Yi704ANmFYCgu rcMw== 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=/se6Itshe3peDHfEi3KWgqCb0155ofgsYRjmhVffFeA=; b=Gb4zu7eS/WAieBAxg840dfnTGcSPCxTduMf8K7G3A4pAiutetiVuKrbvrx4+YBHPtA E/4xnVIYlWFyryjMPhtQVwOlKotafLrlqmm9yIYR5ZDh6xitdilh7T7ij6asgayJ7LiW hzUxeOJmMmiohuhxS28M7SFG63C6h0vOFwIjIOVdfDy05Q7gPHP+tbF1fEaU0mHfBUlF fZO6j7ALzta7tEXXq+0wkeTSDlx4mieJ/dQghirpQsBd3CDyt2D+1XlfWYxQHyrkqYrG 7RD1JfgXlQgHHKdzbRHLSSqaYHNM01WByCzVYcSV2mTgyiRtGwi3Nnl/JFIGK2MiBccl saFQ== X-Gm-Message-State: APjAAAUf0ggAxRkD/2Gi/XkyEcra+Oyw2HtiFhmzRytBFZ8CLc+uw8H0 e52KpBFDdPTC4hRFQQzHmZGoCkW88jggMXzlyUe5JrPrKrs= X-Google-Smtp-Source: APXvYqxTa3YhxGB097wvLXsXh2grAaRR7LGrsyfQpPiKx+4papjjDRmat67G7i4Ujnq2fLgFR/KZUAlHlTING8QovoE= X-Received: by 2002:a5d:9e02:: with SMTP id h2mr8143102ioh.137.1570890201419; Sat, 12 Oct 2019 07:23:21 -0700 (PDT) In-Reply-To: <83y2xqm6m4.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::d2a 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:240918 Archived-At: --0000000000006fd7ac0594b76019 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Oct 12, 2019 at 2:33 PM Eli Zaretskii wrote: > The post-command-hook is notorious for slowing down cursor motion. Probably a fame unjustly inherited from functions that people put there. > > Can you tell me more about the kinds of files you're anxious about > > and exact meaning of "paging"? Is it C-n'ing from the first line to > > the last? I could benchmark. > > C-n and C-v. Try C mode for starters, and then Emacs Lisp. OK, will do. > > > If there's no better solution than using that over-used hook, > > > > My very first version relied on an extension of the existing > > jit-lock-context-time, but I seem to remember it broke down here and > > there sometimes. I agreed with Stefan (possibly off-list) to use a > > post-command-hook, which is safer. But I can have a look at the > > original version and re-study those problems more closely. > > We also have display-related hooks. If you could use one of them, > that might be better, because one could generally type quite a few > commands before redisplay kicks in, and post-command-hook runs once > for every command. OK, will try that. > > > then at the very least we should give users a way of NOT adding a > > > post-command-hook when this feature is disabled. > > > > Given that I intend for this to be controlled via a customization > > variable, I only see it done via a `:set` hook or something like that. > > 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 will only see the desired effects in post-command-hook after additionally toggling jit-lock-mode on and off again. > In addition, I think major modes which present read-only buffers > should also disable this feature, and not add to post-command-hook. OK. > > > > +Setting this to a positive number of seconds helps avoid the > > > > +fontification "blinking" behaviour observed when adding temporaril= y > > > > +unterminated strings to source code. If the user has recently created > > > > +an unterminated string at EOL, jit fontification allows this idle > > > > +"grace" period to elapse before deciding it is a multi-line string and > > > > +fontifying the remainder of the buffer accordingly. > > > > > > This should be simplified and shortened. (In general, copy/paste of > > > doc strings into NEWS is not a good idea.) In particular, if the > > > default is to have this behavior (see below), the NEWS entry should > > > tell how to disable that. > > > > OK. Supposing you've already already gotten the idea, I invite you to > > submit a suggestion. > > I'd rather had you try. I think it's important that more people can > write good documentation, and I think in this case it isn't hard. You > can use other entries as examples. Naturally Eli, I hope you believe me that I try hard, indeed very hard, to write good documentation. I spend I good deal of time in it, sometimes much more than writing the code itself. If I sometimes fail to meet your standards, it's to be expected, (1) because they are high (which is very good) and (2) because we all have unwritten guidelines of what we believe is good style. I tried many versions (many more than you can probably get evidence of in the emacs-diffs ML) and settled on the one I presented. With requesting a suggestion from you, I am not taking an adversarial position, simply a way forward on what I (and many) consider to be a difficult and underestimated problem in programming. Also, English is not my first language, and Emacs-english has certain rules that you will much more familiar with. > > > (I question the wisdom of making this the default behavior, btw.) > > > > What's bothering you? > > 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 because of that fact, I think it's better that Emacs provides an effective and more generic solution to this problem. > > > I don't understand the "at EOL" part: isn't any unterminated string > > > appear as if it is "at EOL"? > > > > An unterminated string at EOL might be terminated somewhere _after_ EOL= , > > i.e. a perfectly legitimate (as "in your intentions") multiline string. > > I still don't think I understand what would constitute an > "unterminated string at EOL", then. Could you show two examples, one > where there is such a string, the other where there isn't? Buffer 1: l1: foofoo "bar < unterminated string at EOL, terminated multiline string l2: barbar" foofoo Buffer 2: l1: foofoo "bar < unterminated string at EOL, unterminated strin= g l2: barbar It's an informal way of referring to both situations at line 1. If I said "unterminated string" the user might be led to believe it doesn't apply to the situation of buffer 1. But the fact that it confused you so much is probably a hint it's not a great idea. Again, let me humbly request a suggestion for rephrasing :-) > > Moreover this is a hint as to how the system is implemented, which some > > users may appreciate. > This kind of stuff should be in comments, not ion doc strings, IMO. Maybe. Sometimes such hints are good because they help consolidate the user's prediction of timer-based behaviour. > > > Please don't use such cryptic variable names, at least not on the fil= e > > > level (preferably also not locally inside functions). > > > > The docstring explains the abbreviation. I'm afraid that given current > > naming practice (prefix, double dash, sub-feature) I couldn't do much > > better. I think jit-lock--antiblink-l-b-p is a better name than > > jit-lock--antiblink-pos, or jit-lock--pos, because it makes the reader > > "chase" the doc and learn of the exact meaning of the abbreviation. > > The variables don't need to use jit-lock--antiblink- prefix, they > could use jit-lock-- prefix instead. jit-lock--last-line-begpos > doesn't sound too long to me, for example. It doesn't, but then I lose the ability to i-search for jit-lock--antiblink and see its related variables. It's all trade-offs. But I'll put in the longer names or use a plist, don't worry. > > > > + (when jit-lock--antiblink-grace-timer > > > > + (message "internal warning: `jit-lock--antiblink-grace-timer' not null")) > > > > > > We should in general avoid calling 'message' here, because such a > > > message will appear after every command, which is a nuisance. Is thi= s > > > really needed? > > > > This is an internal consistency check, i.e. a run-time assertion. It > > should never happen, except when the program is buggy. I had this set > > to 'warn', but Stefan suggested I change it. What do you suggest? > > Perhaps I could warn and turn off the feature. > > Why not just lose the message? Huh? If I lose the message the form becomes a noop. > Why is it important to display it? Run-time consistency assertions are useful, right? I can change 'message' to whatever you think has the optimimum noise-level for such an assertion ('warn' with a :debug level, maybe?) I can also remove the form completely and we just pray that noone every breaks the mechanism in subtle ways :-) Jo=C3=A3o --0000000000006fd7ac0594b76019 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Oct 12, 2019 at 2:33 PM Eli Zaretskii <eliz@gnu.org> wrote:

> The post-c= ommand-hook is notorious for slowing down cursor motion.

Probably a = fame unjustly inherited from functions that people put there.

> &= gt; Can you tell me more about the kinds of files you're anxious about<= br>> > and exact meaning of "paging"?=C2=A0 Is it C-n'i= ng from the first line to
> > the last?=C2=A0 I could benchmark.>
> C-n and C-v.=C2=A0 Try C mode for starters, and then Emacs L= isp.

OK, will do.

> > > If there's no better so= lution than using that over-used hook,
> >
> > My very fi= rst version relied on an extension of the existing
> > jit-lock-co= ntext-time, but I seem to remember it broke down here and
> > ther= e sometimes.=C2=A0 I agreed with Stefan (possibly off-list) to use a
>= ; > post-command-hook, which is safer.=C2=A0 But I can have a look at th= e
> > original version and re-study those problems more closely.>
> We also have display-related hooks.=C2=A0 If you could use o= ne of them,
> that might be better, because one could generally type = quite a few
> commands before redisplay kicks in, and post-command-ho= ok runs once
> for every command.

OK, will try that.

&g= t; > > then at the very least we should give users a way of NOT addin= g a
> > > post-command-hook when this feature is disabled.
&= gt; >
> > Given that I intend for this to be controlled via a c= ustomization
> > variable, I only see it done via a `:set` hook or= something like that.
>
> I'm not sure I understand.=C2=A0 = What I wanted to suggest is that when the
> new defcustom is nil (whi= ch seems to be the way to disable this
> feature), the post-command-h= ook should not be added.

If we do it like that, it will take effect = only when jit-lock-mode is
toggled.=C2=A0 Therefore, if you set the vari= able to nil in a buffer you will
only see the desired effects in post-co= mmand-hook after additionally
toggling jit-lock-mode on and off again.
> In addition, I think major modes which present read-only buffers=
> should also disable this feature, and not add to post-command-hook= .

OK.

> > > > +Setting this to a positive number = of seconds helps avoid the
> > > > +fontification "blin= king" behaviour observed when adding temporarily
> > > >= ; +unterminated strings to source code.=C2=A0 If the user has recently crea= ted
> > > > +an unterminated string at EOL, jit fontificatio= n allows this idle
> > > > +"grace" period to elap= se before deciding it is a multi-line string and
> > > > +fo= ntifying the remainder of the buffer accordingly.
> > >
>= > > This should be simplified and shortened. =C2=A0(In general, copy= /paste of
> > > doc strings into NEWS is not a good idea.) =C2= =A0In particular, if the
> > > default is to have this behavior= (see below), the NEWS entry should
> > > tell how to disable t= hat.
> >
> > OK.=C2=A0 Supposing you've already alrea= dy gotten the idea, I invite you to
> > submit a suggestion.
&g= t;
> I'd rather had you try.=C2=A0 I think it's important tha= t more people can
> write good documentation, and I think in this cas= e it isn't hard.=C2=A0 You
> can use other entries as examples.
Naturally Eli, I hope you believe me that I try hard, indeed very har= d,
to write good documentation.=C2=A0 I spend I good deal of time in it,=
sometimes much more than writing the code itself.=C2=A0 If I sometimes = fail
to meet your standards, it's to be expected, (1) because they a= re high
(which is very good) and (2) because we all have unwritten guide= lines of
what we believe is good style.=C2=A0 I tried many versions (man= y more than
you can probably get evidence of in the emacs-diffs ML) and = settled on
the one I presented.

With requesting a suggestion from= you, I am not taking an adversarial
position, simply a way forward on w= hat I (and many) consider to be a
difficult and underestimated problem i= n programming.=C2=A0 Also, English is
not my first language, and Emacs-e= nglish has certain rules that you will
much more familiar with.

&= gt; > > (I question the wisdom of making this the default behavior, b= tw.)
> >
> > What's bothering you?
>
> 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 probably be in the = doc
> string as well).

Regarding slowdown, we have to check by= how much.=C2=A0 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 th= is problem.=C2=A0 Perhaps you
could weigh in on the pertinence of those = on-by-default (and moreover
impossible-to-turn-off) alternatives, too.= =C2=A0 Although those other
modifications target a reduced subset of mod= es, indeed precisely because
of that fact, I think it's better that = Emacs provides an effective and
more generic solution to this problem.
> > > I don't understand the "at EOL" part: is= n't any unterminated string
> > > appear as if it is "= at EOL"?
> >
> > An unterminated string at EOL might= be terminated somewhere _after_ EOL,
> > i.e. a perfectly legitim= ate (as "in your intentions") multiline string.
>
> I= still don't think I understand what would constitute an
> "= unterminated string at EOL", then.=C2=A0 Could you show two examples, = one
> where there is such a string, the other where there isn't?<= br>
Buffer 1:

l1: foofoo "bar =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0< unterminated string at EOL, terminated multiline stringl2: barbar" foofoo

Buffer 2:

l1: foofoo "bar =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0< unterminated string at EOL, unte= rminated string
l2: barbar

It's an informal way of referring = to both situations at line 1.=C2=A0 If I
said "unterminated string&= quot; the user might be led to believe it doesn't
apply to the situa= tion of buffer 1.

But the fact that it confused you so much is proba= bly a hint it's not a
great idea.=C2=A0 Again, let me humbly request= a suggestion for rephrasing :-)

> > Moreover this is a hint a= s to how the system is implemented, which some
> > users may appre= ciate.
> This kind of stuff should be in comments, not ion doc string= s, IMO.

Maybe.=C2=A0 Sometimes such hints are good because they help= consolidate the
user's prediction of timer-based behaviour.

= > > > Please don't use such cryptic variable names, at least n= ot on the file
> > > level (preferably also not locally inside = functions).
> >
> > The docstring explains the abbreviati= on.=C2=A0 I'm afraid that given current
> > naming practice (p= refix, double dash, sub-feature) I couldn't do much
> > better= .=C2=A0 I think jit-lock--antiblink-l-b-p is a better name than
> >= ; jit-lock--antiblink-pos, or jit-lock--pos, because it makes the reader> > "chase" the doc and learn of the exact meaning of the = abbreviation.
>
> The variables don't need to use jit-lock-= -antiblink- prefix, they
> could use jit-lock-- prefix instead. =C2= =A0jit-lock--last-line-begpos
> doesn't sound too long to me, for= example.

It doesn't, but then I lose the ability to i-search fo= r
jit-lock--antiblink and see its related variables. It's all trade-= offs.

But I'll put in the longer names or use a plist, don't= worry.

> > > > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (wh= en jit-lock--antiblink-grace-timer
> > > > + =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 (message "internal warning: `jit-lock--ant= iblink-grace-timer' not null"))
> > >
> > >= ; We should in general avoid calling 'message' here, because such a=
> > > message will appear after every command, which is a nuis= ance.=C2=A0 Is this
> > > really needed?
> >
> &= gt; This is an internal consistency check, i.e. a run-time assertion.=C2=A0= It
> > should never happen, except when the program is buggy.=C2= =A0 I had this set
> > to 'warn', but Stefan suggested I c= hange it.=C2=A0 What do you suggest?
> > Perhaps I could warn and = turn off the feature.
>
> Why not just lose the message?
Huh? If I lose the message the form becomes a noop.

> =C2=A0Why= is it important to display it?

Run-time consistency assertions are = useful, right?=C2=A0 I can change
'message' to whatever you thin= k has the optimimum noise-level for such
an assertion ('warn' wi= th a :debug level, maybe?) =C2=A0I can also remove the
form completely a= nd we just pray that noone every breaks the mechanism
in subtle ways :-)=

Jo=C3=A3o
--0000000000006fd7ac0594b76019--