GNU bug report logs - #63271
29.0.90; broken mouse-face

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: luangruo <at> yahoo.com, 63271 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#63271: 29.0.90; broken mouse-face
Date: Tue, 09 May 2023 16:32:07 +0300

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: juri <at> linkov.net,  luangruo <at> yahoo.com,  63271 <at> debbugs.gnu.org
> Date: Tue, 09 May 2023 14:43:02 +0200
> 
> > What do you see on the screen in this case?  Please describe the
> > visual appearance of each character in the case of fundamental-mode,
> > and perhaps also show a screenshot of the window as it is displayed
> > when the mouse-highlight becomes visible during this scenario.
> 
> Here's a screenshot of lisp-interaction-mode when the mouse-highlight
> appears:

Thanks.  This is strange.  Can you try one more thing, please?  With
the same breakpoint in xterm.c, when the breakpoint breaks, please
type

  (gdb) print/x s->face->background

Please do this every time the breakpoint breaks, and let's see if
Emacs thinks both the "TODO" text and the blank after it should be
displayed with the same background color (which should be the
background of the 'highlight' face).  That's what I see on my system.

If the colors of the two glyph_string's indeed match, I'm led to
believe that the problem is elsewhere, in the low levels of drawing
the stuff on screen.  Perhaps some library (Cairo?) has a bug or
something.  Because the data structures prepared by the Emacs display
engine are correct, and explicitly specify the mouse-highlight
background to be drawn.  So somehow using this particular font erases
the background, or something to that effect.  This is also consistent
with the fact that other font backends don't show the problem.

Po Lu, any ideas how to look into this further?

> Aside from the difference in highlighting, another difference I failed
> to notice before is that in fundamental-mode the string "TODO" is
> displayed with DejaVu Sans but in lisp-interaction-mode with DejaVu Sans
> Mono, although I used the same Lisp code with the face property
> (:inherit variable-pitch) to enter the string in both buffers.  I guess
> lisp-interaction-mode inhibits variable-pitch face and that's the reason
> the mouse-highlighting appears on the problematic characters in that
> mode, in contrast to fundamental-mode.

This is actually easy to understand, and is expected:
lisp-interaction-mode has font-lock-mode turned on, and thus the
recipe you evaluate doesn't change the face (thus the font), only adds
mouse-highlight.

Previous Next

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