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: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
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: Wed, 20 Jul 2022 14:12:29 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: yantar92 <at> gmail.com,  56637 <at> debbugs.gnu.org
> Date: Tue, 19 Jul 2022 17:12:44 -0400
> 
> 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.

I can: we don't need, and really shouldn't, attempt to cater to each
corner use case in core.  Doing that (and we've been doing that for
quite some time) makes Emacs a larger and less maintainable monster
than it needs to be or already is.  The gain for everyone is minimal,
the gain for those who must for some reason cope with such situations
is small (compared with the above alternative or something like it),
while the damage in terms of being able to know what Emacs does
without stepping through the code with a debugger -- that damage is
quite significant.  You already have one symptom of the monster's
size: I already cannot tell which hooks are and aren't running in
temporary buffers without consulting the sources.  Way to go, Emacs!

> It's not like there a deep technical reason why font-lock should not be
> enabled under any circumstance in those cases.

There are practical reasons why it shouldn't in the vast majority of
cases.  The few rare cases which do have easy workarounds, and I see
absolutely no reason why they couldn't take one of them.

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

See above.

Previous Next

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