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

From: Pip Cet <[email-masked]>
Date: Sat, 09 Aug 2025 18:30:37 +0000

Gerd Möllmann <[email-masked]> writes:

> Alan Mackenzie <[email-masked]> writes:
>
>> Hello, everybody.
>
> Hallo Alan!
>
>> I have an equally simple recipe, which suggests undo is not the culprit.
>> Note step 3.
>>
>> 1. emacs -Q
>> 2. Type asdf.
>> 3. M-: buffer-undo-list.  This gives:
>>
>>     (nil (148 . 152) (t . 0) nil (1 . 148) (t . 0))
>>
>> 4. Type <backspace>.
>> 5. M-: buffer-undo-list.  This gives:
>>
>>     (nil (#("f" 0 1 (fontified t)) . -151) (#<marker at 151 in *scratch*>
>>     . -1) (#<marker at 151 in *scratch*> . -1) (#<marker at 151 in
>>     *scratch*> . -1) (#<marker at 151 in *scratch*> . -1) (#<marker at
>>     151 in *scratch*> . -1) (#<marker at 15\1 in *scratch*> . -1)
>>     (#<marker at 151 in *scratch*> . -1) (#<marker at 151 in *scratch*> .
>>     -1) (#<marker at 151 in *scratch*> . -1) 152 ...)
>>
>>   [ That enforced dumning down of the output by truncation is most
>>   annoying.  I haven't found a way to get a complete output. ]
>
> (I think M-: (pp buffer-undo-list) would do the trick for the
> truncated output.)
>
>
>>
>> Unlike other people here, I see this in the emacs-30 branch, too.
>
> Yes, make sense. After Eli's hint, I found this incoming call tree:
>
> - record_marker_adjustments undo.c:127
>   - record_delete record_delete:187
>     + casify_region casify_region:555
>     + adjust_after_replace adjust_after_replace:1408
>     + replace_range replace_range:1639
>     + del_range_2 del_range_2:2030
>     + record_change record_change:201
>
> where record_marker_adjustments puts basically all present markers in a
> buffer's undo list. del_range_2 I would interpret that any text deletion
> might do that.

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.

> I think a garbage-collect with the old GC will clean up the undo list
> eventually by calling compact_undo_list. With MPS, that doesn't work.
> The cleanup in compact_undo_list cannot be used because MPS's weak
> objects and GC work completely differently.

That's my understanding, too. And it means that this probably isn't
horribly important to fix on the master branch. On feature/igc, it looks
like something has to be done.

> At the moment I'm a bit out of ideas. Waiting for a divine inspiration,
> so to speak.

Maybe some markers could be marked at creation time as not being
important enough to be recorded in the undo list? I'm not really sure
which markers are being recorded and which need to be for undo to work.

Pip