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

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: yantar92 <at> posteo.net, eller.helmut <at> gmail.com, pipcet <at> protonmail.com, Gerd Möllmann <gerd.moellmann <at> gmail.com>, joaomoreira <at> gmx.se, 76538 <at> debbugs.gnu.org
Subject: 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 10:22:38 -0500

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

FWIW, my sorted-array-with-gap is kind of trying that, after making the
choice that the cache is eagerly updated during insertion/deletion.
But admittedly, we could keep the markers as they are and use the
sorted-array-with-gap only for the cache.  This way `save-excursion`
would remain as efficient as before.  At the cost of extra code,
of course.

Another attractive choice would be a cache that is flushed during
insertion/deletions (like the cache in `syntax-ppss`).  In that case it
can be a simple growable array with a constant lookup time since we just
look at `cache[POS / N]` where N is some arbitrary factor we choose
based on a tradeoff of size of the cache vs time to scan the bytes from
the cache's info to the actual POS.


        Stefan

Previous Next

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