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: Juri Linkov <juri <at> linkov.net>
Cc: luangruo <at> yahoo.com, Eli Zaretskii <eliz <at> gnu.org>, 63271 <at> debbugs.gnu.org
Subject: bug#63271: 29.0.90; broken mouse-face
Date: Mon, 08 May 2023 22:46:49 +0200

On Mon, 08 May 2023 22:09:16 +0300 Juri Linkov <juri <at> linkov.net> wrote:

>>> mouse-face specifies only the background color, so I'm at a loss how
>>> could a font affect that.  There's something I'm missing here.  Like
>>> some corruption of the realized faces or something.
>>>
>>> Do you see the same in Emacs 28 and 27?  If some older version doesn't
>>> show this, any chance of bisecting it?
>>
>> I cannot reproduce the problematic display in Emacs 28.  I'll see if I
>> can bisect, but it may take a while.
>
> I tried to bisect and see the problem in
>
> 61b9f2c3179..: 2022-11-17 * lisp/emacs-lisp/shortdoc.el (sequence): Don't use
> cl-lib (bug#59319)
>
> but not in
>
> 0636e1066bb..: 2022-11-16 ; Don't unnecessarily use non-ASCII characters in Texinfo

I checked out those commits and rebuilt emacs and can confirm that the
build from 61b9f2c3179 has the problem and the build from 0636e1066bb
does not.

> probably because 61b9f2c3179 is the last commit of a big merge at that time.

If I'm not misreading the vc-change-log, it looks like that commit is
from Stefan's merge of the noverlay branch, and it seems not implausible
that some change in that branch is the source of the problem.  (But my
git skills are elementary, so I may well be misreading it.)  Is it
possible to confine bisection to the commits from a merge, and if so,
how?

Steve Berman

Previous Next

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