[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: jit-lock-antiblink-grace

From: Eli Zaretskii
Subject: Re: jit-lock-antiblink-grace
Date: Sun, 13 Oct 2019 12:22:11 +0300

> From: João Távora <address@hidden>
> Date: Sun, 13 Oct 2019 09:47:24 +0100
> Cc: emacs-devel <address@hidden>, Stefan Monnier <address@hidden>
> > > 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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]