Re: jit-lock-antiblink-grace

[Eli Zaretskii <eliz@gnu.org>]

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