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: Alan Mackenzie <acm <at> muc.de>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: pipcet <at> protonmail.com, Helmut Eller <eller.helmut <at> gmail.com>, Óscar Fuentes <oscarfv <at> eclipso.eu>, monnier <at> iro.umontreal.ca, acm <at> muc.de, 79200 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: bug#79200: 31.0.50; Duplicated elements for '#<marker at' in buffer-undo-list
Date: Wed, 13 Aug 2025 13:11:18 +0000

Hello, Gerd.

On Wed, Aug 13, 2025 at 10:37:49 +0200, Gerd Möllmann wrote:
> Alan Mackenzie <acm <at> muc.de> writes:

> >> 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.

> Hi Alan.

> > 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.

> One would hope so, yes :-).

> > 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.

> No, I don't have your function. Reason is that there are currently 3
> implementations of BUF_MARKERS, and porting to all the variants was to
> much for me, ATM.

> (1) in mainstream BUF_MARKERS is a list

> (2) in igc it's a "marker array"

> (3) in my Emacs it's a different kind of marker array. That's because
>     Stef asked if I could port the marker array from (2) to mainstream,
>     and that ended up also with a different marker implementation. That
>     I ported back to mainstream in feature/text-index, text-index.[ch]
>     and marker-array.[ch]. Don't know what Stef's plans are wrt to that.

> It's complicated ;-).

For what it's worth, I put next--marker-id into my Emacs, just as a
counter, nothing else.

In my emacs -Q, I do C-h v next--marker-id like you did, and a repeated
g to refresh it.  I get just 76 markers made at each iteration.

That makes your 472 look high indeed.  Might it possibly be there's a
bug with DEFVAR_INT somewhere, and that 472 = 8 * 59 has wrongly got the
3 type bits in it, and is really just 59?  Just a suggestion.

-- 
Alan Mackenzie (Nuremberg, Germany).

Previous Next

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