bug#65896: 30.0.50; folding text with text properties prevents background from extending past the newline

[LemonBreezes]

This might not sound too clever, but why don't we just make the extend

property be determined by the first character in the line rather than

the last character / newline character? 

On Tue, Sep 12, 2023, at 3:51 PM, Kévin Le Gouguec wrote:

Eli Zaretskii <eliz@gnu.org> writes:

> tags 65896 wishlist

> thanks

This seems related to bug#52587, maybe so much so that it might make

sense to merge them?  IIUC, given this Org buffer…

--8<---------------cut here---------------start------------->8---

* foo

#+begin_stuff

bar

#+end_stuff

* baz

--8<---------------cut here---------------end--------------->8---

… and folding "* foo",

* bug#52587 is about "#+end_stuff"'s :extended background "bleeding

  into" the header line,

* bug#65896 (this report) is about the header line's :extended

  background getting "cut short" once folded.

AFAIU those are two aspects of the same problem people have with

outlines: the effective :extended background comes from the last line of

the folded content (because that's the newline that is actually

displayed) whereas one might expect it to come from the header line (but

it can't, because the header line's newline is invisible).

So I'd expect addressing one report will also address the other.

>> From: StrawberryTea <look@strawberrytea.xyz>

>> Date: Tue, 12 Sep 2023 13:00:45 -0500

>> 

>> 

>> Hi. This issue comes from Reddit,

>> https://www.reddit.com/r/emacs/comments/v0i4js/extend_org_heading_background_face_past_the/.

>> Basically, if I fold text using text properties, the heading background

>> does not extend to the end of the window. To quote /u/yantar92: "This is

>> because the trailing newline in the folded heading gets hidden. If the

>> trailing newline is invisible, :extend t has no effect. It is Emacs

>> limitation, AFAIK." It would be great if we could make the :extend

>> property work with invisible text.

>

> It cannot.  Text properties of invisible text are ignored because the

> display engine skips invisible text and doesn't consider it and its

> properties at all.

>

> I'm not closing this bug in the hope that someone will have a clever

> idea for how to work around this, or maybe (gasp!) even submits a

> patch.