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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: Ihor Radchenko <yantar92 <at> posteo.net>, eller.helmut <at> gmail.com,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, 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: Sat, 01 Mar 2025 15:12:41 +0100

Pip Cet <pipcet <at> protonmail.com> writes:

>>> Which would be something like the attached. Can someone try this with
>>> the original recipe? (It's a quick sketch, and blah blah.)
>
> Performance seems slightly better, but not as good as disabling the
> bytepos<->charpos cache entirely and skipping the DO_MARKERS loop.
>
> OTOH, it's not worse!  And keeping the markers in an effectively
> doubly-linked list allows us to sort them whatever way we want.

That's good to hear, thanks for checking!

>> And I think I'll keep that. It makes an overall nicer implementation of
>> DO_MARKERS, keeps add and remove O(1), and provides iteration in
>> most-recently added order, which should be the same as without igc.
>
> I think we might want to sort markers at some point:  if we start out
> with the median marker, then the 25-percentile one, then the
> 75-percentile one, etc., we should arrive at an acceptable one fairly
> early without changing the scanning code at all!
>
> (In more detail, I think we should start with any marker, then choose
> the one with the greatest distance to all previously-chosen ones next,
> recursively.  I don't remember whether there's a particularly efficient
> algorithm to do that in the general case, but in the linear case, it's
> pretty simple, just build a btree and emit it in depth-first order.  Fun
> fact: do the same with a visual color metric and you get a usable color
> scheme!).

Or what Stefan or Eli said, I think, something independent of the buffer
markers. I'd like to see something like that.

>> I like it :-). Until something better comes along, of course.
>
> I still think I have "something better" in my head, but it's not so much
> in code form yet, and work on that is quite slow right now, for various
> reasons, so having a no-worse-than-master solution is important!
>
> So I'd be happy to see this merged!  If it improves performance to be
> acceptable, that's most likely sufficient, as far as this problem goes,
> for merging feature/igc (which I still believe in), even though the
> xdisp.c change (invisible.patch) I proposed (and analogous ones) should
> improve things a lot for magit even on master.

Ok, I'll add it then.

(And I'd like to have the other stuff for Magit :-)!)

Previous Next

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