GNU bug report logs - #46908
28.0.50; Dozens of spurious markers in buffer-undo-list

Previous Next

Package: emacs;

Reported by: Michael Heerdegen <michael_heerdegen <at> web.de>

Date: Wed, 3 Mar 2021 22:46:02 UTC

Severity: normal

Tags: moreinfo

Found in version 28.0.50

Done: Michael Heerdegen <michael_heerdegen <at> web.de>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 46908 in the body.
You can then email your comments to 46908 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#46908; Package emacs. (Wed, 03 Mar 2021 22:46:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Heerdegen <michael_heerdegen <at> web.de>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Wed, 03 Mar 2021 22:46:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: bug-gnu-emacs <at> gnu.org
Cc: Yuan Fu <casouri <at> gmail.com>
Subject: 28.0.50; Dozens of spurious markers in buffer-undo-list
Date: Wed, 03 Mar 2021 23:45:29 +0100
Hello,

after using `undo', `buffer-undo-list' often contains entries
referencing several or dozens of markers (seemingly unrelated to
overlays or such; I dunno from where they originate).  I know this
happens in current Emacs master, and I also found the problem in the
27.1 coming with Debian testing, build from 2020-11-08.  I tried in X.

I measure the count of different marker objects in a buffer's
`buffer-undo-list' with this function:

#+begin_src emacs-lisp
(defun count-markers-in-buffer-undo-list ()
  "Message number of (different) markers in `buffer-undo-list'."
  (interactive)
  (require 'cl-lib)
  (message "%d" (length
                 (cl-delete-duplicates
                  (seq-filter #'markerp (flatten-tree (copy-tree buffer-undo-list)))
                  :test #'eq))))
#+end_src

To reproduce the problem, open a fresh emacs -Q, and in *scratch*,
something like this should do it:

"C-5 C-0 a, RET, C-SPC, C-p, C-SPC, C-n, M-w,
C-y, C-y, C-y";

this recipe is by Yuan Fu, who first reported the problem in emacs-help,
and who is CC'd.  Then he calls the above command and gets a number much
larger than 1.

I can reproduce the problem without copy-and-paste, I just hold down the
"a" key and insert some random space chars in between, then undo
everything.  Sometimes I need to repeat once or twice to get a number
larger than "1", but very soon I see numbers like "40" which definitely
look pathological.  For me the appearance of the issue seems to behave a
bit randomly.


Thanks in advance,

Michael.



In GNU Emacs 28.0.50 (build 6, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0)
 of 2021-03-03 built on drachen
Repository revision: b28b8d83ac882415555fe02b73a26542c9fca781
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12010000
System Description: Debian GNU/Linux bullseye/sid

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBSELINUX LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SOUND
THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM GTK3 ZLIB

Important settings:
  value of $LC_ALL: de_DE.utf8
  value of $LC_COLLATE: C
  value of $LC_TIME: C
  value of $LANG: de_DE.utf8
  locale-coding-system: utf-8-unix




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#46908; Package emacs. (Thu, 04 Mar 2021 08:36:02 GMT) Full text and rfc822 format available.

Message #8 received at 46908 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Michael Heerdegen <michael_heerdegen <at> web.de>, 46908 <at> debbugs.gnu.org
Cc: Yuan Fu <casouri <at> gmail.com>
Subject: Re: bug#46908: 28.0.50; Dozens of spurious markers in buffer-undo-list
Date: Thu, 4 Mar 2021 09:35:41 +0100
> this recipe is by Yuan Fu, who first reported the problem in emacs-help,
> and who is CC'd.  Then he calls the above command and gets a number much
> larger than 1.

IIRC the thread on emacs-help mentioned repeated occurrences of setting
the window-point marker.  Is that still (one of) the main issue(s) or
does the problem happen independently of that?.

martin




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#46908; Package emacs. (Thu, 04 Mar 2021 16:41:02 GMT) Full text and rfc822 format available.

Message #11 received at 46908 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 46908 <at> debbugs.gnu.org, Yuan Fu <casouri <at> gmail.com>
Subject: Re: bug#46908: 28.0.50; Dozens of spurious markers in buffer-undo-list
Date: Thu, 04 Mar 2021 17:40:32 +0100
martin rudalics <rudalics <at> gmx.at> writes:

> IIRC the thread on emacs-help mentioned repeated occurrences of setting
> the window-point marker.  Is that still (one of) the main issue(s) or
> does the problem happen independently of that?.

That was guessing, because winner-mode had been mentioned.  But the
issue seems to be unrelated to winner-mode.

Independently from the window-point marker?  I don't know if there is a
relation to the window-point marker, probably not, because, if there is,
I guess we would not see dozens of _different_ markers.  These could be
copies of the window-point marker created somewhere, I have no clue.

Michael.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#46908; Package emacs. (Thu, 04 Mar 2021 17:21:02 GMT) Full text and rfc822 format available.

Message #14 received at 46908 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 46908 <at> debbugs.gnu.org, Yuan Fu <casouri <at> gmail.com>
Subject: Re: bug#46908: 28.0.50; Dozens of spurious markers in buffer-undo-list
Date: Thu, 4 Mar 2021 18:20:27 +0100
> Independently from the window-point marker?  I don't know if there is a
> relation to the window-point marker, probably not, because, if there is,
> I guess we would not see dozens of _different_ markers.  These could be
> copies of the window-point marker created somewhere, I have no clue.

When I read the discussion on emacs-help I tried with `buffer-undo-list'
nil and doing some window modifications but didn't find a smoking gun.
So I'm afraid you have to look into your undo lists more closely to find
out whether some `with-silent-modifications' are missing.  Maybe
'winner-mode' and its window configuration and active region handling
can give a clue.

martin




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#46908; Package emacs. (Thu, 04 Mar 2021 18:36:02 GMT) Full text and rfc822 format available.

Message #17 received at 46908 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 46908 <at> debbugs.gnu.org, Yuan Fu <casouri <at> gmail.com>
Subject: Re: bug#46908: 28.0.50; Dozens of spurious markers in buffer-undo-list
Date: Thu, 04 Mar 2021 19:35:15 +0100
martin rudalics <rudalics <at> gmx.at> writes:

> When I read the discussion on emacs-help I tried with `buffer-undo-list'
> nil and doing some window modifications but didn't find a smoking gun.

AFAIK window modifications are not necessary to reproduce the issue,
probably they are completely unrelated.

Did you try to reproduce the issue with the recipe?  It is complete.

> So I'm afraid you have to look into your undo lists more closely to find
> out whether some `with-silent-modifications' are missing.  Maybe
> 'winner-mode' and its window configuration and active region handling
> can give a clue.

Sorry for the confusion: We did not turn winner-mode on in the recipe,
please just ignore that part of the discussion, that was a false lead.
You just need insert and undo to reproduce.  Please try.  emacs -Q, just
editing commands plus undo produce the zombi markers.

Regards,

Michael.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#46908; Package emacs. (Fri, 05 Mar 2021 09:12:02 GMT) Full text and rfc822 format available.

Message #20 received at 46908 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 46908 <at> debbugs.gnu.org, Yuan Fu <casouri <at> gmail.com>
Subject: Re: bug#46908: 28.0.50; Dozens of spurious markers in buffer-undo-list
Date: Fri, 5 Mar 2021 10:11:34 +0100
>> When I read the discussion on emacs-help I tried with `buffer-undo-list'
>> nil and doing some window modifications but didn't find a smoking gun.
>
> AFAIK window modifications are not necessary to reproduce the issue,
> probably they are completely unrelated.

Maybe.  But I don't know of any packages that are much interested in
reading or manipulating `window-point'.  So if `window-point' is
involved in at least one scenario that reproduces the problem, it might
help to trace that occurrence back to its origins.

> Did you try to reproduce the issue with the recipe?  It is complete.

I did not because I just believe you that your recipe is valid.  The
problem is that you have to trace back those marker entries back to
where they have been created in such abundance.  And I have no idea
how to do that.

> Sorry for the confusion:

You did not confuse me.

> We did not turn winner-mode on in the recipe,
> please just ignore that part of the discussion, that was a false lead.

If turning on `winner-mode' _can_ create many `window-point' marker
entries, it's not necessarily a false lead.  It might help to locate the
real culprit with one important restriction: You'd have to look into
clients that either deal with `window-point' directly or call something
that does deal with `window-point' only.

> You just need insert and undo to reproduce.  Please try.  emacs -Q, just
> editing commands plus undo produce the zombi markers.

I tried it now.  The only thing I can say is that with Emacs 27 it
usually returns 0 or 1 here while with master it returns 10.  So maybe
you should try (after verifying what I found out) to trace the recent
changes in master.

martin




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#46908; Package emacs. (Fri, 05 Mar 2021 09:51:02 GMT) Full text and rfc822 format available.

Message #23 received at 46908 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 46908 <at> debbugs.gnu.org, Yuan Fu <casouri <at> gmail.com>
Subject: Re: bug#46908: 28.0.50; Dozens of spurious markers in buffer-undo-list
Date: Fri, 5 Mar 2021 10:50:35 +0100
> I tried it now.  The only thing I can say is that with Emacs 27 it
> usually returns 0 or 1 here while with master it returns 10.  So maybe
> you should try (after verifying what I found out) to trace the recent
> changes in master.

The "it" above is `count-markers-in-buffer-undo-list'.  And with "trace"
I really meant "bisect".  But make sure to check first what I said about
the Emacs 27 behavior - YMMV.

martin




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#46908; Package emacs. (Sat, 06 Mar 2021 00:52:02 GMT) Full text and rfc822 format available.

Message #26 received at 46908 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 46908 <at> debbugs.gnu.org, Yuan Fu <casouri <at> gmail.com>
Subject: Re: bug#46908: 28.0.50; Dozens of spurious markers in buffer-undo-list
Date: Sat, 06 Mar 2021 01:51:00 +0100
martin rudalics <rudalics <at> gmx.at> writes:

> > I tried it now.  The only thing I can say is that with Emacs 27 it
> > usually returns 0 or 1 here while with master it returns 10.  So maybe
> > you should try (after verifying what I found out) to trace the recent
> > changes in master.
>
> The "it" above is `count-markers-in-buffer-undo-list'.  And with "trace"
> I really meant "bisect".  But make sure to check first what I said about
> the Emacs 27 behavior - YMMV.

I cannot confirm that, no.  I can reproduce the issue in a newly built
Emacs 27 as well as in the 27 that comes with Debian.  "It" again being
`count-markers-in-buffer-undo-list'.

My question is what amount of that is pathological.  A lot of code
creates markers "on the fly", a lot, e.g. jit-lock or yank (push-mark)
or display-buffer.  When undo is performed before gc is run, they end in
buffer-undo-list.

Does making a marker point to nil with `set-marker' then make it
suitable for garbage collection?  I guess not.

My observation: if I set undo-buffer-list to nil after reproducing the
issue, `count-markers-in-buffer-undo-list' reports "0" afterwards.  So I
wonder whether what we see is maybe normal business and an unfortunate
side effect of undo recording marker positions and gc running not often
enough to prevent these accidents?

I can continue testing with emacs-26 if you want.

Regards,

Michael.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#46908; Package emacs. (Sat, 06 Mar 2021 07:49:01 GMT) Full text and rfc822 format available.

Message #29 received at 46908 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 46908 <at> debbugs.gnu.org, rudalics <at> gmx.at, casouri <at> gmail.com
Subject: Re: bug#46908: 28.0.50; Dozens of spurious markers in buffer-undo-list
Date: Sat, 06 Mar 2021 09:48:35 +0200
> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Date: Sat, 06 Mar 2021 01:51:00 +0100
> Cc: 46908 <at> debbugs.gnu.org, Yuan Fu <casouri <at> gmail.com>
> 
> My question is what amount of that is pathological.  A lot of code
> creates markers "on the fly", a lot, e.g. jit-lock or yank (push-mark)
> or display-buffer.  When undo is performed before gc is run, they end in
> buffer-undo-list.
> 
> Does making a marker point to nil with `set-marker' then make it
> suitable for garbage collection?  I guess not.

GC compacts the buffer's undo-list, and that is supposed to remove
those entries.  Doesn't it?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#46908; Package emacs. (Sat, 06 Mar 2021 08:41:02 GMT) Full text and rfc822 format available.

Message #32 received at 46908 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 46908 <at> debbugs.gnu.org, Yuan Fu <casouri <at> gmail.com>
Subject: Re: bug#46908: 28.0.50; Dozens of spurious markers in buffer-undo-list
Date: Sat, 6 Mar 2021 09:40:20 +0100
> My observation: if I set undo-buffer-list to nil after reproducing the
> issue, `count-markers-in-buffer-undo-list' reports "0" afterwards.

What else did you expect?  Or did you mean in all subsequent runs of
your scenario?

> So I
> wonder whether what we see is maybe normal business and an unfortunate
> side effect of undo recording marker positions and gc running not often
> enough to prevent these accidents?

I'm not sure what you mean.  Here, when trying your scenario, I do set
`buffer-undo-list' to nil first, so the initial insertion is not
recorded and run `count-markers-in-buffer-undo-list' from a globally set
key so the minibuffer is not involved.  And meanwhile I cannot reproduce
your scenario with Emacs 28 either, I get zero invariably.

martin




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#46908; Package emacs. (Sun, 07 Mar 2021 02:41:02 GMT) Full text and rfc822 format available.

Message #35 received at 46908 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 46908 <at> debbugs.gnu.org, Yuan Fu <casouri <at> gmail.com>
Subject: Re: bug#46908: 28.0.50; Dozens of spurious markers in buffer-undo-list
Date: Sun, 07 Mar 2021 03:40:50 +0100
martin rudalics <rudalics <at> gmx.at> writes:

> I'm not sure what you mean.  Here, when trying your scenario, I do set
> `buffer-undo-list' to nil first, so the initial insertion is not
> recorded and run `count-markers-in-buffer-undo-list' from a globally set
> key so the minibuffer is not involved.  And meanwhile I cannot reproduce
> your scenario with Emacs 28 either, I get zero invariably.

Just now I tried exactly that, exactly that way.  Using only
self-insert-command invocations and C-SPC, M-w and C-y, I was able to
get to values of more than 20 in 15 seconds or so with the first
attempt.

Michael.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#46908; Package emacs. (Sun, 07 Mar 2021 02:46:01 GMT) Full text and rfc822 format available.

Message #38 received at 46908 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 46908 <at> debbugs.gnu.org, rudalics <at> gmx.at, casouri <at> gmail.com
Subject: Re: bug#46908: 28.0.50; Dozens of spurious markers in buffer-undo-list
Date: Sun, 07 Mar 2021 03:45:40 +0100
Eli Zaretskii <eliz <at> gnu.org> writes:

> > Does making a marker point to nil with `set-marker' then make it
> > suitable for garbage collection?  I guess not.
>
> GC compacts the buffer's undo-list, and that is supposed to remove
> those entries.  Doesn't it?

Maybe it does that.

What I can say that gc removes a significant amount of markers, but that
also a lot are left after gc.  And the positions of the markers that are
left are numbers (not nil).

Michael.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#46908; Package emacs. (Mon, 08 Mar 2021 04:01:01 GMT) Full text and rfc822 format available.

Message #41 received at 46908 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 46908 <at> debbugs.gnu.org, Yuan Fu <casouri <at> gmail.com>
Subject: Re: bug#46908: 28.0.50; Dozens of spurious markers in buffer-undo-list
Date: Mon, 08 Mar 2021 05:00:13 +0100
Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> I cannot confirm that, no.  I can reproduce the issue in a newly built
> Emacs 27 as well as in the 27 that comes with Debian.  "It" again being
> `count-markers-in-buffer-undo-list'.

The issue disappears (marker count stays constantly less than 3) if I
comment out these two expressions in `push-mark':

  (add-to-history 'mark-ring (copy-marker (mark-marker)) mark-ring-max t)

  (add-to-history
    'global-mark-ring (copy-marker (mark-marker)) global-mark-ring-max t)

I think we really have a problem here: when those newly created markers
are thrown out of the rings, they are not invalidated, and are also
still referenced by buffer-undo-list, so they will live forever, AFAIU.

Michael.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#46908; Package emacs. (Mon, 08 Mar 2021 08:27:02 GMT) Full text and rfc822 format available.

Message #44 received at 46908 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 46908 <at> debbugs.gnu.org, Yuan Fu <casouri <at> gmail.com>
Subject: Re: bug#46908: 28.0.50; Dozens of spurious markers in buffer-undo-list
Date: Mon, 8 Mar 2021 09:26:42 +0100
>> I cannot confirm that, no.  I can reproduce the issue in a newly built
>> Emacs 27 as well as in the 27 that comes with Debian.  "It" again being
>> `count-markers-in-buffer-undo-list'.
>
> The issue disappears (marker count stays constantly less than 3) if I
> comment out these two expressions in `push-mark':
>
>    (add-to-history 'mark-ring (copy-marker (mark-marker)) mark-ring-max t)
>
>    (add-to-history
>      'global-mark-ring (copy-marker (mark-marker)) global-mark-ring-max t)
>
> I think we really have a problem here: when those newly created markers
> are thrown out of the rings, they are not invalidated, and are also
> still referenced by buffer-undo-list, so they will live forever, AFAIU.

So you mean that we really have two problems here, both caused by
`push-mark'?  IIUC a marker is "thrown out of the rings" when its buffer
gets deleted or a marker is pushed on a "full" ring.  I suppose that
"invalidating" markers in these cases should be safe.  But how comes
that `add-to-history' affects `buffer-undo-list'?

martin




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#46908; Package emacs. (Tue, 09 Mar 2021 02:05:01 GMT) Full text and rfc822 format available.

Message #47 received at 46908 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 46908 <at> debbugs.gnu.org, Yuan Fu <casouri <at> gmail.com>
Subject: Re: bug#46908: 28.0.50; Dozens of spurious markers in buffer-undo-list
Date: Tue, 09 Mar 2021 03:04:14 +0100
martin rudalics <rudalics <at> gmx.at> writes:

> So you mean that we really have two problems here, both caused by
> `push-mark'?  IIUC a marker is "thrown out of the rings" when its buffer
> gets deleted or a marker is pushed on a "full" ring.  I suppose that
> "invalidating" markers in these cases should be safe.

But actually that doesn't help, markers pointing to nowhere are not
removed from buffer-undo-list by garbage-collect.

> But how comes that `add-to-history' affects `buffer-undo-list'?

`add-to-history' has no relevance here, no.  There mere existence of a
marker in any buffer does, IIUC, cause it to be referenced by
buffer-undo-list sooner or later, because undoing and redoing inside
text containing a marker is not always without ambiguity regarding
marker positioning, so the undo system adds hints to buffer-undo-list
how these markers must be placed/repositioned.

Michael.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#46908; Package emacs. (Tue, 09 Mar 2021 02:21:01 GMT) Full text and rfc822 format available.

Message #50 received at 46908 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 46908 <at> debbugs.gnu.org, Yuan Fu <casouri <at> gmail.com>
Subject: Re: bug#46908: 28.0.50; Dozens of spurious markers in buffer-undo-list
Date: Tue, 09 Mar 2021 03:20:30 +0100
Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> > But how comes that `add-to-history' affects `buffer-undo-list'?
>
> `add-to-history' has no relevance here, no.  There mere existence of a
> marker in any buffer does, IIUC, cause it to be referenced by
> buffer-undo-list sooner or later, because undoing and redoing inside
> text containing a marker is not always without ambiguity regarding
> marker positioning, so the undo system adds hints to buffer-undo-list
> how these markers must be placed/repositioned.

I did some more experimentation (repeated copy, paste, undo and
garbage-collect in *scratch*), and I saw that the number of markers
living in buffer-undo-list is not monotonously increasing.  After some
time, the amount settles between 20 and 45 or so.  And stays in that
range.  Giving that a large, but still limited number of copies of the
mark marker is stored in the mark rings, that amount of markers isn't a
surprise, and if the number is not constantly growing,
everything...works as expected so far I think.  Correct?

Michael.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#46908; Package emacs. (Tue, 09 Mar 2021 06:20:02 GMT) Full text and rfc822 format available.

Message #53 received at 46908 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 46908 <at> debbugs.gnu.org, rudalics <at> gmx.at, casouri <at> gmail.com
Subject: Re: bug#46908: 28.0.50; Dozens of spurious markers in buffer-undo-list
Date: Tue, 09 Mar 2021 01:19:01 -0500
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I think we really have a problem here: when those newly created markers
  > are thrown out of the rings, they are not invalidated, and are also
  > still referenced by buffer-undo-list, so they will live forever, AFAIU.

I am getting the feeling that references from buffer-undo-list should
not keep markers alive.  That they should be some sort of weak reference.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#46908; Package emacs. (Tue, 09 Mar 2021 08:11:02 GMT) Full text and rfc822 format available.

Message #56 received at 46908 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 46908 <at> debbugs.gnu.org, Yuan Fu <casouri <at> gmail.com>
Subject: Re: bug#46908: 28.0.50; Dozens of spurious markers in buffer-undo-list
Date: Tue, 9 Mar 2021 09:10:15 +0100
> `add-to-history' has no relevance here, no.  There mere existence of a
> marker in any buffer does, IIUC, cause it to be referenced by
> buffer-undo-list sooner or later, because undoing and redoing inside
> text containing a marker is not always without ambiguity regarding
> marker positioning, so the undo system adds hints to buffer-undo-list
> how these markers must be placed/repositioned.

Suppose I put a marker into a buffer and do ten distinct modifications
of the buffer, each modifying that marker's position.  So I get ten
additional entries in the undo list.  Does this mean I get ten copies of
that marker too?

martin




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#46908; Package emacs. (Wed, 10 Mar 2021 02:18:02 GMT) Full text and rfc822 format available.

Message #59 received at 46908 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 46908 <at> debbugs.gnu.org, Yuan Fu <casouri <at> gmail.com>
Subject: Re: bug#46908: 28.0.50; Dozens of spurious markers in buffer-undo-list
Date: Wed, 10 Mar 2021 03:17:49 +0100
martin rudalics <rudalics <at> gmx.at> writes:

> Suppose I put a marker into a buffer and do ten distinct modifications
> of the buffer, each modifying that marker's position.  So I get ten
> additional entries in the undo list.  Does this mean I get ten copies
> of that marker too?

As far as I understand - of course not!  When undo needs to restore
previous positions of that marker, it only can do that when the entries
in buffer-undo-list refer to the original marker.

`push-mark' does copy the mark marker, OTOH, it must, because a mark
ring containing the mark marker 16 times would be nonsense.

Michael.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#46908; Package emacs. (Wed, 10 Mar 2021 02:23:02 GMT) Full text and rfc822 format available.

Message #62 received at 46908 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Richard Stallman <rms <at> gnu.org>
Cc: 46908 <at> debbugs.gnu.org, rudalics <at> gmx.at, casouri <at> gmail.com
Subject: Re: bug#46908: 28.0.50; Dozens of spurious markers in buffer-undo-list
Date: Wed, 10 Mar 2021 03:22:42 +0100
Richard Stallman <rms <at> gnu.org> writes:

> I am getting the feeling that references from buffer-undo-list should
> not keep markers alive.  That they should be some sort of weak
> reference.

Could well be that it already works like this, the result of my
experiments went this way.  I currently just don't understand how that
stuff works.

Regards,

Michael.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#46908; Package emacs. (Wed, 10 Mar 2021 05:51:01 GMT) Full text and rfc822 format available.

Message #65 received at 46908 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 46908 <at> debbugs.gnu.org, rudalics <at> gmx.at, casouri <at> gmail.com
Subject: Re: bug#46908: 28.0.50; Dozens of spurious markers in buffer-undo-list
Date: Wed, 10 Mar 2021 00:49:54 -0500
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > But actually that doesn't help, markers pointing to nowhere are not
  > removed from buffer-undo-list by garbage-collect.

Does undo ever need to relocate a marker that points to nowhere?  I
think it doesn't, so I think it would be ok for GC to delete them.

Undo could also delete them.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#46908; Package emacs. (Mon, 20 Jun 2022 00:05:02 GMT) Full text and rfc822 format available.

Message #68 received at 46908 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 46908 <at> debbugs.gnu.org, martin rudalics <rudalics <at> gmx.at>,
 Yuan Fu <casouri <at> gmail.com>
Subject: Re: bug#46908: 28.0.50; Dozens of spurious markers in buffer-undo-list
Date: Mon, 20 Jun 2022 02:04:30 +0200
Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> I did some more experimentation (repeated copy, paste, undo and
> garbage-collect in *scratch*), and I saw that the number of markers
> living in buffer-undo-list is not monotonously increasing.  After some
> time, the amount settles between 20 and 45 or so.  And stays in that
> range.  Giving that a large, but still limited number of copies of the
> mark marker is stored in the mark rings, that amount of markers isn't a
> surprise, and if the number is not constantly growing,
> everything...works as expected so far I think.  Correct?

I just lightly skimmed this thread, but does this mean that there's
nothing to fix here?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Added tag(s) moreinfo. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Mon, 20 Jun 2022 00:05:02 GMT) Full text and rfc822 format available.

Reply sent to Michael Heerdegen <michael_heerdegen <at> web.de>:
You have taken responsibility. (Mon, 20 Jun 2022 13:57:02 GMT) Full text and rfc822 format available.

Notification sent to Michael Heerdegen <michael_heerdegen <at> web.de>:
bug acknowledged by developer. (Mon, 20 Jun 2022 13:57:02 GMT) Full text and rfc822 format available.

Message #75 received at 46908-done <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 46908-done <at> debbugs.gnu.org, martin rudalics <rudalics <at> gmx.at>,
 Yuan Fu <casouri <at> gmail.com>
Subject: Re: bug#46908: 28.0.50; Dozens of spurious markers in buffer-undo-list
Date: Mon, 20 Jun 2022 15:56:43 +0200
Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> > Giving that a large, but still limited number of copies of the
> > mark marker is stored in the mark rings, that amount of markers isn't a
> > surprise, and if the number is not constantly growing,
> > everything...works as expected so far I think.  Correct?
>
> I just lightly skimmed this thread, but does this mean that there's
> nothing to fix here?

Not unlikely.

Ok, let's close this one, I don't think this will lead to
something.

Michael.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 19 Jul 2022 11:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 1 year and 279 days ago.

Previous Next


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