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

[Ihor Radchenko <yantar92@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> It would be nice if we could somehow enable font-lock inside " *hidden*"
>> buffers. Would it be possible?
>
> Depends on the "somehow" part.  I generally prefer that obscure corner
> cases be solved in the software which creates those obscure cases.  In
> this case, it seems like web-mode is that place?  I'm not sure why
> you say Org should solve this, but perhaps I didn't understand the
> description well enough.  But if this indeed needs to be solved in
> Org, how about not using buffers whose names begin with a space?

While this particular case might be solved on web-mode side (I guess
that directly setting 'font-lock-face property is not recommended?), I
am more concerned about similar issues that might popup in future.

Is it always guaranteed by Emacs that font-lock-fontify-buffer correctly
fontifies that buffer even when font-lock-mode is disabled? If not, Org
has to make sure that font-lock-mode can be enabled when we need to
compute fontification programmatically.

The need to compute fontification is not limited to the described Reddit
report. Org also needs fontification for export purposes - we copy the
Emacs code colours into exported documents. With current behaviour of
font-lock-mode, programmatic fontification may be problematic not only
when we use "hidden" buffers starting with space, but also in
non-interactive mode as in recent related bug report
https://orgmode.org/list/wxaUFiqi8BmIPv8pcYRVHAFa0hTzM35roQxpVVRkgddjRkesPGX1kVBL3G0fr42FonlRq5FNjapV8RiovXV-RGEDehXn-cmIebf4HWBhzIQ=@protonmail.com

As for not using buffers with names starting with a space, we do need
such buffers as means to fontify foreign major mode blocks inside Org.
How else do you suggest computing fontification of an arbitrary text in
arbitrary major-mode (not org-mode) without polluting the buffer list?

Best,
Ihor