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

Previous Next

Full log

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

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

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

Actually, 0636e1066bb was one of the latest commits on emacs-28.
So we need to continue bisecting on emacs-29 down from the commit
be42fdc6dc6..: 2022-04-13 where the test case still fails.
This is one of the last commits before huge merges,
so the history below from it is quite flat and shallow,
and thus easier to bisect.

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

The git history is a mess, it's really hard to read vc-change-log
interspersed with very deep merges.

Previous Next

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