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

Previous Next

Full log

View this message in rfc822 format

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Po Lu <luangruo <at> yahoo.com>
Cc: Gregory Heytings <gregory <at> heytings.org>, 63271 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, Juri Linkov <juri <at> linkov.net>
Subject: bug#63271: 29.0.90; broken mouse-face
Date: Wed, 10 May 2023 13:01:46 +0200

On Wed, 10 May 2023 18:53:34 +0800 Po Lu <luangruo <at> yahoo.com> wrote:

> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> On Tue, 09 May 2023 23:19:35 +0000 Gregory Heytings <gregory <at> heytings.org> wrote:
>>
>>>>> I finished bisection, and not sure if this helps, but that commit was
>>>>> 85a078e7853.
>>>>
>>>> Thanks, but I don't see how this could be true: those changes are all
>>>> conditioned by HAIKU-related conditionals, and I don't suppose you run a
>>>> Haiku build of Emacs, right?
>>>>
>>>
>>> Git bisect is always right.  I confirm that this bug is due to 85a078e785,
>>> which added, in ftcrfont_draw, a
>>>
>>> s->background_filled_p = 1;
>>>
>>> statement inside a #ifndef USE_BE_CAIRO (note the "n").  A few days later
>>> a1aa9cbf57 moved that statement ouside of the conditional.  Removing that
>>> statement fixes the bug.  I'm not sure what that statement is supposed to do
>>> however, it might be necessary, but only for Haiku.
>>
>> I confirm that after rebuilding emacs-29 with that line commented out,
>> the mouse-face highlighting problems no longer occur (here under Gtk3
>> with Cairo).
>>
>> Steve Berman
>
> Would you please answer my other question?  Namely, what is:
>
>   (gdb) p s->for_overlaps

I tried that using Eli's second experiment recipe (with breakpoint
xterm.c:8119) and after hitting the breakpoint and entering that
command, it returned this: $1 = 0

Steve Berman

Previous Next

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