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

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

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

Either way. They should both fontify the buffer with font-lock-ensure
not skipping any parts guaranteed.

In any case, changing font-lock-ensure to font-lock-fontify-buffer will
not change failure to fontify using the report steps.

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

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.

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

To illustrate, try to create a buffer and run the following:

(progn (emacs-lisp-mode) (benchmark-run 100 (erase-buffer) (insert "(+ 1 2)") 
(font-lock-ensure)))

(benchmark-run 100 (erase-buffer) (insert "(+ 1 2)") (emacs-lisp-mode) 
(font-lock-ensure) (fundamental-mode))

The results are:

(5.531764251 0 0.0)
(0.012424528 0 0.0)

Over 400x difference.

Best,
Ihor