jit-lock-antiblink-grace

jit-lock-antiblink-grace

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 1121 bytes --]

Hello all,

A while back I coded up a feature in a scratch branch that
I dubbed the "antiblink".  It helps avoid the fontification "blinking"
behaviour observed when creating temporarily unterminated
strings to source code.

I recall that Lars and Clément tested it with generally positive results.

At Stefan's request, I have reworked the implementation and
cleaned up the feature, which is embodied in the jit-lock-antiblink-grace
variable and want to land it on master if no-one objects.

If you want to try it before that happens see the
scratch/jit-lock-antiblink-cleaned-up branch.

jit-lock-antiblink-grace is set to 2 seconds by default, which works
nicely in my testing. Just launch your emacs, ensure you don't have
a quote-matching facility such as electric-pair-mode setup (in which
case the feature is mostly useless to you), and add/or remove
strings to some source code.

Thanks,
João Távora

BTW: I tried to force-push the cleaned-up version to the
scratch/jit-lock-antiblink branch. It didn't work.  Is force-pushing
disabled in those branches? It didn't use to be, IIRC.

[-- Attachment #2: Type: text/html, Size: 1835 bytes --]

Re: jit-lock-antiblink-grace

[Stefan Monnier]

> At Stefan's request, I have reworked the implementation and
> cleaned up the feature, which is embodied in the jit-lock-antiblink-grace
> variable and want to land it on master if no-one objects.

No objection from me.

> BTW: I tried to force-push the cleaned-up version to the
> scratch/jit-lock-antiblink branch. It didn't work.  Is force-pushing
> disabled in those branches? It didn't use to be, IIRC.

Force-pushing is disabled repository-wide.  You can workaround it by
removing+pushing the branch, instead (this workaround can technically be
used on any branch, but of course we don't want it used elsewhere than
in scratch/* branches).


        Stefan

Re: jit-lock-antiblink-grace

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Thu, 10 Oct 2019 23:34:25 +0100
> 
> A while back I coded up a feature in a scratch branch that 
> I dubbed the "antiblink".  It helps avoid the fontification "blinking"
> behaviour observed when creating temporarily unterminated 
> strings to source code.
> 
> I recall that Lars and Clément tested it with generally positive results.
> 
> At Stefan's request, I have reworked the implementation and 
> cleaned up the feature, which is embodied in the jit-lock-antiblink-grace
> variable and want to land it on master if no-one objects.
> 
> If you want to try it before that happens see the 
> scratch/jit-lock-antiblink-cleaned-up branch.  

Bother: this unconditionally adds a post-command-hook, which will
necessarily slow down paging through a file.  If there's no better
solution than using that over-used hook, then at the very least we
should give users a way of NOT adding a post-command-hook when this
feature is disabled.

Some more comments about the code:

> +** New customizable variable 'jit-lock-antiblink-grace'

This line should end in a period

> +Setting this to a positive number of seconds helps avoid the
> +fontification "blinking" behaviour observed when adding temporarily
> +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.

> +(defcustom jit-lock-antiblink-grace 2
> +  "Like `jit-lock-context-time' but for unterminated multiline strings.
> +Setting this to a positive number of seconds helps avoid the
> +fontification \"blinking\" behaviour observed when adding
> +temporarily unterminated strings to source code.  If the user has
> +recently created an unterminated string at EOL, allow for an idle
> +\"grace\" period to elapse before deciding it is a multi-line
> +string and fontifying the remainder of the buffer accordingly."
> +  :type '(number :tag "seconds")
> +  :group 'jit-lock)

This new defcustom should have a :version tag.

The doc string should say how to disable the feature.  Also, the doc
string makes it sound like the default is not a positive number of
seconds by default, but it is.  (I question the wisdom of making this
the default behavior, btw.)

I don't understand the "at EOL" part: isn't any unterminated string
appear as if it is "at EOL"?

> +(defvar jit-lock--antiblink-l-b-p (make-marker)
> +  "Last line beginning position (l-b-p) after last command (a marker).")
> +(defvar jit-lock--antiblink-i-s-o-c nil
> +  "In string or comment (i-s-o-c) after last command (a boolean).")

Please don't use such cryptic variable names, at least not on the file
level (preferably also not locally inside functions).

> +      (add-hook 'post-command-hook 'jit-lock--antiblink-post-command nil t)

As mentioned above, this hook should not be added if the feature is
disabled.

> +           (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 this
really needed?

Thanks.

Re: jit-lock-antiblink-grace

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 5362 bytes --]

On Sat, Oct 12, 2019 at 10:34 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > If you want to try it before that happens see the
> > scratch/jit-lock-antiblink-cleaned-up branch.
>
> Bother: this unconditionally adds a post-command-hook, which will
> necessarily slow down paging through a file.

Everything slows down everything, the question is where and by how much.
A noop will probably not slow paging very much.  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.

> 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.

> 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.
Or use some hack where the current timers detect the variable has been
enabled/disabled.

> Some more comments about the code:
>
> > +** New customizable variable 'jit-lock-antiblink-grace'
>
> This line should end in a period

OK.

> > +Setting this to a positive number of seconds helps avoid the
> > +fontification "blinking" behaviour observed when adding temporarily
> > +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.

> > +(defcustom jit-lock-antiblink-grace 2
> > +  "Like `jit-lock-context-time' but for unterminated multiline strings.
> > +Setting this to a positive number of seconds helps avoid the
> > +fontification \"blinking\" behaviour observed when adding
> > +temporarily unterminated strings to source code.  If the user has
> > +recently created an unterminated string at EOL, allow for an idle
> > +\"grace\" period to elapse before deciding it is a multi-line
> > +string and fontifying the remainder of the buffer accordingly."
> > +  :type '(number :tag "seconds")
> > +  :group 'jit-lock)
>
> This new defcustom should have a :version tag.

OK.

> The doc string should say how to disable the feature.  Also, the doc
> string makes it sound like the default is not a positive number of
> seconds by default, but it is.

> (I question the wisdom of making this the default behavior, btw.)

What's bothering you? (assuming all other objections you stated already
are somehow dealt with satisfactorily.)

> 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.
Moreover this is a hint as to how the system is implemented, which some
users may appreciate.

> > +(defvar jit-lock--antiblink-l-b-p (make-marker)
> > +  "Last line beginning position (l-b-p) after last command (a
marker).")
> > +(defvar jit-lock--antiblink-i-s-o-c nil
> > +  "In string or comment (i-s-o-c) after last command (a boolean).")
>
> Please don't use such cryptic variable names, at least not on the file
> 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.

Do you really prever jit-lock--antiblink-in-string-or-comment and
jit-lock--antiblink-line-beginning-position? I think it's much harder to
follow.  But I will abide, especially if you suggest alternatives.

> > +      (add-hook 'post-command-hook 'jit-lock--antiblink-post-command
nil t)
>
> As mentioned above, this hook should not be added if the feature is
> disabled.

See above.

> > +           (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 this
> 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.

João

[-- Attachment #2: Type: text/html, Size: 6209 bytes --]

Re: jit-lock-antiblink-grace

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 942 bytes --]

On Sat, Oct 12, 2019 at 12:59 PM João Távora <joaotavora@gmail.com> wrote:

> Do you really prever jit-lock--antiblink-in-string-or-comment and
> jit-lock--antiblink-line-beginning-position?

>
In a clean emacs -Q we already have things like

minibuffer-history-case-insensitive-variables
jit-lock-after-change-extend-region-functions
lisp-el-font-lock-keywords-for-backtraces-1
lisp-el-font-lock-keywords-for-backtraces-2
display-buffer--action-function-custom-type
jka-compr-added-to-file-coding-system-alist
revert-buffer-insert-file-contents-function
w32-direct-print-region-use-command-dot-com
backup-by-copying-when-privileged-mismatch
window-adjust-process-window-size-function
electric-indent-functions-without-reindent
list-matching-lines-default-context-lines
lisp-el-font-lock-keywords-for-backtraces
syntax-propertize-extend-region-functions
jka-compr-compression-info-list--internal

which are longer.

[-- Attachment #2: Type: text/html, Size: 1295 bytes --]

Re: jit-lock-antiblink-grace

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 1489 bytes --]

On Sat, Oct 12, 2019 at 2:02 PM Juanma Barranquero <lekktu@gmail.com> wrote:

> On Sat, Oct 12, 2019 at 12:59 PM João Távora <joaotavora@gmail.com> wrote:
>
> > Do you really prever jit-lock--antiblink-in-string-or-comment and
> > jit-lock--antiblink-line-beginning-position?
>
>>
> In a clean emacs -Q we already have things like
>
> minibuffer-history-case-insensitive-variables
> jit-lock-after-change-extend-region-functions
> lisp-el-font-lock-keywords-for-backtraces-1
> lisp-el-font-lock-keywords-for-backtraces-2
> display-buffer--action-function-custom-type
> jka-compr-added-to-file-coding-system-alist
> revert-buffer-insert-file-contents-function
> w32-direct-print-region-use-command-dot-com
> backup-by-copying-when-privileged-mismatch
> window-adjust-process-window-size-function
> electric-indent-functions-without-reindent
> list-matching-lines-default-context-lines
> lisp-el-font-lock-keywords-for-backtraces
> syntax-propertize-extend-region-functions
> jka-compr-compression-info-list--internal
>
> which are longer.
>

I don't understand how this can be an argument.
Is not exceeding the length of the longest symbol
ever, i.e. playing to the 99% percentile, acceptable
criteria for readability? I don't think so, personally.

That said, I'm neither in love with the solution I came
up with nor will I kill myself over long symbol names :-)

Perhaps a plist `jit-lock--antiblink-info` can be a
compromise.
-- 
João Távora

[-- Attachment #2: Type: text/html, Size: 2215 bytes --]

Re: jit-lock-antiblink-grace

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Sat, 12 Oct 2019 11:57:39 +0100
> Cc: emacs-devel <emacs-devel@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca>
> 
> > Bother: this unconditionally adds a post-command-hook, which will
> > necessarily slow down paging through a file.  
> 
> Everything slows down everything, the question is where and by how much.

The post-command-hook is notorious for slowing down cursor motion.
Many complaints I hear about Emacs being sluggish eventually boil down
to some minor mode inserting itself into that hook and doing
non-trivial stuff there.  We should therefore do so very cautiously.

This case is more important than others because JIT font-lock is
enabled by default, so this change will affect every user out there,
in any possible major mode.

> 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.

> > 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.

> > 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.

In addition, I think major modes which present read-only buffers
should also disable this feature, and not add to post-command-hook.

> > > +Setting this to a positive number of seconds helps avoid the
> > > +fontification "blinking" behaviour observed when adding temporarily
> > > +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.

> > (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).

> > 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?

> 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.

> > Please don't use such cryptic variable names, at least not on the file
> > 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.

> > > +           (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 this
> > 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?  Why is it important to display it?

Re: jit-lock-antiblink-grace

[Stefan Monnier]

>> 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

[ FWIW: I can't remember why I recommended/suggested
  post-command-hook, sorry.  ]

>> 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.

Really?  AFAIK we redisplay at the end of every command executed.
We additionally redisplay after processing filters and after receiving
an event that turned out to be a prefix key, etc...

So, AFAICT we generally redisplay at least as often as we run
post-command-hook.  The only case where we don't is when we can't keep
up with the input events in which case we skip redisplay, but that's the
case where we're *already* too slow.

> It's a backward-incompatible behavior, and is not being developed due
> to bug reports,

It was developed because people like Alan are so bothered by the
flashing that they're going through lengths to find other ways to
avoid it.

> 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).

It shouldn't slow down cursor motion, normally (at least not in any
measurable way).

Also I expect the implementation will change over time, as experience is
gained with it.

> 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?

Code like:

    var x = "foo y = "bar";

where the user is in the middle of writing `x = "foobar";` but hasn't yet
closed the string.


        Stefan

Re: jit-lock-antiblink-grace

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 8146 bytes --]

On Sat, Oct 12, 2019 at 2:33 PM Eli Zaretskii <eliz@gnu.org> 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 temporarily
> > > > +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 string
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 file
> > > 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 this
> > > 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ão

[-- Attachment #2: Type: text/html, Size: 9445 bytes --]

Re: jit-lock-antiblink-grace

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: João Távora <joaotavora@gmail.com>,
>   emacs-devel@gnu.org
> Date: Sat, 12 Oct 2019 10:13:42 -0400
> 
> > 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.
> 
> Really?  AFAIK we redisplay at the end of every command executed.

No, we do that only if there's no other event in the event queue.

> We additionally redisplay after processing filters and after receiving
> an event that turned out to be a prefix key, etc...

Filters run only when Emacs is idle, so they don't run when there are
keyboard events in the queue.

> So, AFAICT we generally redisplay at least as often as we run
> post-command-hook.

I don't think this is correct, not AFAIR.

> The only case where we don't is when we can't keep up with the input
> events in which case we skip redisplay, but that's the case where
> we're *already* too slow.

My point is that post-command-hook might be called more often than
once per redisplay cycle, and I think we agree on that, right?

> > It's a backward-incompatible behavior, and is not being developed due
> > to bug reports,
> 
> It was developed because people like Alan are so bothered by the
> flashing that they're going through lengths to find other ways to
> avoid it.

I'm not saying this is not a useful feature, and I'm not objecting to
its inclusion.  I'm asking why do we need to turn it on by default
right when we introduce it.

> > 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).
> 
> It shouldn't slow down cursor motion, normally (at least not in any
> measurable way).

Font lock does slow down Emacs, so calling it in more cases/places
will do so as well.

> > 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?
> 
> Code like:
> 
>     var x = "foo y = "bar";
> 
> where the user is in the middle of writing `x = "foobar";` but hasn't yet
> closed the string.

Yes, and what is the other example I asked for, where we don't have an
unterminated string at EOL due to such editing?

Re: jit-lock-antiblink-grace

[Stefan Monnier]

>> The only case where we don't is when we can't keep up with the input
>> events in which case we skip redisplay, but that's the case where
>> we're *already* too slow.
>
> My point is that post-command-hook might be called more often than
> once per redisplay cycle, and I think we agree on that, right?

Yes, but only if we can't keep up (i.e. if the event queue is already
non-empty when we're done processing an event).  So whether something is
done in redisplay or in post-command-hook doesn't affect the repeat-rate
threshold where we start skipping redisplay: it only affect how much
speed we gain by skipping redisplay (i.e. how quickly we can recover).

>> > It's a backward-incompatible behavior, and is not being developed due
>> > to bug reports,
>> It was developed because people like Alan are so bothered by the
>> flashing that they're going through lengths to find other ways to
>> avoid it.
> I'm not saying this is not a useful feature, and I'm not objecting to
> its inclusion.  I'm asking why do we need to turn it on by default
> right when we introduce it.

Because I think it offers the behavior 99% of the users will want
(modulo bugs).  Everyone I ever talked to about this agreed that the
current behavior is somewhat annoying and several of them mentioned
using "strategies" to avoid it (e.g. use electric-pair-mode, or be sure
to keep typing quickly so the string/comment gets closed before the
jit-lock-context-timer fires, ...).

>> > 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).
>> It shouldn't slow down cursor motion, normally (at least not in any
>> measurable way).
> Font lock does slow down Emacs, so calling it in more cases/places
> will do so as well.

AFAICT the code doesn't call font-lock.

>> > 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?
>> 
>> Code like:
>> 
>>     var x = "foo y = "bar";
>> 
>> where the user is in the middle of writing `x = "foobar";` but hasn't yet
>> closed the string.
>
> Yes, and what is the other example I asked for, where we don't have an
> unterminated string at EOL due to such editing?

That would be "any normal line", as in:

    var x = "foobar"; y = "bar";

"unterminated string at EOL" means (nth 3 (syntax-ppss
(line-end-position))) is non-nil.


        Stefan

Re: jit-lock-antiblink-grace

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 410 bytes --]

On Sat, Oct 12, 2019 at 3:14 PM João Távora <joaotavora@gmail.com> wrote:

> I don't understand how this can be an argument.

It wasn't an argument, it was a light-hearted comment.

> Is not exceeding the length of the longest symbol
> ever, i.e. playing to the 99% percentile, acceptable
> criteria for readability? I don't think so, personally.

Well, me, I prefer longer names to cryptic ones.

[-- Attachment #2: Type: text/html, Size: 614 bytes --]

Re: jit-lock-antiblink-grace

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 810 bytes --]

On Sat, Oct 12, 2019, 15:50 Juanma Barranquero <lekktu@gmail.com> wrote:

>
>
> On Sat, Oct 12, 2019 at 3:14 PM João Távora <joaotavora@gmail.com> wrote:
>
> > I don't understand how this can be an argument.
>
> It wasn't an argument, it was a light-hearted comment.
>

Sorry for the knee-jerk, then.

>

> Well, me, I prefer longer names to cryptic ones
>

Then it _was_ an argument :-) "cryptic" is a value judgement. I personally
decide on form on a case by case basis, but I can't really write the cost
function I use. Unfortunately, after a while, you become biased. It's often
when you actually witness others try to understand what you wrote that you
realize the consequences of one decision over the other. That's hard to do
in this ML... But did you try to read it?

João

[-- Attachment #2: Type: text/html, Size: 1833 bytes --]

Re: jit-lock-antiblink-grace

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 423 bytes --]

On Sat, Oct 12, 2019 at 5:11 PM João Távora <joaotavora@gmail.com> wrote:

> Then it _was_ an argument :-)

Nope. I can easily decouple what I prefer, and what could be best, or what
most prefer ;-)  I dislike customize, but I would never argue against it,
for example.

> But did you try to read it?

Yes. But I have nothing of value to add, other than misplaced light-hearted
comments ;-)  I'l shut up now.

[-- Attachment #2: Type: text/html, Size: 772 bytes --]

Re: jit-lock-antiblink-grace

[Alan Mackenzie]

Hello, Stefan.

On Sat, Oct 12, 2019 at 10:13:42 -0400, Stefan Monnier wrote:

[ .... ]

> > It's a backward-incompatible behavior, and is not being developed due
> > to bug reports,

> It was developed because people like Alan are so bothered by the
> flashing that they're going through lengths to find other ways to
> avoid it.

Who, me?  The flashing bothers me not at all, though there will surely
be people it does bother.  I think you're referring to the feature in CC
Mode where unterminated strings are font-locked to match their error
syntax, i.e. the string face ends at the next unescaped EOL.  This is a
static feature, not a dynamic one like João has just developed.  The two
features are not closely related.

[ .... ]

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: jit-lock-antiblink-grace

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: joaotavora@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 12 Oct 2019 10:34:44 -0400
> 
> >> The only case where we don't is when we can't keep up with the input
> >> events in which case we skip redisplay, but that's the case where
> >> we're *already* too slow.
> >
> > My point is that post-command-hook might be called more often than
> > once per redisplay cycle, and I think we agree on that, right?
> 
> Yes, but only if we can't keep up (i.e. if the event queue is already
> non-empty when we're done processing an event).  So whether something is
> done in redisplay or in post-command-hook doesn't affect the repeat-rate
> threshold where we start skipping redisplay: it only affect how much
> speed we gain by skipping redisplay (i.e. how quickly we can recover).

What is the purpose of this argument?  Do you agree that adding too
much to post-command-hook should be avoided?  If you do, then let's
not split hair about the rest, okay?

> > I'm not saying this is not a useful feature, and I'm not objecting to
> > its inclusion.  I'm asking why do we need to turn it on by default
> > right when we introduce it.
> 
> Because I think it offers the behavior 99% of the users will want
> (modulo bugs).

You are entitled to your opinion, and I'm entitled to mine.

> Everyone I ever talked to about this agreed that the current
> behavior is somewhat annoying

Here, you are talking to someone who is much more annoyed by the
sluggishness of our movement commands than by an occasional "flashes"
of incorrect fontification when I'm in the process of modifying code.
So I guess not "everyone" finds this annoying enough.

> > Font lock does slow down Emacs, so calling it in more cases/places
> > will do so as well.
> 
> AFAICT the code doesn't call font-lock.

It adds a timer that does.

Re: jit-lock-antiblink-grace

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Sat, 12 Oct 2019 15:23:08 +0100
> Cc: emacs-devel <emacs-devel@gnu.org>, 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.

> > 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.

It doesn't have to be like that.  It depends on how you arrange for
the hook not to be added.

> > 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.

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.

> > 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.

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.

> > 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 string
> l2: barbar
> 
> It's an informal way of referring to both situations at line 1.

That's what I thought, but then I think we should rather talk about
"unbalanced quotes", which should catch both cases without involving
EOL.

> > 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, or if the code absolutely cannot continue
under that condition.  Which I think is not the case here.

Re: jit-lock-antiblink-grace

[Alan Mackenzie]

Hello, João.

On Sat, Oct 12, 2019 at 15:23:08 +0100, João Távora wrote:
> On Sat, Oct 12, 2019 at 2:33 PM Eli Zaretskii <eliz@gnu.org> wrote:

[ .... ]

> > 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.

No.  The feature in CC Mode I think you're referring to, namely the
correct fontification of unterminated strings is a static feature,
clearly indicating that the string hasn't (yet) been terminated, and
where its current end (as would be interpreted by a compiler) is.  The
feature you've implemented is, if I understand correctly (I haven't tried
it, yet) a dynamic one, where fontification gets delayed a bit to give
the user a certain chance to terminate an unterminated string before
fontification kicks in.

I would guess that your new feature is less needed in a CC Mode mode than
in modes where the fontification of a string extends to the next string
quote, no matter how far away.

> 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 agree with that.  My view is that such a feature should be provided in
syntax.c and the font locking system, such that a major mode can specify
that unterminated strings are to be regarded as terminated by an
unescaped new line.

I think I said this before, off hand, but it didn't go anywhere.

[ .... ]

> João

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: jit-lock-antiblink-grace

[Stefan Monnier]

> What is the purpose of this argument?  Do you agree that adding too
> much to post-command-hook should be avoided?

I agree that post-command-hook is never the "right" place.  But I don't
think moving to a place that runs at every redisplay will help very much
in terms of the risk of impacting responsiveness.

Also often there's no "right" place, so we end up choosing
post-command-hook because it's the least bad choice.

I'd like the patch to be installed, because I think it'll need tweaking
but that we need more experience with it in order to figure out what
to do.

>> > Font lock does slow down Emacs, so calling it in more cases/places
>> > will do so as well.
>> AFAICT the code doesn't call font-lock.
> It adds a timer that does.

AFAICT this only runs code which has been delayed (i.e. it would have
been run earlier if it weren't for this feature), so it's "no worse".

And it's an idle-timer run after 2s of idle time, so impact on
responsiveness should be minimal even in the worst case.


        Stefan

Re: jit-lock-antiblink-grace

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: joaotavora@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 12 Oct 2019 13:16:45 -0400
> 
> >> AFAICT the code doesn't call font-lock.
> > It adds a timer that does.
> 
> AFAICT this only runs code which has been delayed (i.e. it would have
> been run earlier if it weren't for this feature), so it's "no worse".
> 
> And it's an idle-timer run after 2s of idle time, so impact on
> responsiveness should be minimal even in the worst case.

Idle timers that run expensive code make Emacs feel very unresponsive.
That's one reason why we introduced JIT lock, many years ago.

Re: jit-lock-antiblink-grace

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 4718 bytes --]

On Sat, Oct 12, 2019 at 5:05 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: João Távora <joaotavora@gmail.com>
> > Date: Sat, 12 Oct 2019 15:23:08 +0100
> > Cc: emacs-devel <emacs-devel@gnu.org>, 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 will
> > 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 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 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ão

[-- Attachment #2: Type: text/html, Size: 5544 bytes --]

Re: jit-lock-antiblink-grace

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 1545 bytes --]

On Sat, Oct 12, 2019 at 5:14 PM Alan Mackenzie <acm@muc.de> wrote:
>
> Hello, João.

> > 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.
> No.

You're right. I never really understood _your_ motivation for it.  Of
all its serious drawbacks, the only positive effect that others --
indeed not you -- effectively pointed out is that it partially solves
the "flashing" or "blinking" problem for users who don't use
electric-pair-mode, smartparens, or similar solutions.  In contrast,
your explanations for that particular feature, which conflated syntax
and font-lock considerations, were always nonsensical to me.  With all
sincerity, whenever I tried to follow your logic I came to a insoluble
contradiction.  Alas, I'm afraid my ability to follow the same arguments
hasn't evolved much in the meantime, and so I very much wish not to
rehash that discussion.

Anyway, after recognizing the legitimacy of the aforementioned
"flashing" problem (which, again, I avoid with electric-pair-mode), I
took up a stuggestion by Stefan for an alternative way to solve that
problem.  So that there would be less justification to the
behaviour-breaking changes to CC Mode, or at least so that other mode
authors aren't encouraged to replicate your approach, that I personally
consider harmful.

João

[-- Attachment #2: Type: text/html, Size: 1753 bytes --]

Re: jit-lock-antiblink-grace

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Sat, 12 Oct 2019 22:55:29 +0100
> Cc: emacs-devel <emacs-devel@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca>
> 
> > 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?

I didn't figure out the details, I thought it should be easy to do.
Don't we already do something like that in all kinds of places?  The
:set attribute of a defcustom comes to mind, for example.
Alternatively, the timer you add could notice the change and take that
action.  And I'm sure there are more ways of doing that.  Or maybe I'm
missing something.

> > 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.

Thank you.

> > 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.

I don't remember the particular case, but I can make mistakes, can I?

Anyway, I'm not sure I understand what you are trying to say here.
Are you saying that I treat you differently from others?  If so,
that's not the case, and if I said something that could be interpreted
otherwise, I apologize.

> 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?

Very simply: the behavior is different from what we had previously.
Previously, starting a new comment would give me an almost immediate
visual feedback; now that feedback is delayed by 2 sec (more, or even
not at all, if I continue typing).  How can we know that everybody
will instantly like this new behavior?

> > > 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.

That's not so: various packages define their own debug facilities.
Examples include Tramp and smtpmail.el.  We could add a debug facility
to jit-lock.el as well, if you think it's important for this feature.

Thanks.

Re: jit-lock-antiblink-grace

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 4749 bytes --]

On Sun, Oct 13, 2019 at 7:39 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: João Távora <joaotavora@gmail.com>
> > Date: Sat, 12 Oct 2019 22:55:29 +0100
> > Cc: emacs-devel <emacs-devel@gnu.org>, Stefan Monnier <
monnier@iro.umontreal.ca>
> I didn't figure out the details, I thought it should be easy to do.
> Don't we already do something like that in all kinds of places?  The
> :set attribute of a defcustom comes to mind, for example.
> Alternatively, the timer you add could notice the change and take that
> action.  And I'm sure there are more ways of doing that.  Or maybe I'm
> missing something.

I had already mentioned :set, but iiuc it only works via customize.  The
other techniques you mention are the (relatively) hacky ones I had in
mind, too.

> > > 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.
>
> I don't remember the particular case, but I can make mistakes, can I?
> Anyway, I'm not sure I understand what you are trying to say here.
> Are you saying that I treat you differently from others?  If so,
> that's not the case, and if I said something that could be interpreted
> otherwise, I apologize.

All I'm trying to say is one of the motivations for my proposed feature
A is to be an alternative to another feature B in Emacs (which I
consider harmful) and you are holding my feature to a higher standard
(regarding backward compatibility, performance, doc, etc) than you did
the other one.  In absolute terms, that's just fine, but in relative
terms there is a discrepancy that was trying to understand.  If it was
simply an oversight, it's perfectly OK.

> > 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?
> Very simply: the behavior is different from what we had previously.

Of course, there is different behaviour in every feature except a
refactorization.

> Previously, starting a new comment would give me an almost immediate
> visual feedback; now that feedback is delayed by 2 sec (more, or even
> not at all, if I continue typing).  How can we know that everybody
> will instantly like this new behavior?

Hmmm. We might be miscommunicating (or you might be seeing a bug).  When
you start to type a comment or a string, you still get "almost immediate
visual feedback" just you did before.  This has not changed at all.  If
the command you just performed, say, insert or delete a quote:

1. _created_ a situation if unbalanced quotes at EOL, then the typical
"flipping" of the fontification of many lines _after_ the current is
delayed, because the system believes you will probably solve the
situation within jit-lock-antiblink-grace seconds;

2. _restored_ a situation of balanced quotes, then everything should be
as before.

A core assumption here is that the user very rarely wants to create
deliberate unbalance of strings. Those users, were they to exist in
great numbers, would probably be bothered by the grace delay.

Anyway, it is only in situation 1 that the amplitude of "visual
feedback" is reduced, because the system considers the extra visual
feedback related to the real possibility of inserting a multi-line
string, is alarmist/premature/unjustified.  Do I explain myself?

> > > > 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.
> That's not so: various packages define their own debug facilities.

I meant Emacs-wide, of course.  There is display-warning-minimum-level
and warning-minimum-log-level tho, which I wish were easier to control.

> Examples include Tramp and smtpmail.el.  We could add a debug facility
> to jit-lock.el as well, if you think it's important for this feature.

I don't (and I don't like these package-specific solutions).  And that's
precisely why I settled on a 'message' as a middle-of-the-road solution.
Anyway, your point seems to be to minimize the probability of incessant
debug chatter in *Messages* which would supposedly render an Emacs with
a buggy jit-lock.el unusable.  I can use a suitably parameterized
'warn', a cl-assertion, an error, or just get rid of it.

João

[-- Attachment #2: Type: text/html, Size: 5499 bytes --]

Re: jit-lock-antiblink-grace

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Sun, 13 Oct 2019 09:47:24 +0100
> Cc: emacs-devel <emacs-devel@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca>
> 
> > > 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.
> >
> > I don't remember the particular case, but I can make mistakes, can I?
> > Anyway, I'm not sure I understand what you are trying to say here.
> > Are you saying that I treat you differently from others?  If so,
> > that's not the case, and if I said something that could be interpreted
> > otherwise, I apologize.
> 
> All I'm trying to say is one of the motivations for my proposed feature
> A is to be an alternative to another feature B in Emacs (which I
> consider harmful) and you are holding my feature to a higher standard
> (regarding backward compatibility, performance, doc, etc) than you did
> the other one.  In absolute terms, that's just fine, but in relative
> terms there is a discrepancy that was trying to understand.  If it was
> simply an oversight, it's perfectly OK.

All I can say is that I consider each proposal on its own terms, and
try to apply the same considerations in all cases.  There's no higher
standard for you or anyone else, and lower standards for others, at
least not intentionally.

> > Very simply: the behavior is different from what we had previously.
> 
> Of course, there is different behaviour in every feature except a
> refactorization.

No, bug fixes make changes that don't change behavior, not in general.
New features do change behavior, and we normally don't turn them all
on by default, not unless we have a very good reason.

> Do I explain myself?

Yes, but I already knew all that, so there's no misunderstanding on my
part.

> Anyway, your point seems to be to minimize the probability of incessant
> debug chatter in *Messages* which would supposedly render an Emacs with
> a buggy jit-lock.el unusable.

It's not just the *Messages* buffer: each call to 'message' causes
redisplay, so we will have a flood of redisplays, which is not nice.

> I can use a suitably parameterized
> 'warn', a cl-assertion, an error, or just get rid of it.

Thanks.

Re: jit-lock-antiblink-grace

[Alan Mackenzie]

Hello, Jaão.

On Sat, Oct 12, 2019 at 23:26:00 +0100, João Távora wrote:
> On Sat, Oct 12, 2019 at 5:14 PM Alan Mackenzie <acm@muc.de> wrote:

> > > 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.
> > No.

> You're right. I never really understood _your_ motivation for it.  Of
> all its serious drawbacks, the only positive effect that others --
> indeed not you -- effectively pointed out is that it partially solves
> the "flashing" or "blinking" problem for users who don't use
> electric-pair-mode, smartparens, or similar solutions.  In contrast,
> your explanations for that particular feature, which conflated syntax
> and font-lock considerations, were always nonsensical to me.  With all
> sincerity, whenever I tried to follow your logic I came to a insoluble
> contradiction.  Alas, I'm afraid my ability to follow the same arguments
> hasn't evolved much in the meantime, and so I very much wish not to
> rehash that discussion.

> Anyway, after recognizing the legitimacy of the aforementioned
> "flashing" problem (which, again, I avoid with electric-pair-mode), I
> took up a stuggestion by Stefan for an alternative way to solve that
> problem.  So that there would be less justification to the
> behaviour-breaking changes to CC Mode, or at least so that other mode
> authors aren't encouraged to replicate your approach, that I personally
> consider harmful.

Why do you have to be so hostile?

You start by snipping my entire post, bar one word, so that people can't
see my point of view that you're supposedly replying to.

Then you generally disparage my work, vaguely and unspecifically.  If
there's something about CC Mode workings you don't like, say what it is.
Then I can see if the mode can be further improved.

The one specific feature you referred to in the past, namely syntactic
matching of disjoint string quotes (i.e. on different lines), I
implemented back in July.

Please don't post more posts like the one I'm replying to.  They're not
helpful, and spoil the generally positive and cooperative tone on this
list.

> João

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: jit-lock-antiblink-grace

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 2051 bytes --]

On Sun, Oct 13, 2019 at 10:22 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > > Very simply: the behavior is different from what we had previously.
> > Of course, there is different behaviour in every feature except a
> > refactorization.
> No, bug fixes make changes that don't change behavior, not in general.

We're well into hair-splitting territory here but I would argue that a
bug fix, by definition, changes incorrect behaviour into correct
behaviour.

> New features do change behavior, and we normally don't turn them all
> on by default, not unless we have a very good reason.

I understand that, and I agree with this policy.  My very good reason
for enabling by default is that this change is cheap, i.e. there are
very few adverse effects (be it in performance or behaviour change), and
considerable benefit.  Of course, I've yet to prove the performance hit
is neglibile and I also separately trying to convince that the lost
behaviour is almost never desirable.

Speaking of benchmarks, what is the correct way to benchmark this,
i.e. to simulate "paging down a file". Is it just sth like

  (while t (call-interactively 'next-line))

? Or should I add a `redisplay` or something else there?

> > Do I explain myself?
> Yes, but I already knew all that, so there's no misunderstanding on my
> part.

Well, you did write two mails ago that the current "almost immediate"
visual feedback would be delayed for 2 seconds or more.  Since that is
patently not true it led me to believe there was a misunderstanding (or
a bug).

> > Anyway, your point seems to be to minimize the probability of incessant
> > debug chatter in *Messages* which would supposedly render an Emacs with
> > a buggy jit-lock.el unusable.
> It's not just the *Messages* buffer: each call to 'message' causes
> redisplay, so we will have a flood of redisplays, which is not nice.

Yes, but my point was that in a buggy jit-lock.el such things are
relatively unimportant in comparison, hence the case for early warning.

João

[-- Attachment #2: Type: text/html, Size: 2328 bytes --]

Re: jit-lock-antiblink-grace

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Sun, 13 Oct 2019 11:28:39 +0100
> Cc: emacs-devel <emacs-devel@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca>
> 
> Speaking of benchmarks, what is the correct way to benchmark this,
> i.e. to simulate "paging down a file". Is it just sth like
> 
>   (while t (call-interactively 'next-line))
> 
> ? Or should I add a `redisplay` or something else there?

For timing the effect of post-command-hook, you need to actually
invoke many commands.  I suggest to lean on the DOWN arrow for a fixed
amount of time, say, 30 sec, and see how far into the file did you go,
and what was the average CPU load (e.g, as shown by display-time-mode
or by 'top').

Re: jit-lock-antiblink-grace

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 1757 bytes --]

On Sun, Oct 13, 2019 at 11:18 AM Alan Mackenzie <acm@muc.de> wrote:
> Why do you have to be so hostile?
> You start by snipping my entire post, bar one word, so that people can't
> see my point of view that you're supposedly replying to.

The word I left was the only thing that interested me in your whole
post.  It was a simple "No." reply to one of my earlier statements, and
I replied by correcting myself and admitting I misattributed an
intention to you.  How can that be hostile?  Also, people will
presumably have access to the conversion, it's not secret.

> Then you generally disparage my work, vaguely and unspecifically.  If
> there's something about CC Mode workings you don't like, say what it is.
> Then I can see if the mode can be further improved.

Stating disagreement is not the same as disparaging.  Also, as I wrote,
I have no intention of convincing you to change CC Mode.  I already
spent a good deal of effort trying to do so in the past, I gave up, and
I have no plans or energy topersist..  I'd much rather invest in
alternatives, sorry :-), but that's being honest, not hostile.

> Please don't post more posts like the one I'm replying to.  They're not
> helpful, and spoil the generally positive and cooperative tone on this
> list.

I'm not spoiling anything Alan, don't overreact.  The feature I'm
proposing is for all Emacs modes, and is related to the past discussion
(was it really July? perhaps) in the sense that some people brought up
the "flashing/blinking" behaviour in connection to it.

You're of course well welcome to discuss the merits/flaws of my
proposal, but outside the scope of CC Mode (unless of course you show it
has some adverse effect _specific_ to CC Mode).

João

[-- Attachment #2: Type: text/html, Size: 1999 bytes --]

Re: jit-lock-antiblink-grace

[Alan Mackenzie]

Hello, João.

On Thu, Oct 10, 2019 at 23:34:25 +0100, João Távora wrote:
> Hello all,

> A while back I coded up a feature in a scratch branch that
> I dubbed the "antiblink".  It helps avoid the fontification "blinking"
> behaviour observed when creating temporarily unterminated
> strings to source code.

> I recall that Lars and Clément tested it with generally positive results.

> At Stefan's request, I have reworked the implementation and
> cleaned up the feature, which is embodied in the jit-lock-antiblink-grace
> variable and want to land it on master if no-one objects.

Before that, I would suggest you turn it into two minor modes, one
working on the current buffer, the other global, just like
font-lock-mode and global-font-lock-mode.

> If you want to try it before that happens see the
> scratch/jit-lock-antiblink-cleaned-up branch.

I think the mode should be easier to turn on and off, and should not
need font-lock-mode to be reinitialised.

> jit-lock-antiblink-grace is set to 2 seconds by default, which works
> nicely in my testing. Just launch your emacs, ensure you don't have
> a quote-matching facility such as electric-pair-mode setup (in which
> case the feature is mostly useless to you), and add/or remove
> strings to some source code.

> Thanks,
> João Távora

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: jit-lock-antiblink-grace

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 999 bytes --]

On Sun, Oct 13, 2019 at 1:02 PM Alan Mackenzie <acm@muc.de> wrote:

> Before that, I would suggest you turn it into two minor modes, one
> working on the current buffer, the other global, just like
> font-lock-mode and global-font-lock-mode.

Thanks for the suggestion.  Currently, my intention is that a variable,
a generalized boolean controls this feature.  This shouldn't conflict
a lot with your proposal of proper global and minor modes for
separate (de)activation, but those would come later.

> > If you want to try it before that happens see the
> > scratch/jit-lock-antiblink-cleaned-up branch.
>
> I think the mode should be easier to turn on and off, and should not
> need font-lock-mode to be reinitialised.

Don't worry, that's the way it works right now (no jit-lock-mode
reinitialisation needed): just set (or customize) jit-lock-antiblink-grace
to a positive number to activate, and to nil to deactivate. It should take
effect immediately.

--
João Távora

[-- Attachment #2: Type: text/html, Size: 1284 bytes --]

Re: jit-lock-antiblink-grace

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 2158 bytes --]

On Sun, Oct 13, 2019 at 11:45 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > ? Or should I add a `redisplay` or something else there?
> For timing the effect of post-command-hook, you need to actually
> invoke many commands.  I suggest to lean on the DOWN arrow for a fixed
> amount of time, say, 30 sec, and see how far into the file did you go,
> and what was the average CPU load (e.g, as shown by display-time-mode
> or by 'top').

OK, I found some time to run these "manual" tests:

So I tried this with and without the hook. I removed it (forcibly) with

 (remove-hook 'post-command-hook
               'jit-lock--antiblink-post-command t)
and re-added it with

 (add-hook 'post-command-hook
           'jit-lock--antiblink-post-command nil t)

before beginning the test.

I confirmed that without the hook the feature is crippled and fails, and
with the hook it works fine.  This was easier then launching separate
emacsen with jit-lock-antiblink-grace customized differently.

60 second-long C-n in src/xdisp.c,
  without antiblink: line 706, avg load 4%
  with antiblink: line 717, avg load 4%
30 second-long C-n in lisp/minibuffer.el,
  with antiblink: line 366, avg load 4%
  without antiblink: line 361, avg load 4%

Time to end of buffer with C-v in lisp/minibuffer.el:
  with antiblink: 10 seconds, avg load 6%
  without antiblink: 10 seconds, avg load 6%

Time to end of buffer with C-v in src/xdisp.c:
  without antiblink: 90 seconds, avg load 8%
  with antiblink: 91 seconds, avg load 8%

I ran this with Emacs -Q with git commit
079461b360a2467ff4ab2ec57516c6f9e45f50fe on a 2013 Macbook Air running
Mojave.

The CPU load averages are computed "in my mind" from looking at top(1)
output. Times are taken from a wristwatch.  Thus, not really precise
measurements at all.  So, because these tests are kind of boring to
conduct, I'd like you or someone else to reproduce (or fail to
reproduce) one or two results before going any further.

Nevertheless, I'd risk saying that your worries about the performance
impact on these particular "paging" operations may not materialize at
all.

João

[-- Attachment #2: Type: text/html, Size: 2471 bytes --]

Re: jit-lock-antiblink-grace

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Tue, 15 Oct 2019 00:29:51 +0100
> Cc: emacs-devel <emacs-devel@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca>
> 
> So I tried this with and without the hook. I removed it (forcibly) with
> 
>  (remove-hook 'post-command-hook
>                'jit-lock--antiblink-post-command t)
> and re-added it with
> 
>  (add-hook 'post-command-hook
>            'jit-lock--antiblink-post-command nil t)
> 
> before beginning the test.
> 
> I confirmed that without the hook the feature is crippled and fails, and
> with the hook it works fine.  This was easier then launching separate
> emacsen with jit-lock-antiblink-grace customized differently.
> 
> 60 second-long C-n in src/xdisp.c,
>   without antiblink: line 706, avg load 4%
>   with antiblink: line 717, avg load 4%
> 30 second-long C-n in lisp/minibuffer.el,
>   with antiblink: line 366, avg load 4%
>   without antiblink: line 361, avg load 4%
> 
> Time to end of buffer with C-v in lisp/minibuffer.el:
>   with antiblink: 10 seconds, avg load 6%
>   without antiblink: 10 seconds, avg load 6%
> 
> Time to end of buffer with C-v in src/xdisp.c:
>   without antiblink: 90 seconds, avg load 8%
>   with antiblink: 91 seconds, avg load 8%

This is encouraging, but please try C-n near the end of xdisp.c, so
that it includes syms_of_xdisp.  The first 350 lines of xdisp.c is one
large comment, and there's a very small number of strings after that.

Thanks.

Re: jit-lock-antiblink-grace

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 1555 bytes --]

On Tue, Oct 15, 2019 at 7:48 AM Eli Zaretskii <eliz@gnu.org> wrote:

>
> This is encouraging, but please try C-n near the end of xdisp.c, so
> that it includes syms_of_xdisp.  The first 350 lines of xdisp.c is one
> large comment, and there's a very small number of strings after that.

OK. So same setup as before but running on Windows 10 on a i7
processor:

30 seconds from syms_of_xdisp (void) in src/xdisp.c:
  with antiblink: 34969, around 7% load measured by Process Explorer
  without: 34977, also around 7% load

So I'd venture to say this didn't change much.

I think the reason the C-n and C-v tests escape a big performance hit is
that the potentially expensive operation, 'syntax-ppss', doesn't get
called when you you have switched lines.  So the presence or absence of
strings is irrelevant.  The most expensive operation will probably be
`line-beginning-position` which is in C and apparently fast enough to
not have any kind of relative impact.

But now that I notice, the beginning of jit-lock--antiblink-post-command
could be improved slightly to shortcut earlier and avoid one extra
`line-beginning-position' call in these cases (though probably these
rough benchmarks wouldn't show it.)

So to summarize, for the "paging" scenario, the overhead of the
post-command-based antiblink can be as low a 'copy-marker', an argless
'line-beginning-position' and few tests.

Assuming you're OK with the performace aspects of the thing, I'll do the
fixes you suggested earlier and re-submit (or push?)

João

[-- Attachment #2: Type: text/html, Size: 1805 bytes --]

Re: jit-lock-antiblink-grace

[João Távora]

João Távora <joaotavora@gmail.com> writes:

> On Tue, Oct 15, 2019 at 7:48 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
>> This is encouraging, but please try C-n near the end of xdisp.c, so
>> that it includes syms_of_xdisp.  The first 350 lines of xdisp.c is one
>> large comment, and there's a very small number of strings after that.

> 30 seconds from syms_of_xdisp (void) in src/xdisp.c:
>   with antiblink: 34969, around 7% load measured by Process Explorer
>   without: 34977, also around 7% load
>   
Hi Eli,

We seem to have lost track of this, and it's waiting for your input.  I'd
like this change to make it 27.1.

To summarize, the benchmarks you suggested (paging down the file with
C-v and C-n) all confirmed "no performance hit".  I also tried a couple
of C-f/C-b benchmarks to the same results. 

If you need to gain more confidence from more benchmarks or a refresher
on exactly what this change is about, I'm at your disposal.  If you
think you're OK with the performance aspect, I'll perform the changes to
the docstrings and NEWS that we had agreed to previously.

João

Re: jit-lock-antiblink-grace

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Cc: emacs-devel <emacs-devel@gnu.org>,  Stefan Monnier
>  <monnier@iro.umontreal.ca>
> Date: Sun, 24 Nov 2019 01:04:53 +0000
> 
> João Távora <joaotavora@gmail.com> writes:
> 
> > On Tue, Oct 15, 2019 at 7:48 AM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> >> This is encouraging, but please try C-n near the end of xdisp.c, so
> >> that it includes syms_of_xdisp.  The first 350 lines of xdisp.c is one
> >> large comment, and there's a very small number of strings after that.
> 
> > 30 seconds from syms_of_xdisp (void) in src/xdisp.c:
> >   with antiblink: 34969, around 7% load measured by Process Explorer
> >   without: 34977, also around 7% load
> >   
> Hi Eli,
> 
> We seem to have lost track of this, and it's waiting for your input.  I'd
> like this change to make it 27.1.

I was under the impression that you had some issues with Alan, and
didn't realize you were waiting for me.  Sorry.

> If you need to gain more confidence from more benchmarks or a refresher
> on exactly what this change is about, I'm at your disposal.  If you
> think you're OK with the performance aspect, I'll perform the changes to
> the docstrings and NEWS that we had agreed to previously.

Please add/finalize the docs, and let's take it from there.

One thing I see already is that you turned on this feature by default,
but NEWS is worded as if it is off.  Not sure if we had a consensus
regarding the default back then.

Thanks.

Re: jit-lock-antiblink-grace

[Alan Mackenzie]

Hello, Eli.

On Sun, Nov 24, 2019 at 18:16:49 +0200, Eli Zaretskii wrote:
> > From: João Távora <joaotavora@gmail.com>
> > Cc: emacs-devel <emacs-devel@gnu.org>,  Stefan Monnier
> >  <monnier@iro.umontreal.ca>
> > Date: Sun, 24 Nov 2019 01:04:53 +0000

> > João Távora <joaotavora@gmail.com> writes:

> > > On Tue, Oct 15, 2019 at 7:48 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > >> This is encouraging, but please try C-n near the end of xdisp.c, so
> > >> that it includes syms_of_xdisp.  The first 350 lines of xdisp.c is one
> > >> large comment, and there's a very small number of strings after that.

> > > 30 seconds from syms_of_xdisp (void) in src/xdisp.c:
> > >   with antiblink: 34969, around 7% load measured by Process Explorer
> > >   without: 34977, also around 7% load

> > Hi Eli,

> > We seem to have lost track of this, and it's waiting for your input.  I'd
> > like this change to make it 27.1.

> I was under the impression that you had some issues with Alan, and
> didn't realize you were waiting for me.  Sorry.

Just for the record, I have no objection to this new mode, provided it is
disabled by default.

> > If you need to gain more confidence from more benchmarks or a refresher
> > on exactly what this change is about, I'm at your disposal.  If you
> > think you're OK with the performance aspect, I'll perform the changes to
> > the docstrings and NEWS that we had agreed to previously.

> Please add/finalize the docs, and let's take it from there.

> One thing I see already is that you turned on this feature by default,
> but NEWS is worded as if it is off.  Not sure if we had a consensus
> regarding the default back then.

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: jit-lock-antiblink-grace

[João Távora]

On Mon, Nov 25, 2019 at 6:46 PM Alan Mackenzie <acm@muc.de> wrote:

> provided it is disabled by default.

It's not.  The goal is to enable it by default.

Last I hear from you on the matter was in:

  https://lists.gnu.org/archive/html/emacs-devel/2019-10/msg00540.html
  https://lists.gnu.org/archive/html/emacs-devel/2019-10/msg00563.html

You didn't bring up this point (you suggested an improvement
I can agree to to and another one that doesn't apply).

Eli was concerned about performance, but the
suggested benchmarks so far all point to "little to no
impact".

So can you explain your new objection?

Thanks in advance,
João

Re: jit-lock-antiblink-grace

[Alan Mackenzie]

Hello, Joåo.

On Mon, Nov 25, 2019 at 19:02:16 +0000, João Távora wrote:
> On Mon, Nov 25, 2019 at 6:46 PM Alan Mackenzie <acm@muc.de> wrote:

> > provided it is disabled by default.

> It's not.  The goal is to enable it by default.

[ .... ]

> So can you explain your new objection?

Consistency.  All little tweaks to Emacs functionality which "everybody
is bound to want" end up irritating people immensely, so they are all
disabled by default - at least when new, including several I have
written myself.  Even Font Lock was disabled by default up until (I
believe) Emacs 22.

People who want this new mode will find it and enable it.  I can't
remember any arguments you may have made as to why this mode should be
singled out for special treatment, but I can't see any compelling reason
for its default enablement.

Anyway, it's for Eli to decide, not me.

> Thanks in advance,
> João

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: jit-lock-antiblink-grace

[João Távora]

On Mon, Nov 25, 2019 at 7:26 PM Alan Mackenzie <acm@muc.de> wrote:
> > So can you explain your new objection?
>
> Consistency.

Best consistency tends do arise when taking a good
hard look of the pros and cons of each change, instead
of citing blanket policy.

> All little tweaks to Emacs functionality which "everybody
is bound to want" end up irritating people immensely,

[ I could remember some introduced by you, but this
is besides the discussion. ]

> I can't remember any arguments you may have made

Here they are: see the second paragraph and the ensuing
discussion, where Eli suggests benchmarks:

  https://lists.gnu.org/archive/html/emacs-devel/2019-10/msg00537.html

I can summarize:

1. There are no adverse or surprising behaviors;
2. There is negligible performance impact;
3. There is a demonstrated benefit;

I've only done so much work testing each of these
assertions, and I'd of course be interested in hearing
(concrete) objections.

João

Re: jit-lock-antiblink-grace

[Dmitry Gutov]

On 25.11.2019 21:26, Alan Mackenzie wrote:
> People who want this new mode will find it and enable it.  I can't
> remember any arguments you may have made as to why this mode should be
> singled out for special treatment, but I can't see any compelling reason
> for its default enablement.

Considering this mode was born out of a discussion on how to simplify 
one of CC Mode's latest features, this exchange reads like a political 
failure. :-(

Re: jit-lock-antiblink-grace

[João Távora]

On Mon, Nov 25, 2019 at 7:47 PM Dmitry Gutov <dgutov@yandex.ru> wrote:

> Considering this mode was born out of a discussion on how to simplify
> one of CC Mode's latest features, this exchange reads like a political
> failure. :-(

Don't understand your comment 100%, but, in a way, I think
it's a success.  This work was envisioned by Stefan and
implemented by me. It helps other parts of Emacs, not just
CC-Mode. It's indebted to that discussion, to all its
participants, including Alan, of course.

João

Re: jit-lock-antiblink-grace

[Alan Mackenzie]

Hello, Joåo.

On Mon, Nov 25, 2019 at 19:45:40 +0000, João Távora wrote:
> On Mon, Nov 25, 2019 at 7:26 PM Alan Mackenzie <acm@muc.de> wrote:
> > > So can you explain your new objection?

> > Consistency.

> Best consistency tends do arise when taking a good
> hard look of the pros and cons of each change, instead
> of citing blanket policy.

> > All little tweaks to Emacs functionality which "everybody
> is bound to want" end up irritating people immensely,

> [ I could remember some introduced by you, but this
> is besides the discussion. ]

> > I can't remember any arguments you may have made

> Here they are: see the second paragraph and the ensuing
> discussion, where Eli suggests benchmarks:

>   https://lists.gnu.org/archive/html/emacs-devel/2019-10/msg00537.html

> I can summarize:

> 1. There are no adverse or surprising behaviors;
> 2. There is negligible performance impact;
> 3. There is a demonstrated benefit;

I could have made exactly these arguments for enabling "my" new features
by default.  In fact, I might well have done so.  ;-)  But wiser heads
prevailed.  For one of these features, fast-but-imprecise-scrolling,
there was even a massive performance advantage.  It remains disabled by
default.

Point 2 may hold.  Points 1 and 3 are pure speculation by you, you not
being the most impartial judge.

For me, at least, point 1 doesn't hold.  Having the fontification
delayed until 2 seconds of inactivity would for me be intensely
irritating.  Context fontification is bad enough, but that at least is
justified by performance reasons.

As for point 3, there would be no benefit for me, at least.  I want to
see correct fontification when I type a quote mark, not 2 seconds of
inactivity later.

> I've only done so much work testing each of these
> assertions, and I'd of course be interested in hearing
> (concrete) objections.

There will be users who will not like this new minor mode.  It should
not be imposed upon them.

Anyhow, as I said, I will accept Eli's judgment on this point.

> João

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: jit-lock-antiblink-grace

[João Távora]

On Mon, Nov 25, 2019 at 8:11 PM Alan Mackenzie <acm@muc.de> wrote:

> For me, at least, point 1 doesn't hold.  Having the fontification
> delayed until 2 seconds of inactivity would for me be intensely
> irritating.

This is not how it works. The only thing that is delayed is
guaranteed to be unwanted, namely, fontifying as string
a big chunk of the buffer that we know wasn't a string
before the user opened a string.

So what my change does is that this unwanted thing
now comes later, if at all.

> As for point 3, there would be no benefit for me, at least.  I want to
> see correct fontification when I type a quote mark, not 2 seconds of
> inactivity later.

Again: this is not how it works. I encourage you to try it out
(and/or read the discussion from the beginning).

And you are confusing two things: One is immediate and
correct fontification, which I agree is desirable, but comes
at a large performance cost for languages that permit multi-line
strings.  The other is an improvement on the current situation.

Thanks,
João

Re: jit-lock-antiblink-grace

[João Távora]

On Mon, Nov 25, 2019 at 8:23 PM João Távora <joaotavora@gmail.com> wrote:
>
> On Mon, Nov 25, 2019 at 8:11 PM Alan Mackenzie <acm@muc.de> wrote:
>
> > For me, at least, point 1 doesn't hold.  Having the fontification
> > delayed until 2 seconds of inactivity would for me be intensely
> > irritating.
>
> This is not how it works. The only thing that is delayed is
> guaranteed to be unwanted, namely, fontifying as string
> a big chunk of the buffer that we know wasn't a string
> before the user opened a string.

Actually, let me clarify this "guaranteed to be unwanted".
The "unwanted" fontification of the large part of the buffer is
guaranteed never to be fully correct, I think.  But some of
it _might_ be correct, and, as such, helpful, namely when
you really want to define a multi-line string by first entering
the quote, thus unbalancing the whole buffer (and incorrectly
fontifying a part of it), paging down some lines, and then
rebalancing it by entering another quote.

(If it weren't so, we could downright abolish the behaviour,
equivalent to setting jit-lock-antiblink-grace to infinity.)

But even in that particular case, whose frequency I presume to
be minute in proportion to the number of opened-and-closed
strings, it can be argued that the patch has a benefit,
since it's normally easier to spot where you want to end the
new string made of existing non-string text when it's fontified
as non-string text.  The amount of CPU spent is also lower.

João Távora

Re: jit-lock-antiblink-grace

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 6743 bytes --]

On Mon, Nov 25, 2019 at 9:07 PM João Távora <joaotavora@gmail.com> wrote:

> But even in that particular case, whose frequency I presume to
> be minute in proportion to the number of opened-and-closed
> strings, it can be argued that the patch has a benefit,
> since it's normally easier to spot where you want to end the
> new string made of existing non-string text when it's fontified
> as non-string text.  The amount of CPU spent is also lower.

A correction, again.  This paragraph is an inaccurate description
of how jit-lock-antiblink-grace works when the user wants to
insert multi-line strings. In fact, I believe that scenario produce
mostly the same behaviour in both antiblink-on/antiblink-off cases.

The best way to explain it to show it in action, so I hope the
animated gifs illustrate (from Emacs -Q).

Eli, I also attach an updated patch (which I hope Gmail doesn't
mangle) with the fixes you requested earlier.

Thanks,
João

diff --git a/etc/NEWS b/etc/NEWS
index 7e86ccc71e..e66dd4a21c 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -604,6 +604,13 @@ If the region is active, the command joins all
the lines in the
 region.  When there's no active region, the command works on the
 current and the previous or the next line, as before.

+---
+** New customizable variable 'jit-lock-antiblink-grace'.
+When adding strings to source code, this helps avoid
+\"blinking\", an unwanted oscillation of certain regions between
+string and non-string fontification.
+
+

 * Changes in Specialized Modes and Packages in Emacs 27.1

diff --git a/lisp/jit-lock.el b/lisp/jit-lock.el
index 48998a81fe..23afb53bf8 100644
--- a/lisp/jit-lock.el
+++ b/lisp/jit-lock.el
@@ -123,6 +123,20 @@ jit-lock-context-time
   :type '(number :tag "seconds")
   :group 'jit-lock)

+(defcustom jit-lock-antiblink-grace 2
+  "Idle time after which to refontify due to unterminated strings.
+If the user creates a temporarily unterminated string up to the
+end of the current line, that part of the line is fontified after
+`jit-lock-context-time', but an extended idle \"grace\" period of
+this many seconds is granted before deciding it is a multi-line
+string and fontifying the remainder of the buffer accordingly.
+When adding strings to source code, this helps avoid
+\"blinking\", an unwanted oscillation of certain regions between
+string and non-string fontification.  If nil, there is no grace
+period."
+  :type '(number :tag "seconds")
+  :group 'jit-lock)
+
 (defcustom jit-lock-defer-time nil ;; 0.25
   "Idle time after which deferred fontification should take place.
 If nil, fontification is not deferred.
@@ -157,6 +171,15 @@ jit-lock-defer-buffers
   "List of buffers with pending deferred fontification.")
 (defvar jit-lock-stealth-buffers nil
   "List of buffers that are being fontified stealthily.")
+
+(defvar jit-lock--antiblink-grace-timer nil
+  "Idle timer for fontifying unterminated string or comment, or nil.")
+(defvar jit-lock--antiblink-line-beginning-position (make-marker)
+  "Last line beginning position after last command (a marker).")
+(defvar jit-lock--antiblink-string-or-comment nil
+  "Non-nil if in string or comment after last command (a boolean).")
+
+

 ;;; JIT lock mode

@@ -232,7 +255,10 @@ jit-lock-mode
       (unless jit-lock-context-timer
         (setq jit-lock-context-timer
               (run-with-idle-timer jit-lock-context-time t
-                                   'jit-lock-context-fontify)))
+                                   (lambda ()
+                                     (unless jit-lock--antiblink-grace-timer
+                                       (jit-lock-context-fontify))))))
+      (add-hook 'post-command-hook 'jit-lock--antiblink-post-command nil t)
       (setq jit-lock-context-unfontify-pos
             (or jit-lock-context-unfontify-pos (point-max))))

@@ -669,6 +695,55 @@ jit-lock-after-change
               ;; buffer, only jit-lock-context-* will re-fontify it.
               (min jit-lock-context-unfontify-pos jit-lock-start))))))

+(defun jit-lock--antiblink-post-command ()
+  (let* ((new-l-b-p (copy-marker (line-beginning-position)))
+         (l-b-p-2 (line-beginning-position 2))
+         (same-line
+          (and jit-lock-antiblink-grace
+               (not (= new-l-b-p l-b-p-2))
+               (eq (marker-buffer jit-lock--antiblink-line-beginning-position)
+                   (current-buffer))
+               (= new-l-b-p jit-lock--antiblink-line-beginning-position)))
+         (new-s-o-c
+          (and same-line
+               (nth 8 (save-excursion (syntax-ppss l-b-p-2))))))
+    (cond (;; opened a new multiline string...
+           (and same-line
+                (null jit-lock--antiblink-string-or-comment) new-s-o-c)
+           (setq jit-lock--antiblink-grace-timer
+                 (run-with-idle-timer jit-lock-antiblink-grace nil
+                                      (lambda ()
+                                        (jit-lock-context-fontify)
+                                        (setq jit-lock--antiblink-grace-timer
+                                              nil)))))
+          (;; closed an unterminated multiline string.
+           (and same-line
+                (null new-s-o-c) jit-lock--antiblink-string-or-comment)
+           ;; Kill the grace timer, might already have run and died.
+           ;; Don't refontify immediately: it adds an unreasonable
+           ;; delay to a well-behaved operation.  Leave it for the
+           ;; `jit-lock-context-timer' as usual.
+           (when jit-lock--antiblink-grace-timer
+             (cancel-timer jit-lock--antiblink-grace-timer)
+             (setq jit-lock--antiblink-grace-timer nil)))
+          (same-line
+           ;; in same line, but no state change, leave everything as it was
+           )
+          (t
+           ;; left the line somehow or customized feature away, etc
+           ;; kill timer if running, resume normal operation.
+           (when jit-lock--antiblink-grace-timer
+             ;; Do refontify immediately, adding a small delay.  This
+             ;; is per Lars' request, and it makes sense because we
+             ;; should remark somehow that we are leaving the unstable
+             ;; state.
+             (jit-lock-context-fontify)
+             (cancel-timer jit-lock--antiblink-grace-timer)
+             (setq jit-lock--antiblink-grace-timer nil))))
+    ;; update variables
+    (setq jit-lock--antiblink-line-beginning-position   new-l-b-p
+          jit-lock--antiblink-string-or-comment new-s-o-c)))
+
 (provide 'jit-lock)

 ;;; jit-lock.el ends here

[-- Attachment #2: antiblink-on.gif --]
[-- Type: image/gif, Size: 183742 bytes --]

[-- Attachment #3: multi-line-strings-antiblink-on-and-off.gif --]
[-- Type: image/gif, Size: 450963 bytes --]

[-- Attachment #4: antiblink-off.gif --]
[-- Type: image/gif, Size: 499091 bytes --]

Re: jit-lock-antiblink-grace

[Stefan Monnier]

> I could have made exactly these arguments for enabling "my" new
> features by default.

FWIW, this antiblink thingy eliminates (or at least reduces) an
annoyance rather than provides a feature.  I wouldn't go as far as to
claim it's a bug fix, but it's closer to it than to a feature, IMO.


        Stefan

Re: jit-lock-antiblink-grace

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Tue, 26 Nov 2019 02:30:12 +0000
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel <emacs-devel@gnu.org>, 
> 	Alan Mackenzie <acm@muc.de>
> 
> +---
> +** New customizable variable 'jit-lock-antiblink-grace'.
> +When adding strings to source code, this helps avoid
> +\"blinking\", an unwanted oscillation of certain regions between
> +string and non-string fontification.

Escaping quotes in NEWS is not needed/expected.

And this entry doesn't say what is the default value, and doesn't tell
how to get back old behavior.

> +(defcustom jit-lock-antiblink-grace 2
> +  "Idle time after which to refontify due to unterminated strings.
> +If the user creates a temporarily unterminated string up to the
> +end of the current line, that part of the line is fontified after
> +`jit-lock-context-time', but an extended idle \"grace\" period of
> +this many seconds is granted before deciding it is a multi-line
> +string and fontifying the remainder of the buffer accordingly.
> +When adding strings to source code, this helps avoid
> +\"blinking\", an unwanted oscillation of certain regions between
> +string and non-string fontification.  If nil, there is no grace
> +period."

This is too wordy.  If you think this description is necessary, we
probably need to move most of it into the user manual.

> +  :type '(number :tag "seconds")
> +  :group 'jit-lock)

Missing :version.

> +           (when jit-lock--antiblink-grace-timer
> +             ;; Do refontify immediately, adding a small delay.  This
> +             ;; is per Lars' request, and it makes sense because we
                      ^^^^^^^^^^^^^^^^^
Let's leave personae out of the code, okay?

Thanks.

Re: jit-lock-antiblink-grace

[João Távora]

Eli Zaretskii <eliz@gnu.org> writes:

>> +---
>> +** New customizable variable 'jit-lock-antiblink-grace'.
>> +When adding strings to source code, this helps avoid
>> +\"blinking\", an unwanted oscillation of certain regions between
>> +string and non-string fontification.
>
> Escaping quotes in NEWS is not needed/expected.

Fixed.

> And this entry doesn't say what is the default value, and doesn't tell
> how to get back old behavior.

Fixed.

I didn't mention because I found examples in NEWS that don't.  But
mostly because we haven't come to a decision yet.  I generally agree
with Stefan and I propose the latest patch with the default value of 2
seconds for jit-lock-antiblink-grace.

However, I have detected a case where jit-lock-antiblink-grace kicks in
and, while not exactly causing a regression in useful behaviour, also
doesn't add any useful behaviour.  Here is the case:

a.  You want to make a string region in a non-string buffer of 10 lines
    between line 3 and 7.
b.  You go to line 7 and type a quote
c.  You go to line 3 and type a quote

Previously, after step b) you would get lines 8, 9, and 10 (and 7
partially) string-fontified "immediately".

Now, after step b), and _if stay on the same line_, it takes 2 seconds
for lines 7-10 to be string-fontified.  If you leave line 7 in your
journey to line 3 before those 2 seconds are up, 7-10 are immediately
string-fontified (and the old and new version become identical in
behaviour).

It may be argued by users that create strings like this that the
antiblink grace timer wasn't useful at all, or that it mis-fired: these
users were already counting on (temporarily) invalidly fontified lines
7-10, so they were suprised that it didn't happen immediately (or rather
that it didn't happen after a short jit-lock-context-time delay).

I think most users will do step c) before step b), and this doesn't
present any problem.

>> +(defcustom jit-lock-antiblink-grace 2
>> +  "Idle time after which to refontify due to unterminated strings.
>> +If the user creates a temporarily unterminated string up to the
>> +end of the current line, that part of the line is fontified after
>> +`jit-lock-context-time', but an extended idle \"grace\" period of
>> +this many seconds is granted before deciding it is a multi-line
>> +string and fontifying the remainder of the buffer accordingly.
>> +When adding strings to source code, this helps avoid
>> +\"blinking\", an unwanted oscillation of certain regions between
>> +string and non-string fontification.  If nil, there is no grace
>> +period."
>
> This is too wordy.  If you think this description is necessary, we
> probably need to move most of it into the user manual.

Fixed.  Tho you'll see it was about as wordy as the other jit-lock
defcustoms preceding it.  Hope it's better now.

>> +  :type '(number :tag "seconds")
>> +  :group 'jit-lock)
>
> Missing :version.

Fixed.

>> +           (when jit-lock--antiblink-grace-timer
>> +             ;; Do refontify immediately, adding a small delay.  This
>> +             ;; is per Lars' request, and it makes sense because we
>                       ^^^^^^^^^^^^^^^^^
> Let's leave personae out of the code, okay?

I really meant the person.  But okay.

João

diff --git a/etc/NEWS b/etc/NEWS
index 7e86ccc71e..2f2acd52ac 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -604,6 +604,13 @@ If the region is active, the command joins all the lines in the
 region.  When there's no active region, the command works on the
 current and the previous or the next line, as before.
 
+---
+** New customizable variable 'jit-lock-antiblink-grace'.
+When typing strings, this helps avoid "blinking", an oscillation
+between string and non-string fontification.  The variable holds a
+number of seconds (default is 2) before a potentially unwanted
+fontification starts.  Set to nil to deactivate.
+
 \f
 * Changes in Specialized Modes and Packages in Emacs 27.1
 
diff --git a/lisp/jit-lock.el b/lisp/jit-lock.el
index 48998a81fe..c896c9d5ea 100644
--- a/lisp/jit-lock.el
+++ b/lisp/jit-lock.el
@@ -123,6 +123,20 @@ jit-lock-context-time
   :type '(number :tag "seconds")
   :group 'jit-lock)
 
+(defcustom jit-lock-antiblink-grace 2
+  "Grace period after which to refontify due to unterminated strings.
+If nil, no grace period is given.  Otherwise, a newly created
+unterminated string is fontified only to the end of the current
+line, after which the system waits this many seconds of idle time
+before deciding the string is multi-line and fontifying the
+remaining lines.  When typing strings, this helps avoid
+\"blinking\", an unwanted oscillation between string and
+non-string fontification."
+  :type '(choice (const :tag "never" nil)
+	         (number :tag "seconds"))
+  :group 'jit-lock
+  :version "27.1")
+
 (defcustom jit-lock-defer-time nil ;; 0.25
   "Idle time after which deferred fontification should take place.
 If nil, fontification is not deferred.
@@ -157,6 +171,13 @@ jit-lock-defer-buffers
   "List of buffers with pending deferred fontification.")
 (defvar jit-lock-stealth-buffers nil
   "List of buffers that are being fontified stealthily.")
+
+(defvar jit-lock--antiblink-grace-timer nil
+  "Idle timer for fontifying unterminated string or comment, or nil.")
+(defvar jit-lock--antiblink-line-beginning-position (make-marker)
+  "Last line beginning position after last command (a marker).")
+(defvar jit-lock--antiblink-string-or-comment nil
+  "Non-nil if in string or comment after last command (a boolean).")
 \f
 ;;; JIT lock mode
 
@@ -232,7 +253,10 @@ jit-lock-mode
       (unless jit-lock-context-timer
         (setq jit-lock-context-timer
               (run-with-idle-timer jit-lock-context-time t
-                                   'jit-lock-context-fontify)))
+                                   (lambda ()
+                                     (unless jit-lock--antiblink-grace-timer
+                                       (jit-lock-context-fontify))))))
+      (add-hook 'post-command-hook 'jit-lock--antiblink-post-command nil t)
       (setq jit-lock-context-unfontify-pos
             (or jit-lock-context-unfontify-pos (point-max))))
 
@@ -669,6 +693,54 @@ jit-lock-after-change
               ;; buffer, only jit-lock-context-* will re-fontify it.
               (min jit-lock-context-unfontify-pos jit-lock-start))))))
 
+(defun jit-lock--antiblink-post-command ()
+  (let* ((new-l-b-p (copy-marker (line-beginning-position)))
+         (l-b-p-2 (line-beginning-position 2))
+         (same-line
+          (and jit-lock-antiblink-grace
+               (not (= new-l-b-p l-b-p-2))
+               (eq (marker-buffer jit-lock--antiblink-line-beginning-position)
+                   (current-buffer))
+               (= new-l-b-p jit-lock--antiblink-line-beginning-position)))
+         (new-s-o-c
+          (and same-line
+               (nth 8 (save-excursion (syntax-ppss l-b-p-2))))))
+    (cond (;; opened a new multiline string...
+           (and same-line
+                (null jit-lock--antiblink-string-or-comment) new-s-o-c)
+           (setq jit-lock--antiblink-grace-timer
+                 (run-with-idle-timer jit-lock-antiblink-grace nil
+                                      (lambda ()
+                                        (jit-lock-context-fontify)
+                                        (setq jit-lock--antiblink-grace-timer
+                                              nil)))))
+          (;; closed an unterminated multiline string.
+           (and same-line
+                (null new-s-o-c) jit-lock--antiblink-string-or-comment)
+           ;; Kill the grace timer, might already have run and died.
+           ;; Don't refontify immediately: it adds an unreasonable
+           ;; delay to a well-behaved operation.  Leave it for the
+           ;; `jit-lock-context-timer' as usual.
+           (when jit-lock--antiblink-grace-timer
+             (cancel-timer jit-lock--antiblink-grace-timer)
+             (setq jit-lock--antiblink-grace-timer nil)))
+          (same-line
+           ;; in same line, but no state change, leave everything as it was
+           )
+          (t
+           ;; left the line somehow or customized feature away, etc
+           ;; kill timer if running, resume normal operation.
+           (when jit-lock--antiblink-grace-timer
+             ;; Do refontify immediately, adding a small delay.  This
+             ;; makes sense because it remarks somehow that we are
+             ;; leaving the unstable state.
+             (jit-lock-context-fontify)
+             (cancel-timer jit-lock--antiblink-grace-timer)
+             (setq jit-lock--antiblink-grace-timer nil))))
+    ;; update variables
+    (setq jit-lock--antiblink-line-beginning-position new-l-b-p
+          jit-lock--antiblink-string-or-comment new-s-o-c)))
+
 (provide 'jit-lock)
 
 ;;; jit-lock.el ends here

Re: jit-lock-antiblink-grace

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Cc: monnier@iro.umontreal.ca,  emacs-devel@gnu.org,  acm@muc.de
> Date: Sat, 30 Nov 2019 19:11:57 +0000
> 
> a.  You want to make a string region in a non-string buffer of 10 lines
>     between line 3 and 7.
> b.  You go to line 7 and type a quote
> c.  You go to line 3 and type a quote
> 
> Previously, after step b) you would get lines 8, 9, and 10 (and 7
> partially) string-fontified "immediately".
> 
> Now, after step b), and _if stay on the same line_, it takes 2 seconds
> for lines 7-10 to be string-fontified.  If you leave line 7 in your
> journey to line 3 before those 2 seconds are up, 7-10 are immediately
> string-fontified (and the old and new version become identical in
> behaviour).

So how is this a problem, if at worst we get the old behavior?

> +** New customizable variable 'jit-lock-antiblink-grace'.
> +When typing strings, this helps avoid "blinking", an oscillation
> +between string and non-string fontification.  The variable holds a
> +number of seconds (default is 2) before a potentially unwanted
> +fontification starts.  Set to nil to deactivate.
                          ^^^^^^^^^^^^^^^^^^^^^^^^
"Deactivate" is not self-explanatory here, because the text didn't
mention any "activation".  I suggest this instead:

  Set to nil to get back the old behavior.

Thanks.

Re: jit-lock-antiblink-grace

[João Távora]

Eli Zaretskii <eliz@gnu.org> writes:

>>     between line 3 and 7.
>> b.  You go to line 7 and type a quote
>> c.  You go to line 3 and type a quote
>> 
>> Previously, after step b) you would get lines 8, 9, and 10 (and 7
>> partially) string-fontified "immediately".
>> 
>> Now, after step b), and _if stay on the same line_, it takes 2 seconds
>> for lines 7-10 to be string-fontified.  If you leave line 7 in your
>> journey to line 3 before those 2 seconds are up, 7-10 are immediately
>> string-fontified (and the old and new version become identical in
>> behaviour).
>
> So how is this a problem, if at worst we get the old behavior?

After b), you now have to wait 2 seconds (jit-lock-antiblink-grace)
before you get the old behaviour (string-fontifying 7-10).  Previously,
you would get it after 0.5 seconds (jit-lock-context-time).  It's
arguable that the new behaviour is worse than the old one, for the
specific case where you already expected lines 7-10 to be temporarily
invalidly fontified anyway. (I say "invalid" because the user's
intention is to move up to line 3)

Anyway, I think it's a pretty minor thing, but I wanted to record it for
completeness.

>> +** New customizable variable 'jit-lock-antiblink-grace'.
>> +When typing strings, this helps avoid "blinking", an oscillation
>> +between string and non-string fontification.  The variable holds a
>> +number of seconds (default is 2) before a potentially unwanted
>> +fontification starts.  Set to nil to deactivate.
>                           ^^^^^^^^^^^^^^^^^^^^^^^^
> "Deactivate" is not self-explanatory here, because the text didn't
> mention any "activation".  I suggest this instead:
>
>   Set to nil to get back the old behavior.

OK.

I will also add the "set marker buffer to nil" optimization that Alan
suggested.

If there's no further comments, I will push this to master in a day or
so.

João

Re: jit-lock-antiblink-grace

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Cc: monnier@iro.umontreal.ca,  emacs-devel@gnu.org,  acm@muc.de
> Date: Sat, 30 Nov 2019 20:12:51 +0000
> 
> >> b.  You go to line 7 and type a quote
> >> c.  You go to line 3 and type a quote
> >> 
> >> Previously, after step b) you would get lines 8, 9, and 10 (and 7
> >> partially) string-fontified "immediately".
> >> 
> >> Now, after step b), and _if stay on the same line_, it takes 2 seconds
> >> for lines 7-10 to be string-fontified.  If you leave line 7 in your
> >> journey to line 3 before those 2 seconds are up, 7-10 are immediately
> >> string-fontified (and the old and new version become identical in
> >> behaviour).
> >
> > So how is this a problem, if at worst we get the old behavior?
> 
> After b), you now have to wait 2 seconds (jit-lock-antiblink-grace)
> before you get the old behaviour (string-fontifying 7-10).

Isn't this the new behavior?

Re: jit-lock-antiblink-grace

[João Távora]

On Sat, Nov 30, 2019 at 8:17 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: João Távora <joaotavora@gmail.com>
> > Cc: monnier@iro.umontreal.ca,  emacs-devel@gnu.org,  acm@muc.de
> > Date: Sat, 30 Nov 2019 20:12:51 +0000
> >
> > >> b.  You go to line 7 and type a quote
> > >> c.  You go to line 3 and type a quote
> > >>
> > >> Previously, after step b) you would get lines 8, 9, and 10 (and 7
> > >> partially) string-fontified "immediately".
> > >>
> > >> Now, after step b), and _if stay on the same line_, it takes 2 seconds
> > >> for lines 7-10 to be string-fontified.  If you leave line 7 in your
> > >> journey to line 3 before those 2 seconds are up, 7-10 are immediately
> > >> string-fontified (and the old and new version become identical in
> > >> behaviour).
> > >
> > > So how is this a problem, if at worst we get the old behavior?
> >
> > After b), you now have to wait 2 seconds (jit-lock-antiblink-grace)
> > before you get the old behaviour (string-fontifying 7-10).
>
> Isn't this the new behavior?

Yes, but in this very particular case, it doesn't gain you anything,
IMO.

João Távora

Re: jit-lock-antiblink-grace

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Sat, 30 Nov 2019 20:19:35 +0000
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel <emacs-devel@gnu.org>, 
> 	Alan Mackenzie <acm@muc.de>
> 
> > > > So how is this a problem, if at worst we get the old behavior?
> > >
> > > After b), you now have to wait 2 seconds (jit-lock-antiblink-grace)
> > > before you get the old behaviour (string-fontifying 7-10).
> >
> > Isn't this the new behavior?
> 
> Yes, but in this very particular case, it doesn't gain you anything,
> IMO.

But you don't lose anything, either, right?

Re: jit-lock-antiblink-grace

[João Távora]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: João Távora <joaotavora@gmail.com>
>> Date: Sat, 30 Nov 2019 20:19:35 +0000
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel <emacs-devel@gnu.org>, 
>> 	Alan Mackenzie <acm@muc.de>
>> 
>> > > > So how is this a problem, if at worst we get the old behavior?
>> > >
>> > > After b), you now have to wait 2 seconds (jit-lock-antiblink-grace)
>> > > before you get the old behaviour (string-fontifying 7-10).
>> >
>> > Isn't this the new behavior?
>> 
>> Yes, but in this very particular case, it doesn't gain you anything,
>> IMO.
>
> But you don't lose anything, either, right?

Depends on how you look at it.  Let me try to explain.

jit-lock-antiblink-grace is based on presumptions, the main one being
that when you open a string, no two seconds of idle time will elapse
before you close it.  The presumption is also that you will close it
in a further position of the buffer.

In the edge case I described, that doesn't hold: the user wants to close
the string in a previous position.  So I speculate that that user is
accustomed to the old behaviour and will find it odd that the invalid
fontification -- which he/she expects and potentially even likes and
which used to come almost immediately -- now only comes after two
seconds, or when moving up the line.

This is fundamentally different from the main use case of
jit-lock-antiblink, where we are certain that near-immediate invalid
fontification will annoy the user, who we presume will "soon" close the
string.  So delaying that annoying thing is a good decision.

I only mentioned this edge case (which doesn't affect me, personally)
because previously I had written I could not find any useful behaviour
lost by jit-lock-antiblink.  I am doing this for completeness because we
know changing any default is potentially controversial (cue
https://xkcd.com/1172/).

João

Re: jit-lock-antiblink-grace

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Sat, 30 Nov 2019 22:00:24 +0000
> Cc: acm@muc.de, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> >> > Isn't this the new behavior?
> >> 
> >> Yes, but in this very particular case, it doesn't gain you anything,
> >> IMO.
> >
> > But you don't lose anything, either, right?
> 
> Depends on how you look at it.  Let me try to explain.

Thanks.  I still think this is very much like the old behavior, so I
wouldn't be bothered by it.

Re: jit-lock-antiblink-grace

[João Távora]

On Sun, Dec 1, 2019 at 7:13 PM Eli Zaretskii <eliz@gnu.org> wrote:

> Thanks.  I still think this is very much like the old behavior, so I
> wouldn't be bothered by it.

In the absence of more comments, I pushed the antiblink to master.
It's commit 5b45c26.  For those of you that don't use a quote-matching
solution like electric-pair-mode, paredit, or something else,  let me
know if you like the new behaviour, if you're bothered by it, or just
indifferent.

Thanks,
João

Re: jit-lock-antiblink-grace

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Wed, 4 Dec 2019 23:45:51 +0100
> Cc: Alan Mackenzie <acm@muc.de>, Stefan Monnier <monnier@iro.umontreal.ca>, 
> 	emacs-devel <emacs-devel@gnu.org>
> 
> In the absence of more comments, I pushed the antiblink to master.
> It's commit 5b45c26.  For those of you that don't use a quote-matching
> solution like electric-pair-mode, paredit, or something else,  let me
> know if you like the new behaviour, if you're bothered by it, or just
> indifferent.

Thanks.  I tweaked the documentation a bit.