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

Previous Next

Package: emacs;

Reported by: Óscar Fuentes <oscarfv <at> eclipso.eu>

Date: Fri, 8 Aug 2025 16:45:03 UTC

Severity: normal

Found in version 31.0.50

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 08:19:36 +0000
Hello, Gerd.

On Wed, Aug 13, 2025 at 08:39:11 +0200, Gerd Möllmann wrote:
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> > Helmut Eller <eller.helmut <at> gmail.com> 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).




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.