From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.help Subject: Re: A ton of marker entry in buffer-und-list Date: Mon, 01 Mar 2021 13:13:22 -0500 Message-ID: References: <72F34690-3033-4CC5-8AFC-89C6158AA65D@gmail.com> <83k0qvqnul.fsf@gnu.org> <834khzq7iv.fsf@gnu.org> <04692508-554F-426B-BFE6-1C4A9B7D6307@gmail.com> <87czwm5wl8.fsf@web.de> <83h7lyoun8.fsf@gnu.org> <87y2f8gbmt.fsf@web.de> <87lfb7iv04.fsf@web.de> <8B9B7C97-A763-47EB-98BD-7A89B03E7182@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14046"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) To: help-gnu-emacs@gnu.org Cancel-Lock: sha1:ZibbIu2/a7NdSrQB5hY6H3nIC0c= Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Mon Mar 01 19:14:13 2021 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lGn3Y-0003Qj-CC for geh-help-gnu-emacs@m.gmane-mx.org; Mon, 01 Mar 2021 19:14:08 +0100 Original-Received: from localhost ([::1]:45478 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lGn3X-0006im-DM for geh-help-gnu-emacs@m.gmane-mx.org; Mon, 01 Mar 2021 13:14:07 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55122) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lGn36-0006dV-ON for help-gnu-emacs@gnu.org; Mon, 01 Mar 2021 13:13:40 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]:37278) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lGn2y-0000Xq-NW for help-gnu-emacs@gnu.org; Mon, 01 Mar 2021 13:13:39 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1lGn2w-0002c4-Qm for help-gnu-emacs@gnu.org; Mon, 01 Mar 2021 19:13:30 +0100 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=geh-help-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:128328 Archived-At: >>> Hmmm, I just tried again and alas, I get the markers even without >>> winner-mode. For some reason disabling winner-mode solved it when I >>> last tested it. How strange. >> >> Ok. >> >> Now I used this: >> >> #+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 get the number of different markers in `buffer-undo-list', after >> reproducing the recipe. The answer was always "1". Just a bunch of >> entries referring to one and the same marker. That seems sane. >> >> Are you able to provide a more pathological recipe? >> > > Using the same recipe, I got 18, the number of marker entries in each undo > step. Also, even if the answer is 1, it is not ok because that shortens the > number of undo a buffer can record by a factor of n (e.g., 18 in my case). IIUC this is the `window-point` marker being moved each time. We could try and avoid this by not recording it for the `window-point` of the current `selected-window` (since its point is temporarily kept elsewhere, really), but I'm not sure it's worth the trouble. It's not as bad as it looks: this factor 18 is simply because those 18 insertions were collapsed into a single undo entry by `undo-auto-amalgamate`, so it only applies when the only thing you do is `self-insert-command`. In "real life" the impact should be significantly lower than that. Of course, another way to reduce the problem is to improve the amalgamation code so it not only amalgamate the entries for the actual insertion but also the associated 18 entries that move that one marker. Stefan