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:26:47 +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:09:55 +0800
> 
> >> Is it always guaranteed by Emacs that font-lock-fontify-buffer correctly
> >> fontifies that buffer even when font-lock-mode is disabled?
> >
> > IMO, if it doesn't, it's a bug that should be fixed.  If you have
> > recipes where it happens, please submit a bug report.
> 
> Create a file called bug.el with the following text:
> 
> (with-current-buffer (get-buffer-create "Test")
>   (emacs-lisp-mode)
>   (insert "(message \"Foo\")")
>   (font-lock-ensure)
>   (message "%S" (buffer-string)))
> 
> Then, run
> emacs-29-vcs -Q --script /tmp/bug.el
> 
> Observed output: #("(message \"Foo\")" 9 14 (face font-lock-string-face))
> Expected: #("(message \"Foo\")" 0 9 (fontified t) 9 14 (face font-lock-string-face fontified t) 14 15 (fontified t))
> 
> The expected output appears in *Messages* when you run 
> emacs-29-vcs -Q -l /tmp/bug.el

You said font-lock-fontify-buffer, not font-lock-ensure...

Anyway, I hope Stefan will look into this.

> > If you create buffer, process text in it, then write it out and kill
> > the buffer, all in one go, there should be no reason to use a buffer
> > whose name begins with a space, because interactive users will not
> > have an opportunity to see such a buffer in the Emacs session.
> >
> > This problem is only real when a temporary buffer is left around
> > because, for example, it is being collected/processed asynchronously,
> > or in several stages with the user being able to interact with Emacs
> > in-between.
> 
> Killing the buffer where we do fontification is too slow for Org.
> If Org were to use temporary buffers, it would need to load major mode
> for every text fragment to be fontified. Loading major modes (at least
> some major modes) is taking significant amount of time and should
> better be avoided if we can simply reuse a single buffer with major mode
> that is already loaded.

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

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.




This bug report was last modified 2 years and 327 days ago.

Previous Next


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