On Sun, Oct 13, 2019 at 7:39 AM Eli Zaretskii <
address@hidden> wrote:
>
> > From: João Távora <
address@hidden>
> > Date: Sat, 12 Oct 2019 22:55:29 +0100
> > Cc: emacs-devel <
address@hidden>, Stefan Monnier <
address@hidden>
> 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.
I had already mentioned :set, but iiuc it only works via customize. The
other techniques you mention are the (relatively) hacky ones I had in
mind, too.
> > > 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.
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.
> > 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.
Of course, there is different behaviour in every feature except a
refactorization.
> 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?
Hmmm. We might be miscommunicating (or you might be seeing a bug). When
you start to type a comment or a string, you still get "almost immediate
visual feedback" just you did before. This has not changed at all. If
the command you just performed, say, insert or delete a quote:
1. _created_ a situation if unbalanced quotes at EOL, then the typical
"flipping" of the fontification of many lines _after_ the current is
delayed, because the system believes you will probably solve the
situation within jit-lock-antiblink-grace seconds;
2. _restored_ a situation of balanced quotes, then everything should be
as before.
A core assumption here is that the user very rarely wants to create
deliberate unbalance of strings. Those users, were they to exist in
great numbers, would probably be bothered by the grace delay.
Anyway, it is only in situation 1 that the amplitude of "visual
feedback" is reduced, because the system considers the extra visual
feedback related to the real possibility of inserting a multi-line
string, is alarmist/premature/unjustified. Do I explain myself?
> > > > 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.
I meant Emacs-wide, of course. There is display-warning-minimum-level
and warning-minimum-log-level tho, which I wish were easier to control.
> 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.
I don't (and I don't like these package-specific solutions). And that's
precisely why I settled on a 'message' as a middle-of-the-road solution.
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. I can use a suitably parameterized
'warn', a cl-assertion, an error, or just get rid of it.
João