GNU bug report logs - #36877
25.3; uniquify renaway uniquify-managed list

Previous Next

Full log

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

From: David Biesack <David.Biesack <at> Apiture.com>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: "36877 <at> debbugs.gnu.org" <36877 <at> debbugs.gnu.org>
Subject: Re: bug#36877: 25.3; uniquify renaway uniquify-managed list
Date: Wed, 25 Nov 2020 17:19:41 +0000

Note that this problem is still persisting for me, both in Emacs 26 and also in Emacs 27.1
which I just upgraded to.

I have implemented a workaround to the uniquify-managed list growing
Exponentially after using revert-buffer. See this patch

  *** /dev/fd/632020-11-25 12:18:39.000000000 -0500
--- /Users/david.biesack/emacs/uniqify.el2020-11-25 11:24:19.000000000 -0500
***************
*** 69,74 ****
--- 69,77 ----
  ;;   Stefan Monnier <monnier <at> cs.yale.edu> 17 Nov 2000
  ;; Algorithm and data structure changed to reduce consing with lots of buffers
  ;;   Francesco Potortì <pot <at> gnu.org> (ideas by rms and monnier) 2001-07-18
+ ;; Added workaround to uniqify-managed list growing exponentially
+ ;;   (underlying problem still exists tho)
+ ;;   DavidBiesack <at> gmail.com 25Nov20

  ;; Valuable feedback was provided by
  ;; Paul Smith <psmith <at> baynetworks.com>,
***************
*** 270,275 ****
--- 273,285 ----
  (defun uniquify-rationalize (fix-list)
    ;; Set up uniquify to re-rationalize after killing/renaming
    ;; if there is a conflict.
+
+   ;; When using revert-buffer, the uniquify-managed list grows exponentially;
+   ;; and there are many duplicates items in the list. So sort and remove dups first.
+   ;; (The real fix would be to find/repair whatever allows dups in the list,
+   ;; or use a hashtable instead.)
+   (setq fix-list (delete-dups (sort fix-list 'uniquify-item-greaterp)))
+
    (dolist (item fix-list)
      (with-current-buffer (uniquify-item-buffer item)
        ;; Refresh the dirnames and proposed names.

David Biesack | Vice President, API Platforms
David.Biesack <at> apiture.com | @davidbiesack <https://twitter.com/davidbiesack>




On 8/21/19, 8:47 AM, "David Biesack" <David.Biesack <at> Apiture.com> wrote:

    No, uniquify-after-kill-buffer-p is set to t in my session; no customization.

    David Biesack | Vice President, API Platforms
    David.Biesack <at> apiture.com | @davidbiesack <https://twitter.com/davidbiesack>





    On 8/20/19, 10:47 PM, "Noam Postavsky" <npostavs <at> gmail.com> wrote:

        David Biesack <David.Biesack <at> Apiture.com> writes:

        > Attached is a backtrace.
        > Let me know if there is other advice I can add to help track this down.

        The attachment seems to be missing.  But anyway, I have a simple
        reproducer now, so we don't need any more backtraces.  I found setting
        uniquify-after-kill-buffer-p to nil was needed to reproduce this, do you
        have that setting in your init?





Disclaimer: The information in this message may be proprietary and/or confidential, and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify Apiture immediately by replying to this message and deleting it from your computer.

Previous Next

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