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

[Ihor Radchenko <yantar92@gmail.com>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> When font-lock-mode is active, char-property-alias-alist contains
>> '(face font-lock-face).
>
> Yes, I know, but it would really help to see a concrete case where that
> makes a difference, because there are various ways to "fix" this
> problem.  They all have upsides and downsides.

In my case, the main difference is in org-src-font-lock-fontify-block.
Its purpose is copying the text fontification from major mode buffer to
Org mode buffer. The copying is done by checking 'face and
font-lock-extra-managed-props properties, which is sufficient as long as
font-lock-mode is activated. When font-lock-mode is not activated,
copying 'face is not enough, and we have to copy 'font-lock-face.

>> Unless we can forever rely on the implementation detail that
>> 'font-lock-face is always equivalent to the 'face property,
> It's not really "equivalent", but more importantly it's not an
> implementation detail: it's documented in the ELisp manual.

Apart from 'font-lock-face, which can be copied explicitly, I do not see
any real issues.

Maybe only htmlize, which explicitly checks the value of font-lock-mode
variable and does something strange if it is nil.

Of course, htmlize is an external package. However, potentially, places
that check font-lock-mode value and can be used noninteractively may be
problematic:

1. align-rules-list
2. faces--attribute-at-point
3. font-lock-flush (it will fail to work when font-lock-mode is nil)
4. Info-fontify-node
5. c-toggle-comment-style
6. c-fontify-new-found-type
7. c-change-expand-fl-region
8. grep-process-setup
9. sh-set-shell
10. verilog-preprocess
11. reftex-show-entry

Best,
Ihor