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

From: Alan Mackenzie <[email-masked]>
Date: Wed, 13 Aug 2025 08:19:36 +0000

Hello, Gerd.

On Wed, Aug 13, 2025 at 08:39:11 +0200, Gerd Möllmann wrote:
> Gerd Möllmann <[email-masked]> writes:

> > Helmut Eller <[email-masked]> writes:

> >> On Tue, Aug 12 2025, Gerd Möllmann wrote:

> >>> Like so, I think:

> >> I think the DEFVAR_INT is not needed. Something like this:

> >> static ptrdiff_t next_marker_id;

> >> static ptrdiff_t
> >> next_marker_id (void)
> >> {
> >>   return next_marker_id++;
> >> }

> >> and in syms_of_alloc

> >>   PDUMPER_REMEMBER_SCALAR(next_marker_id);

> >> should also work.

> > That's true.

> > I've made it a DEFVAR mainly because I wanted to be able to see it
> > easily :-).

> > Don't know if the wrap-around check in next_marker_id is really
> > necessary; that's just paranoia, I guess, or maybe laziness, not wanting
> > to calculate :-).

> BTW, C-h v next--marker-id and 'g' to refresh is somwwhat interesting.
> In my mac GUI session each 'g' shows 472 markers have been made.
> Whatever that means.

That sounds a lot, but ....  many of these markers will have a short
lifetime, being rapidly terminated with (set-marker foo nil) or the like.

What matters more is surely the number of markers which persist and can
get into buffer-undo-list.  In your current version, have you built my
function buffer-marker-list into it?  M-: (length (buffer-marker-list))
is revealing.  Currently when I run that form repeatedly, I'm getting an
extra 3 markers per repetition.  That's in my version which takes care to
eliminate markers as soon as possible after they're not needed.

-- 
Alan Mackenzie (Nuremberg, Germany).