bug#36877: 25.3; uniquify renaway uniquify-managed list

[David Biesack]

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@cs.yale.edu> 17 Nov 2000
  ;; Algorithm and data structure changed to reduce consing with lots of buffers
  ;;   Francesco Potortì <pot@gnu.org> (ideas by rms and monnier) 2001-07-18
+ ;; Added workaround to uniqify-managed list growing exponentially
+ ;;   (underlying problem still exists tho)
+ ;;   DavidBiesack@gmail.com 25Nov20

  ;; Valuable feedback was provided by
  ;; Paul Smith <psmith@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@apiture.com | @davidbiesack <https://twitter.com/davidbiesack>




On 8/21/19, 8:47 AM, "David Biesack" <David.Biesack@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@apiture.com | @davidbiesack <https://twitter.com/davidbiesack>





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

        David Biesack <David.Biesack@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.