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

Package: emacs;

Reported by: Po Lu <luangruo <at> yahoo.com>

Date: Sat, 18 Sep 2021 12:24:01 UTC

Severity: normal

Found in version 28.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #170 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:10:35 +0300
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: larsi <at> gnus.org,  50660 <at> debbugs.gnu.org
> Date: Thu, 14 Oct 2021 19:54:38 +0800
> 
> Eli Zaretskii <eliz <at> 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?




This bug report was last modified 3 years and 275 days ago.

Previous Next


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