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

[Eli Zaretskii <eliz@gnu.org>]

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