bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: yantar92@gmail.com,  56637@debbugs.gnu.org
> Date: Tue, 19 Jul 2022 15:21:22 -0400
> 
> >> >> FWIW, I do think it would be good to remove the rule that font-lock is
> >> >> never enabled in temp buffers.
> >> > I don't.
> >> I think we agree :-)
> >> More seriously, I didn't mean to remove it willy-nilly, but that it's
> >> a desirable goal and the question is how to get there.
> > Why is that a desirable goal?
> 
> Because testing `noninteractive` and the presence of a leading space are
> just heuristics and they aren't quite right.  IOW it's a handy hack but
> it's just a hack.

I agree with its being a heuristic, but disagree that they aren't
quite right, and definitely not that they are a hack.  Its our way to
have cheap temporary buffers, and it works quite well.

> > It slows down stuff that is never displayed.
> 
> That's why I say that we shouldn't do it "willy-nilly".
> 
> > And if that buffer has very long lines, it slows Emacs down considerably.
> 
> I think currently it should basically never be the case, because the
> actual fontification (the part which pays attention to lines) only
> happens via jit-lock, which should never trigger if those buffers
> aren't displayed.

jit-lock _will_ trigger if you invoke some APIs that call display
routines.  And that's just one way font-lock can slow down there.

> >> We could start by adding a new variable
> >> `font-lock-allow-in-temporary-buffer`, which packages could set
> >> buffer-locally in those rare temp buffers where they do want to enable
> >> font-lock, as in the untested patch below.
> > This is a slippery slope.  Next some other corner case will want to
> > run buffer-modification hooks in a temporary buffer, so we invent
> > another variable, and so on and so forth.
> 
> Hmm... we do run buffer-modification hooks in temp buffers.

Sorry, I meant kill-buffer-hook, kill-buffer-query-functions, and
buffer-list-update-hook.

> > I'd rather introduce a macro like with-temp-buffer, but one that can
> > accept a buffer name, and ask such applications to please name their
> > temporary buffers something that doesn't begin with a space.
> 
> The purpose of the leading space, AFAIK is to avoid displaying the
> buffer in `read-buffer`.  Forcing those buffers to appear in
> `read-buffer` just because we need to run font-lock in there
> sounds wrong.

That's fixable, and even if we do that in core (something that I'm not
sure is needed), it is still better than having variables to
selectively enable what we generally want to disable in temporary
buffers.

And then, of course, people are free to write their own macros that
are like with-temp-buffer, but different in some way.  Why do we need
to cater for every corner case in core?

> If you don't like `font-lock-allow-in-temporary-buffer`, we could have
> a new function `font-lock-enable-unconditionally` which does the same as
> `font-lock-mode` but skips the (or noninteractive (eq (aref
> (buffer-name) 0) ?\s)) test.

Ouch!