bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being uncondi


From: Eli Zaretskii
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@gmail.com>
> Cc: monnier@iro.umontreal.ca,  56637@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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]