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


Message #176 received at 79200 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: Óscar Fuentes <oscarfv <at> eclipso.eu>,
 Pip Cet <pipcet <at> protonmail.com>, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 79200 <at> debbugs.gnu.org
Subject: Re: bug#79200: 31.0.50; Duplicated elements for '#<marker at' in
 buffer-undo-list
Date: Sun, 10 Aug 2025 15:11:24 +0200
Alan Mackenzie <acm <at> muc.de> writes:

>> > I think it may make more sense to find out who goes around creating
>> > markers and not cleaning up after them. But I suspect many places cannot
>> > easily be fixed because the markers might be exposed to Lisp.
>
>> Probably. Good question is how to find these places, especially when
>> they are created in Lisp :-/.
>
> I've made a start on this (see patch below).  It's mainly in the C files,
> where I grepped for Fpoint_marker and Fcopy_marker, and tidied up the
> uses which didn't tidy up their uses of markers.  But also in some Lisp
> files, which are directly part of the command loop (simple.el), or called
> from it in hooks (jit.el, electric.el).

Hi Alan,

Thanks.

> Unfortunately, this hasn't helped much.  When I type "asdfasdf" into
> *scratch* on emacs -Q, then <BACKSPACE>, I still see five point markers
> in buffer-undo-list.  If I <BACKSPACE> a second time, this adds on a
> further ten point markers to b-u-list.
>
> It's worth mentioning that these markers aren't eq to eachother.  At
> least, not all of them.  I have a strong suspicion that there are
> duplicates in the 15 markers in buffer-undo-list after my two
> deletions.

Hm, you mean eq markers inside the same undo group has duplicates? That
I haven't seen yet. There is code in primitive-undo for that case,
though, so it seems to be expected in some case. No idea.

If the same marker appears twice in different undo groups, then that's
normal. The entries for markers mean something like "add some delta to
the marker's position when we undo this record".

> It is unclear whether the <BACKSPACE> creates these markers, or just puts
> existing markers into buffer-undo-list.  Maybe we could do with a
> primitive in marker.c which would print out the current buffer's list of
> markers.

I don't believe it creates the markers. But I'm pretty sure that
record_change can put a lot of markers to a buffer's undo list. It just
considers all markers in a buffer's markers list as relevant for undo.
IOW, when we undo, all these markers need their positions changed. It
has no way to recognize markers that are only used temporarily. 

...

> This might be a silly question, but why do we have to put markers into
> buffer-undo-list at all?  Surely they should "fix themselves" as other
> changes in the buffer get undone?

Please see above. I hope that explains it. 




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.