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

View this message in rfc822 format

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

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

>> I'm reasonably sure.  Under the old code in *term, moving the mouse over
>> the entry for `glyphless-char' in list-faces-display results in nothing,
>> while under the new code (where s->font == s->face->font even under
>> mouse face) the section under mouse face overlaps with its surroundings
>> and is otherwise glitchy, because the mouse face's font is larger than
>> the original face's font.

> In the examples I used for testing the size of the font was the same,
> so I'm no longer sure we are talking about the same thing.

Yes, this has gone off on some kind of tangent.  We're discussing the
repercussions of a proposed method of moving the mouse face selection
into fill_XXX_glyph_string, instead of putting it in terminal specific
code.

> I also asked to describe what exactly you found that causes the
> artifacts I described when I installed the previous patch -- could you
> please provide that description?  Because I'm no longer sure I
> understand what is the problem with the existing code you are trying
> to fix now.

Okay.  The first issue, with the cursor put on the first character "s",
is caused by this snippet of xterm.c (in x_draw_glyph_string_foreground):

  /* If first glyph of S has a left box line, start drawing the text
     of S to the right of that box line.  */
  if (s->face->box != FACE_NO_BOX
      && s->first_glyph->left_box_line_p)
    x = s->x + max (s->face->box_vertical_line_width, 0);
  else
    x = s->x;

An identical snippet exists in w32term.

This happens because s->face is not the mouse face when s->hl is
DRAW_CURSOR and cursor_in_mouse_face_p, so it mistakenly assumes there
is a box for s (when there is in fact no box), and adds the original
face's vertical box width to x.

(Seeing this issue, you proposed to also move mouse face selection to
draw_glyphs, and I proposed to move it to fill_XXX_glyph_string, leading
to the above tangent about the semantics of s->font.)

The second issue was caused by testing for "start <=" end instead of
"start < end" in get_cursor_offset_for_mouse_face.

Thanks.

Previous Next

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