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