On Sat, Oct 12, 2019 at 5:05 PM Eli Zaretskii <
address@hidden> wrote:
>
> > From: João Távora <
address@hidden>
> > Date: Sat, 12 Oct 2019 15:23:08 +0100
> > Cc: emacs-devel <
address@hidden>, Stefan Monnier <
address@hidden>
> >
> > > 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