GNU bug report logs -
#79200
31.0.50; Duplicated elements for '#<marker at' in buffer-undo-list
Previous Next
Full log
Message #164 received at 79200 <at> debbugs.gnu.org (full text, mbox):
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> Alan Mackenzie <acm <at> muc.de> 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
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.