GNU bug report logs - #79200
31.0.50; Duplicated elements for '#<marker at' in buffer-undo-list

Previous Next

Full log

View this message in rfc822 format

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Óscar Fuentes <oscarfv <at> eclipso.eu>
Cc: pipcet <at> protonmail.com, Helmut Eller <eller.helmut <at> gmail.com>, monnier <at> iro.umontreal.ca, Alan Mackenzie <acm <at> muc.de>, 79200 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: bug#79200: 31.0.50; Duplicated elements for '#<marker at' in buffer-undo-list
Date: Thu, 14 Aug 2025 19:52:48 +0200

Óscar Fuentes <oscarfv <at> eclipso.eu> writes:

> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
> * src/undo.c (truncate_undo_list): Use undo_group_limit.
> (syms_of_undo): Add DEFVAR_INT.
>
> [snip]
>
> Thank you for the detailed explanation. I'm running it now on one of the
> two machines that I use daily. 

Thanks!

> Apart from reporting obvious problems, do you want other info that
> requires inspecting buffer-undo-list or anything else from time to
> time?

Can't think of something specific at the moment. For me, a general
impression of how it is doing with the undo-group-limit would suffice.

> BTW, saying "No one would do 1000 undos" sounds very sensible. But on
> some circunstances I've seen how almost every character produced an undo
> boundary (time ago with Evil, now it seems better.) Also, some packages
> allow you to navigate the undo history on a way that is easy to restore
> the state of the buffer when its content's met certain criteria, like
> some text was added or removed, which could happened long time ago on
> the session. Having a limit of 200 (or 2000) undo steps may be
> constraining for the users of those packages. 

I guess you are thinking of vundo for example. I tried it once and it
was nice, but since I never used it after installation, I removed it
again. YMMV. And they could set the value to something higher. Don't
know if they require a lot of undos. For vundo, it seems it needed only
few because it displayed the states as graphical nodes and so on. And
there is only limited space for that. But I can't really say much about
that.

> Also, it would be interesting to see how much memory the average undo
> step consumes (without the pathological marker adjustment elements.)
> That way we could know if your change is significantly reducing the
> amount of undo info that Emacs traditionally stored.

Hm.

> While writing this e-mail the associated buffer-undo-list grew to 6000+
> elements, almost all of them marker adjustments. Executing igc-collect
> made no difference, but IIUC this is expected, the effects of your patch
> should begin after exceeding undo-group-limit. 

Right. The groups would be the nil list elements if I'm not mistaken.

> While writing English prose I make *lots* of corrections, maybe that's
> one of the main reasons why the problem affects me on a larger way.
>

Could be something like that. Or ispell maybe?

> Just before finishing this e-mail, buffer-undo-list went down to 3000+
> elements, almost all of them markers.

That sounds promising 👍

Previous Next

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