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: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: pipcet <at> protonmail.com, eller.helmut <at> gmail.com, yantar92 <at> posteo.net, monnier <at> iro.umontreal.ca, 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:19:56 +0200

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

Previous Next

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