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 wrote: > >> Cc: 70637@debbugs.gnu.org >> Date: Mon, 29 Apr 2024 18:34:40 +0300 >> From: Eli Zaretskii >> >>> From: JD Smith >>> 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!