| 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!
|