Subject: bug#79200: 31.0.50; Duplicated elements for '#<marker at' in buffer-undo-list

From: Gerd Möllmann <[email-masked]>
Date: Sun, 10 Aug 2025 15:11:24 +0200

Alan Mackenzie <[email-masked]> 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.