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

Previous Next

Full log

Message #176 received at 50660 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: larsi <at> gnus.org, 50660 <at> debbugs.gnu.org
Subject: Re: bug#50660: 28.0.50; Text artifacting when the cursor moves over
 text under mouse face that originally displayed a box
Date: Thu, 14 Oct 2021 15:20:04 +0300

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: larsi <at> gnus.org,  50660 <at> debbugs.gnu.org
> Date: Thu, 14 Oct 2021 20:16:23 +0800
> 
> Eli Zaretskii <eliz <at> 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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.