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 20:16:23 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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?
> 
> OK, I think I understand what you mean now.  But is it really correct to
> put that in draw_glyphs, and not say, fill_XXX_glyph_string?

If this affects the glyph string, then fill_XXX_glyph_string is a
better place, yes.

> And even then, what about cases where a non-ASCII face is used?
> Does the mouse face in the Mouse_HLInfo take that into account?

I'm not sure what issue you have in mind.  Why should it matter if the
glyph string's face is ASCII or non-ASCII?  Do you see any problems
related to the box face that happen when text is ASCII, but not when
it's non-ASCII, or vice versa?