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

Previous Next

Package: emacs;

Reported by: Óscar Fuentes <oscarfv <at> eclipso.eu>

Date: Fri, 8 Aug 2025 16:45:03 UTC

Severity: normal

Found in version 31.0.50

Full log


View this message in rfc822 format

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Helmut Eller <eller.helmut <at> gmail.com>
Cc: pipcet <at> protonmail.com, Óscar Fuentes <oscarfv <at> eclipso.eu>, 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: Tue, 12 Aug 2025 10:26:54 +0200
Helmut Eller <eller.helmut <at> gmail.com> writes:

> On Tue, Aug 12 2025, Gerd Möllmann wrote:
>
>> An alternative for igc, maybe, could be to make the markers in the
>> marker adjustment entries weak references. We'd need such weak
>> references, though, as Lisp objects. I have a vague memory that igc had
>> that at some point, does someone remember?
>
> For a time we had weak-ref Lisp objects.  I suppose putting such
> weak-refs in the undo list would still break some code.  Instead of
> weak-refs one could also use another layer of indirection, e.g. put a
> fixnum in the undo list and the fixnum is a key in a weak hashtable that
> holds markers weakly.

Yes. Or one could give markers a unique integer id, store that instead
of the marker itself in the marker adjustment entries. Then,
primitive-undo could iterate over the buffer's markers and only do
something for those markers it has an id entry for.

If that would work, we wouldn't need to employ weakness, which I think
might be a win. It's of course fiddly again. How to find all places
relying on the fact that markers are in the entries, with some
certainty?

What breakage are you thinking of?

> Even better would be if we could put positions instead of markers in the
> undo list.  After undoing, positions should be correct again; in an
> ideal world anyway.

After Stef reminded me: All markers in the deleted range get the same
position (ignoring details) after the deletion, so I think a position
alone wouldn't suffice. 




This bug report was last modified today.

Previous Next


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