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

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 56637 <at> debbugs.gnu.org, yantar92 <at> gmail.com
Subject: bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers
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.

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

Also, most of those buffers have no font-lock rules installed so
(font-lock-specified-p mode) should return nil and
`font-lock-default-function` won't call `font-lock-mode-internal`.

But yes, if we do it naively, we'll surely bump into corner cases where
there happens to be font-lock rules setup and where jit-lock is disabled
for some reason, or something else ends up causing some of the font-lock
machinery to be run.

Or maybe just running font-lock's setup code itself ends up too costly
for some reason.

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

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

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.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.