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

Previous Next

Package: emacs;

Reported by: Ihor Radchenko <yantar92 <at> gmail.com>

Date: Tue, 19 Jul 2022 04:15:02 UTC

Severity: normal

Found in version 28.1.90

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> gmail.com>
Cc: 56637 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers
Date: Thu, 21 Jul 2022 15:49:38 +0300
> From: Ihor Radchenko <yantar92 <at> gmail.com>
> Cc: monnier <at> iro.umontreal.ca,  56637 <at> debbugs.gnu.org
> Date: Thu, 21 Jul 2022 20:44:23 +0800
> 
> > Sorry, I don't understand: once Emacs loads a major mode, it stays
> > loaded, unless you forcibly unload it.  Or what do you mean by "load
> > major mode"?
> 
> If fontification is done in temporary throwaway buffers that are closed
> immediately after fontification, next portion of text that should be
> fontified in the same major mode will need to create a new throwaway
> buffer, turn on the relevant major mode, and perform fontification.
> Hence, major mode will need to be loaded every single time we need to
> fontify a text fragment.

It is not "loaded", it is "activated".  "Loading" in Emacs means
loading the Lisp package that implements the mode, and that is done
only once.  We don't unload packages when buffers are killed.

> > And why do you assume that erasing a buffer and then inserting some
> > text into it will be significantly faster than turning on a mode in
> > it?  It sounds like another fragile assumption.
> 
> It is usually true from my experience.

Well, "usually" is not a guarantee it will always be so.

Anyway, if this is the issue, we could add another way of marking a
buffer as "invisible for user", one that is not based on the buffer's
name.

> (5.531764251 0 0.0)
> (0.012424528 0 0.0)
> 
> Over 400x difference.

Sorry, but this proves nothing, and I'm sure you know it.

To me, this is just one more fragile assumption on which Org code is
based that is bound to be broken some day.




This bug report was last modified 3 years and 55 days ago.

Previous Next


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