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

Previous Next

Full log

View this message in rfc822 format

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: 79200 <at> debbugs.gnu.org, oscarfv <at> telefonica.net, monnier <at> iro.umontreal.ca, me <at> pengjiz.com
Subject: bug#79200: 31.0.50; Duplicated elements for '#<marker at' in buffer-undo-list
Date: Sat, 09 Aug 2025 15:18:39 +0200

Pip Cet <pipcet <at> protonmail.com> writes:

> Óscar Fuentes <oscarfv <at> telefonica.net> writes:
>
>> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>>
>>> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>>>
>>>> Makes sense: no idea what that is, but it's something with mode-lines,
>>>> and what Pip found out is also the mode-line department.
>>>
>>> And with Pip's patch applied, I can now longer reproduce the problem.
>>
>> Applied the patch to igc (adding the call to detach_marker.) It took a
>> while of monkeying around, but eventually...
>
> I'm afraid I must be monkeying around differently; I haven't found a way
> to produce similar undo lists with the patch applied on feature/igc.
>
> Our options here are either to find a recipe which results in what
> appears to be an undesirable undo list, or to run Emacs in rr and
> produce one in some way, then inspect the rr session to see where the
> undesirable markers were produced and whether there's a way to clean up
> when they're no longer in use.
>
>> (nil (363 . 364) nil (354 . 363) nil (353 . 354) nil (352 . 353) nil
>>      (351 . 352) nil (#("
>> "
>> 			0 1 (fontified t))
>> 		      . 351)
>>      (#<marker (moves after insertion) at 351 in *scratch*> . 1)
>>      (#<marker at 364 in *scratch*> . -1)
>>      (#<marker at 364 in *scratch*> . -1)
>>      (#<marker at 364 in *scratch*> . -1)
>>      (#<marker at 364 in *scratch*> . -1)
>>      (#<marker at 364 in *scratch*> . -1)
>>      (#<marker at 364 in *scratch*> . -1)
>>      (#<marker at 363 in *scratch*> . -1)
>>      (#<marker at 363 in *scratch*> . -1)
>
> That's 6 markers at position 364, then two at position 363.
>
> Note that it's not necessarily a bug for several markers to share a
> position; it is inefficient for too many of those to show up in an undo
> list, but I'm not sure it can always be avoided.
>
>>      (#<marker in no buffer> . -1) nil
>>      (#("n" 0 1 (fontified t)) . 352)
>>      (#<marker at 364 in *scratch*> . -1)
>>      (#<marker at 364 in *scratch*> . -1)
>>      (#<marker at 364 in *scratch*> . -1)
>>      (#<marker at 364 in *scratch*> . -1)
>>      (#<marker at 364 in *scratch*> . -1)
>>      (#<marker at 364 in *scratch*> . -1)
>>      (#<marker at 363 in *scratch*> . -1)
>> etc.
>>
>>
>> Bummer.
>>
>> Looks like the patch puts igc on the same footing as master wrt the
>> required work to reproduce the problem.
>>
>> As a side note, executing igc-collect removed some elements:
>
> It moved some markers to point nowhere (I'm not sure how, or whether it
> was igc-collect itself rather than unrelated code that ran, maybe
> because of auto-saving or a timer).
>
>> (nil (363 . 364) nil (354 . 363) nil (353 . 354) nil (352 . 353) nil
>>      (351 . 352) nil (#("
>> "
>> 			0 1 (fontified t))
>> 		      . 351)
>>      (#<marker (moves after insertion) at 351 in *scratch*> . 1)
>>      (#<marker at 364 in *scratch*> . -1)
>>      (#<marker at 364 in *scratch*> . -1)
>>      (#<marker at 364 in *scratch*> . -1)
>>      (#<marker at 364 in *scratch*> . -1)
>>      (#<marker at 364 in *scratch*> . -1)
>>      (#<marker at 364 in *scratch*> . -1)
>>      (#<marker in no buffer> . -1) (#<marker in no buffer> . -1)
>>      (#<marker in no buffer> . -1) nil
>>      (#("n" 0 1 (fontified t)) . 352)
>> etc.
>>
>> Note that on my first copy&paste of buffer-undo-list the first sequence
>> of repeated elements was 8, but above it shows 6. The other repeated
>> sequences show a similar change.
>
> I don't see a run of 8 markers at the same position.
>
> Pip

Another thought: the format_mode_line_unwind is only called from
display_mode_line (redisplay) and format-mode-line. Why does soemthing
land in the undo list at all? DOes that make sense at all?

Previous Next

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