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: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: pipcet <at> protonmail.com, gerd.moellmann <at> gmail.com, oscarfv <at> eclipso.eu, monnier <at> iro.umontreal.ca, 79200 <at> debbugs.gnu.org, acm <at> muc.de
Subject: bug#79200: 31.0.50; Duplicated elements for '#<marker at' in buffer-undo-list
Date: Mon, 11 Aug 2025 19:57:53 +0300

> Date: Mon, 11 Aug 2025 16:35:22 +0000
> Cc: pipcet <at> protonmail.com, gerd.moellmann <at> gmail.com, oscarfv <at> eclipso.eu,
>   monnier <at> iro.umontreal.ca, 79200 <at> debbugs.gnu.org, acm <at> muc.de
> From: Alan Mackenzie <acm <at> muc.de>
> 
> On Mon, Aug 11, 2025 at 19:20:43 +0300, Eli Zaretskii wrote:
> > > Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
> > >  Óscar Fuentes <oscarfv <at> eclipso.eu>, acm <at> muc.de,
> > >  Stefan Monnier <monnier <at> iro.umontreal.ca>, 79200 <at> debbugs.gnu.org
> > > Date: Mon, 11 Aug 2025 15:48:13 +0000
> > > From: Alan Mackenzie <acm <at> muc.de>
> 
> > > Fread_from_minibuffer just calls read_minibuf.  By perusing the source,
> > > it seems that two of the three repeating markers are created in
> > > save_window_save, called from Fcurrent_window_configuration (which is
> > > called from read_minibuf).
> 
> > > With a bit of refactoring, we could arrange for (at least) two of these
> > > three regularly created markers to be nullified.  This would be tedious
> > > rather than difficult.
> 
> > Why aren't they collected by GC?
> 
> They are, eventually.
> 
> But my hypothesis is that between GC runs many hundreds of useless
> markers clog up the buffer's list of markers, and these in turn clog up
> the OP's (Óscar's) undo list.

GC runs quite frequently, and will both collect these markers and
compact the undo list.  So I don't think this is a part of Óscar's
problem, at least not on the master branch.  (On the igc branch we
currently have no solution for compacting the undo list, and I hope we
will find one soon.)

> And that if we could reduce the number of useless live markers we leave
> to GC, we could resolve the OP's problem.  It may even be that the vast
> numbers of markers we suspect get created are slowing Emacs down
> noticeably, though there's no firm evidence for this at the moment.

If GC solves the problem, I don't think we should waste energy and
make the code trickier by trying to get rid of these markers faster.
We have other objects in Emacs that take their time to be collected
(example: font objects), and we don't consider that a problem.

Previous Next

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