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 #182 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:44:46 +0300

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: larsi <at> gnus.org,  50660 <at> debbugs.gnu.org
> Date: Thu, 14 Oct 2021 20:27:34 +0800
> 
> > 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?
> 
> IIUC, the face that is actually used in a glyph string is the one
> returned by FACE_FOR_CHAR, which returns an adjusted face if the
> character passed to it is multibyte.

Correct.  (More accurately, not if the character is multibyte, but if
the character cannot be displayed by the font of the ASCII face.)

> What I'm asking is whether or not the adjustments made by FACE_FOR_CHAR
> are also made to the mouse face (which I think they are not, because
> there is only one mouse face at any given time

That's not true.  See this part of x_set_mouse_face_gc:

  /* What face has to be used last for the mouse face?  */
  face_id = MOUSE_HL_INFO (s->f)->mouse_face_face_id;
  face = FACE_FROM_ID_OR_NULL (s->f, face_id);
  if (face == NULL)
    face = FACE_FROM_ID (s->f, MOUSE_FACE_ID);

  if (s->first_glyph->type == CHAR_GLYPH)
    face_id = FACE_FOR_CHAR (s->f, face, s->first_glyph->u.ch, -1, Qnil);
  else
    face_id = FACE_FOR_CHAR (s->f, face, 0, -1, Qnil);
  s->face = FACE_FROM_ID (s->f, face_id);
  prepare_face_for_display (s->f, s->face);

IOW, we do call FACE_FOR_CHAR to create a mouse-face variant suitable
for non-ASCII characters.

> while the highlighted area can span many faces that could have been
> adjusted for many different characters).

If the original text includes characters that need different fonts,
then each run of characters that have the same font will produce a
separate glyph string.  A glyph string by definition has the same face
on all of its characters; when FACE_FOR_CHAR produces a new face
(because we found a character that needs a different font), we end the
glyph string and start a new one.  So such stretches of text will be
covered by several separate glyph strings with mouse-face, and each
one of them will have its own face from non-ASCII characters by virtue
of the above code.

Previous Next

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