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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@gmail.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  56637@debbugs.gnu.org
> Date: Wed, 20 Jul 2022 12:13:14 +0800
> 
> 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.

We don't necessarily need to solve future problems.  Let's leave
something for those who will come after us.

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

> 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

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.

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

Once again, if the buffer is killed before the user can see it,
there's no problem to use a name which doesn't start with a space.

But let me turn the table and ask you: how have you been doing this
till now?