GNU bug report logs - #76538
31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs.

Previous Next

Full log

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: Ihor Radchenko <yantar92 <at> posteo.net>, eller.helmut <at> gmail.com,
 Gerd Möllmann
 <gerd.moellmann <at> gmail.com>, joaomoreira <at> gmx.se, 76538 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using
 magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some
 random ways blocks GNU Emacs.
Date: Wed, 26 Feb 2025 17:40:26 -0500

>> BTW, now that I look at the code, maybe the problem you're bumping into
>> is that on the igc branch, (cache-)markers are added to the rear of the
>> array (as a first approximation), whereas on `master` they're added to
>> the front of the linked list.
>>
>> In `buf_charpos_to_bytepos` we scan the array/list starting from
>> the front, so once the array gets large we never reach the end of the
>> array where we would find the recently-created nearby cache-marker, so
>> instead of using that nearby (cache-)marker we end up creating a new one
>> and paying (again) for a costly long scan.
>
> That seems to match what's happening here, with the order of scanning to
> blame, but...
>
>> Maybe if we change the `DO_MARKERS` iteration to scan from the end,
>> we'd recover a behavior much closer to what we see on `master`.
>
> ...I tried doing that, and it didn't work.  Maybe I messed up somehow.

Hmm... yeah, maybe you messed up somehow, or maybe it's because of the
"as a first approximation":

Gerd's array of markers keeps a free-list so new markers are not really
always added to the end, but rather they're added "randomly" in the
reverse order where markers were removed from the buffer (until reaching
the end of this, at which point it's added to the end of the array).
If there are enough markers in the array, anywhere that's not very-near
the rear (or the front, depending on the order in which we scan) will
simply never be consulted during char<->byte conversion.  🙁


        Stefan

Previous Next

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