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 #53 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:53:03 -0500

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

Maybe we can confirm this behavior:

- in the `buf_*pos_to_*pos` code, in the `DO_MARKERS` loop, we can keep
  track of the range of indices of the markers we consult.
- then when we exit unsuccessfully and create a new cache-marker, we can
  compare the index of that cache-marker with the indices we consulted.

If the index is not within the range of indices we consulted, then this
cache-marker is most likely going to be useless (because, if nothing
else is changed, next time we need to convert at this position we simply
won't find it).


        Stefan

Previous Next

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