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

Previous Next

Full log

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

From: Pip Cet <pipcet <at> protonmail.com>
To: Óscar Fuentes <oscarfv <at> telefonica.net>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 79200 <at> debbugs.gnu.org, Pip Cet via <bug-gnu-emacs <at> gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, Pengji Zhang <me <at> pengjiz.com>
Subject: Re: bug#79200: 31.0.50;
 Duplicated elements for '#<marker at' in buffer-undo-list
Date: Sat, 09 Aug 2025 12:29:02 +0000

Ó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

Previous Next

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