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 #92 received at 76538 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> protonmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: yantar92 <at> posteo.net, eller.helmut <at> gmail.com,
 Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 monnier <at> iro.umontreal.ca, joaomoreira <at> gmx.se, 76538 <at> debbugs.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: Fri, 28 Feb 2025 16:07:18 +0000

[Message part 1 (text/plain, inline)]

On Friday, February 28th, 2025 at 08:19, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Gerd Möllmann gerd.moellmann <at> gmail.com
> 
> > Cc: Ihor Radchenko yantar92 <at> posteo.net, Eli Zaretskii eliz <at> gnu.org,
> > eller.helmut <at> gmail.com, pipcet <at> protonmail.com, joaomoreira <at> gmx.se,
> > 76538 <at> debbugs.gnu.org
> > Date: Fri, 28 Feb 2025 06:19:34 +0100
> > 
> > Gerd Möllmann gerd.moellmann <at> gmail.com writes:
> > 
> > > In any case, I think I would try to change DO_MARKERS to start at the
> > > end of the marker vector. If fix_marker_vector runs often enough one
> > > could also "straighten" the free-list there, maybe.
> > 
> > Or one could build a doubly-linked list of markers in most-recently
> > created order. But that would mean 3 array slots per marker in the
> > marker vector. Don't know.
> 
> How about not relying on buffer markers too much for this job? And in
> particular, not adding any ephemeral markers when we don't find a
> close-enough existing marker? We could instead build our own data
> structure, and make it so we could use efficient search methods.

I can't really contribute much to the general discussion, but, if I understand correctly, in this specific case the problem is that magit causes redisplay to skip over a large invisible region, finding each newline in it, calculating its charpos, then advancing to the next one because the newline is invisible.

So I've tried applying the attached patch, and that seems to avoid the specific problem here: we simply skip to the beginning of the invisible region, which means only one charpos<->bytepos lookup for the entire region, and it doesn't matter too much that it's a slow one.

Of course there are still problems caused by the heuristic nature of the charpos<->bytepos caching mechanism, which simply doesn't have very good worst-time complexity, but I think the right solution there is to continue working on storing buffer text in a number of chunks (and saving the correct bytepos/charpos change for each chunk).  I have some code for that and I'd rather continue working on it for a while before giving up and spending time on different implementations of the marker array.  That would give us predictable and acceptable worst-case performance, I think, and we wouldn't need to go out hunting for use cases that come close to the worst case.

Pip

[invisible.patch (text/x-patch, attachment)]

Previous Next

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