Re: jit-lock-antiblink-grace

[Eli Zaretskii <eliz@gnu.org>]

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