bug#50660: 28.0.50; Text artifacting when the cursor moves over text under mouse face that originally displayed a box

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: larsi@gnus.org,  50660@debbugs.gnu.org
> Date: Thu, 14 Oct 2021 19:54:38 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> @@ -1799,11 +1799,24 @@ x_draw_glyph_string_foreground (struct 
> >> glyph_string *s)
> >>  {
> >>    int i, x;
> >>  
> >> +  struct face *face_for_box_line = s->face;
> >> +
> >> +  if (s->hl == DRAW_CURSOR && cursor_in_mouse_face_p (s->w))
> >> +    {
> >> +      /* In this situation, the cursor is in the mouse face, but
> >> +   s->face hasn't been updated with the mouse face yet. */
> >> +      face_for_box_line =
> >> +  FACE_FROM_ID_OR_NULL (s->f, MOUSE_HL_INFO (s->f)->mouse_face_face_id);
> >> +
> >> +      if (!face_for_box_line)
> >> +  face_for_box_line = FACE_FROM_ID (s->f, MOUSE_FACE_ID);
> >> +    }
> 
> > Can't we "fix" this face in xdisp.c, before calling the
> > terminal-specific backend?  The bonus will be that we then do it only
> > in one place.
> 
> The only way to do that I can think of would be to offset the glyph
> string's x position (but not the phys cursor) by the vertical box line
> width, and I think it would be an ugly thing to do, because that would
> imply lying to the window system backend.

We may be miscommunicating.  My point is that the conditions on which
you base the face selection are known in draw_glyphs, so why delay
that to when xterm.c is called to actually draw the glyph string?  Why
not test this same condition in draw_glyphs (or some other suitable
place in xdisp.c) and fix the glyph string's face accordingly?  Am I
missing something?