bug#63271: 29.0.90; broken mouse-face

[Stephen Berman]

On Tue, 09 May 2023 16:32:07 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: juri@linkov.net,  luangruo@yahoo.com,  63271@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.

In both fundamental-mode and lisp-interaction-mode the above command
returned the same value at every break: 0xffb4eeb4 (i.e, $1 =
0xffb4eeb4, $2 = 0xffb4eeb4, etc.).

> 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.

Yes, it looks like a font plus backend 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.

Ok, thanks.

BTW, in the screen shot of fundamental-mode I neglected to note that
"TODO" appears to be in bold-face when the mouse pointer moves over it,
and outside of gdb, when I move the mouse pointer over "TODO" and then
away, I can clearly see the thickness of the characters change (but I
cannot verify this with `C-u C-x =', which says "ftcrhb:-PfEd-DejaVu
Sans-regular-normal-normal-*-19-*-*-*-*-0-iso10646-1 (#x37)" both when
the mouse pointer is over the string and when it isn't).

BTW2: In checking the above, I unintentionaly but fortuitously created
the the same image the Juri posted, where "TODO" has a black background,
"ODO" is not visible, and "T" has same foreground color as
mouse-highlight.  I did this by keeping the mouse pointer over "T" and
moving the cursor (i.e. point) leftwards from the end of the string: as
point moves over each character, its foreground appears in
mouse-highlight and on moving point to the next character to the left,
the black cursor block remains on the character it just moved off of,
leaving the character invisible.

Steve Berman