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