emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#46908: closed (28.0.50; Dozens of spurious markers in buffer-undo-li


From: GNU bug Tracking System
Subject: bug#46908: closed (28.0.50; Dozens of spurious markers in buffer-undo-list)
Date: Mon, 20 Jun 2022 13:57:02 +0000

Your message dated Mon, 20 Jun 2022 15:56:43 +0200
with message-id <87v8sv4ew4.fsf@web.de>
and subject line Re: bug#46908: 28.0.50; Dozens of spurious markers in 
buffer-undo-list
has caused the debbugs.gnu.org bug report #46908,
regarding 28.0.50; Dozens of spurious markers in buffer-undo-list
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
46908: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46908
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: 28.0.50; Dozens of spurious markers in buffer-undo-list Date: Wed, 03 Mar 2021 23:45:29 +0100 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
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



--- End Message ---
--- Begin Message --- Subject: Re: bug#46908: 28.0.50; Dozens of spurious markers in buffer-undo-list Date: Mon, 20 Jun 2022 15:56:43 +0200 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
Lars Ingebrigtsen <larsi@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.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]