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

[StrawberryTea]

I finally figured it out. This can be resolved with a small Elisp advice:

(advice-add #’org-fold-core-region :around #’cae-org-fold-region-a)
(defun cae-org-fold-region-a (oldfun from to flag &optional spec-or-alias)
  (if (and (eq to (point-max)) flag)
      (setq to (1- to)))
  (funcall oldfun from to flag spec-or-alias)
  (remove-overlays from (1+ to) ’cae-org-fold-heading t)
  (when flag
    (let ((o (make-overlay to (1+ to) nil ’front-advance)))
      (overlay-put o ’evaporate t)
      (overlay-put o ’cae-org-fold-heading t)
      (overlay-put o ’face
                   (save-excursion (goto-char from)
                                   (face-at-point)))
      (overlay-put o ’display “\n”))))

I modeled the code after the Backline package which does the same thing for
Outline, which uses overlays. I’m thinking now that we should not patch the
display engine.

Eli Zaretskii <eliz@gnu.org> writes:

>> From: StrawberryTea <look@strawberrytea.xyz>
>> Cc: yantar92@posteo.net, 65896@debbugs.gnu.org, kevin.legouguec@gmail.com
>> Date: Sat, 23 Sep 2023 14:05:53 -0500
>>
>> What I’m saying is that, I start up GDB and I set a breakpoint on Frecenter 
>> and
>> step into display_line, I can see the glyph row and how all the characters in
>> the folded heading have the heading except the newline character at the end. 
>> And
>> I would like for in this specific scenario, the face on the ellipsis to be 
>> used
>> (since it has extend) instead of the face on the newline which is the default
>> face. But I don’t know how to make that modification to the code yet.
>
> How will this behavior be limited to the case of folded text?  Because
> when the text between the ellipsis and the newline is not invisible,
> the face of the newline should still be used, otherwise we will have
> an unacceptable change in behavior in the “normal” cases, when there’s
> no invisible folded text.