bug#42184: 27.0.91; org-fontify-whole-heading-line does not work in emacs 27

["Kévin Le Gouguec" <kevin.legouguec@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
>> Cc: egh@e6h.org,  42184@debbugs.gnu.org,  Nicolas Goaziou
>>  <mail@nicolasgoaziou.fr>,  Bastien <bzg@gnu.org>
>> Date: Sat, 04 Jul 2020 21:52:08 +0200
>> 
>> To make the discussion more concrete: here's a suggested patch for Org
>> against the emacs-27 branch; what say you?
>
> I don't understand why you extend all those faces: the original report
> was about a much smaller set.  It is not the intent that every face
> that happens to span the entire line be extended: that's why we made
> ':extend' by default be off for a face.
>
> What am I missing?

The original report was about the org-level-1 and org-level-2 faces, as
well as org-block-begin-line and the org-block-end-line.

The only faces I added were org-level-[3-8], because I don't see why
different heading levels should not work with
org-fontify-whole-heading-line.

AFAICT, this is the simplest way to fix org-fontify-whole-heading-line
and org-fontify-whole-block-delimiter-line for Emacs ≥27.  These user
options work under the assumption that simply fontifying the final
newline is enough to extend attributes past EOL.


The long term fix might be for Org to (1) deprecate these user options
and let themes and/or users apply :extend t themselves, or (2) slap
:extend t onto the faces when setting up the major mode fontification
depending on these user options (Org already does similar on-the-fly
face tweaks; see e.g. org-hide).  Or something else.

It seems to me that this kind of change would be somewhat more involved
and breakage-prone, but if Org maintainers think this is the way forward
for emacs-27, I wouldn't mind.