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

From: Alan Mackenzie <[email-masked]>
Date: Mon, 11 Aug 2025 15:48:13 +0000

Hello again, Pip.

On Sun, Aug 10, 2025 at 16:35:11 +0000, Alan Mackenzie wrote:
> On Sun, Aug 10, 2025 at 14:56:56 +0000, Pip Cet wrote:
> > "Alan Mackenzie" <[email-masked]> writes:
> > > On Sun, Aug 10, 2025 at 06:55:45 +0200, Gerd Möllmann wrote:
> > >> Pip Cet <[email-masked]> writes:

> > >> >> - record_marker_adjustments undo.c:127
> > >> >>   - record_delete record_delete:187
> > >> >>     + casify_region casify_region:555
> > >> >>     + adjust_after_replace adjust_after_replace:1408
> > >> >>     + replace_range replace_range:1639
> > >> >>     + del_range_2 del_range_2:2030
> > >> >>     + record_change record_change:201

> > I think the Lisp part is easy: we can simply capture a backtrace and
> > attach it when creating the marker.

[ .... ]

> Have you got any results back from this, yet?

I've got some results.  With my modified master, when I repeatedly do M-:
(length (buffer-marker-list)), I get three extra markers each iteration.
Tracking them with (a slight modification of) your (Pip's) tool, I see
that all three are ostensibly created by read-from-minibuffer.

[ .... ]

> We just need to track down those remaining three markers and remove them,
> somehow.  :-)

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.

Is it worth the effort, though?  It is unclear how much this would help
the OP's (Óscar's) problem, though it would surely help a bit.

> > This is against feature/igc, but the code looks unchanged from master.

> Indeed, yes.

> > Pip

-- 
Alan Mackenzie (Nuremberg, Germany).