bug#70637: :box vertical bar artifacts at 'display boundaries

[JD Smith <jdtsmith@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2456 bytes --]

I presume this is a more general issue than just :box.  One idea is to add a warning to the Elisp section "Display Specs That Replace The Text", perhaps at the end:

Note: certain `face' attributes such as `:box' can lead to display artifacts when applied to the replacing text in a `display' specification.  These attributes may be incorrectly merged with adjacent non-`display' `face' properties.  This can be mitigated by applying the `face' attributes directly to the text being replaced, rather than (or in addition to) the `display' replacement text itself.

Maybe a bit too wordy.

> On May 9, 2024, at 3:36 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> Cc: 70637@debbugs.gnu.org
>> Date: Mon, 29 Apr 2024 18:34:40 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> 
>>> From: JD Smith <jdtsmith@gmail.com>
>>> Date: Mon, 29 Apr 2024 11:19:52 -0400
>>> Cc: 70637@debbugs.gnu.org
>>> 
>>> This happens when the glyph under cursor has the beginning-of-box or
>>> end-of-box flag set.  When we display the entire stretch of characters
>>> on that line, we (correctly) don't pay attention to these flags in the
>>> middle of the glyph sequence, but redrawing the cursor draws just one
>>> glyph, and knows nothing about those before or after it.  So it draws
>>> the unnecessary border, because the glyph under cursor has the flag
>>> set.
>>> 
>>> Those box flags are set on the glyphs produced from the display
>>> strings because when we process the beginning or end of the string, we
>>> don't have any idea whether the characters of the underlying buffer
>>> text before/after the string have the same value of the :box face, so
>>> we cannot avoid setting these flags at the first and the last
>>> character of the display string.
>>> 
>>> 
>>> I see, makes sense.  So the cursor blink code would also have to "look ahead/behind" the underlying glyph to
>>> know whether to ignore the flag.
>> 
>> It's not just to "look", it's actually to redraw.  because the logic
>> which determines whether we draw the borders lives in the code that
>> draws the glyphs on the glass, and to DTRT it needs to be presented
>> with a sequence of glyphs that begins before the one under cursor and
>> ends after it.
>> 
>>> Probably this is such a rare case that unless there are other related
>>> artifacts, it's worth documenting but not fixing.
>> 
>> Suggestions for how to document this are welcome.
> 
> Ping!


[-- Attachment #2: Type: text/html, Size: 3091 bytes --]