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

[Stefan Monnier]

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

IIUC these used to be run also in temp buffers, so I don't have yet much
intuition for how likely it is that we'll need to avoid those cases.
But, AFAIK these *are* run in batch mode, so it's a slightly
different situation.

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

Basically, there is a need to have buffers which have font-lock enabled yet
should be hidden from `read-buffer`.  We could try to fix that on the
side of `internal-complete-buffer`, admittedly.

But there is also a need for buffers with font-lock in batch mode
(typically for testing purposes), so changing `internal-complete-buffer`
is not sufficient.

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

Whether you use `with-temp-buffer` or your own macro, you're still stuck
with the choice between "either can't use font-lock or it shows up in `C-x b`".
Of course, people can use hacks like

   (defun really-turn-on-font-lock ()
     (unwind-protect
         (let ((noninteractive nil))
           (rename-buffer (concat "\0" (buffer-name)))
           (font-lock-mode 1))
       (when (eq ?\0 (aref (buffer-name) 0))
         (rename-buffer (substring (buffer-name) 1)))))

But I can't see why we shouldn't accommodate those needs more directly.
It's not like there a deep technical reason why font-lock should not be
enabled under any circumstance in those cases.

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

I don't understand this reaction.  The code would be just as clean as
the current `font-lock-mode` and it's not like there's any reason to
think that people would abuse such a function.


        Stefan