From unknown Sun Jun 15 08:44:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#77312: [PATCH] Add uniquify-get-unique-names Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: dmitry@gutov.dev, bug-gnu-emacs@gnu.org Resent-Date: Thu, 27 Mar 2025 15:04:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 77312 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: 77312@debbugs.gnu.org Cc: dmitry@gutov.dev X-Debbugs-Original-To: bug-gnu-emacs@gnu.org X-Debbugs-Original-Xcc: dmitry@gutov.dev Received: via spool by submit@debbugs.gnu.org id=B.174308781521573 (code B ref -1); Thu, 27 Mar 2025 15:04:03 +0000 Received: (at submit) by debbugs.gnu.org; 27 Mar 2025 15:03:35 +0000 Received: from localhost ([127.0.0.1]:50818 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1txolY-0005bN-6r for submit@debbugs.gnu.org; Thu, 27 Mar 2025 11:03:35 -0400 Received: from lists.gnu.org ([2001:470:142::17]:36430) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1txolU-0005Zm-H1 for submit@debbugs.gnu.org; Thu, 27 Mar 2025 11:03:31 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1txolP-0001bx-03 for bug-gnu-emacs@gnu.org; Thu, 27 Mar 2025 11:03:23 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1txolM-0001Te-4i for bug-gnu-emacs@gnu.org; Thu, 27 Mar 2025 11:03:22 -0400 From: Spencer Baugh Date: Thu, 27 Mar 2025 11:03:17 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1743087797; bh=C2bQrXJNDsdEnC7XcH/9zbP5u1wSdXxQYMo9Gr77Cfw=; h=From:To:Subject:Date; b=ZOpHNvybOU2MdPIQN4zVlP7RDfwFfvdU6BpY0oHXSIsK65GSDctTfCLuSVl6Q9OLe r6F1Vvt/LrEQD2ID+ezzSRV+KeogDtoMGYwd8pv5DKDTisaKx/cujMyC1t0qtsjy19 TX3OdJlJ6UcjTJG1LPck1YyXIoP4beVJ+JpNrQrl6vRRzju3Tt4zYqjTa82Bcfg98q ujbY5M4eusWn48+lpLWK97rj1EVx+vzDKSaQphkVSmk+Pg/cd+G8fG+XMXYf/lEiEH dOoDG/HFpKaZVMc+2vfeTPKXtACYWgumzYJ4cQM6uleMQ8WbFqLXBoMZXsGKi+UIKw /cFJTu6TE2wYg== Received-SPF: pass client-ip=64.215.233.18; envelope-from=sbaugh@janestreet.com; helo=mxout5.mail.janestreet.com X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) --=-=-= Content-Type: text/plain Tags: patch This new function provides an interface to uniquify.el which doesn't change the actual names of the buffers. This is useful for any commands which deal with a subset of all buffers; for example, project.el. * lisp/uniquify.el (uniquify-rationalize--generic): Add. (uniquify-rationalize, uniquify-rationalize-a-list) (uniquify-rationalize-conflicting-sublist): Explicitly pass RENAME-BUFFER-FN and GET-BUFFER-FN. (uniquify--stateless-curname, uniquify-get-unique-names): Add. In GNU Emacs 30.1.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.15.12, Xaw scroll bars) of 2025-03-11 built on igm-qws-u22796a Repository revision: 516d1e6463a9659951f7567e038efc5ee2a19bbf Windowing system distributor 'The X.Org Foundation', version 11.0.12011000 System Description: Rocky Linux 8.10 (Green Obsidian) Configured using: 'configure --config-cache --with-x-toolkit=lucid --without-gpm --without-gconf --without-selinux --without-imagemagick --with-modules --with-gif=no --with-cairo --with-rsvg --without-compress-install --with-tree-sitter --with-native-compilation=aot --prefix=/usr/local/home/garnish/raw-emacs/30-20250311_131404' --=-=-= Content-Type: text/patch Content-Disposition: attachment; filename=0001-Add-uniquify-get-unique-names.patch >From afd867ef7577bab1cf83a62c5acaa1bfc5da6305 Mon Sep 17 00:00:00 2001 From: Spencer Baugh Date: Thu, 27 Mar 2025 09:32:47 -0400 Subject: [PATCH] Add uniquify-get-unique-names This new function provides an interface to uniquify.el which doesn't change the actual names of the buffers. This is useful for any commands which deal with a subset of all buffers; for example, project.el. * lisp/uniquify.el (uniquify-rationalize--generic): Add. (uniquify-rationalize, uniquify-rationalize-a-list) (uniquify-rationalize-conflicting-sublist): Explicitly pass RENAME-BUFFER-FN and GET-BUFFER-FN. (uniquify--stateless-curname, uniquify-get-unique-names): Add. --- lisp/uniquify.el | 65 ++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 54 insertions(+), 11 deletions(-) diff --git a/lisp/uniquify.el b/lisp/uniquify.el index 358ae6af651..50971e115b0 100644 --- a/lisp/uniquify.el +++ b/lisp/uniquify.el @@ -320,14 +320,19 @@ uniquify-rerationalize-w/o-cb (defun uniquify-rationalize (fix-list) ;; Set up uniquify to re-rationalize after killing/renaming ;; if there is a conflict. + (dolist (item fix-list) + (with-current-buffer (uniquify-item-buffer item) + (setq uniquify-managed fix-list))) + (uniquify-rationalize--generic fix-list #'uniquify-rename-buffer #'get-buffer)) + +(defun uniquify-rationalize--generic (fix-list rename-buffer-fn get-buffer-fn) (dolist (item fix-list) (with-current-buffer (uniquify-item-buffer item) ;; Refresh the dirnames and proposed names. (setf (uniquify-item-proposed item) (uniquify-get-proposed-name (uniquify-item-base item) (uniquify-item-dirname item) - nil)) - (setq uniquify-managed fix-list))) + nil)))) ;; Strip any shared last directory names of the dirname. (when (and (cdr fix-list) uniquify-strip-common-suffix) (let ((strip t)) @@ -353,13 +358,13 @@ uniquify-rationalize fix-list))))) ;; If uniquify-min-dir-content is 0, this will end up just ;; passing fix-list to uniquify-rationalize-conflicting-sublist. - (uniquify-rationalize-a-list fix-list)) + (uniquify-rationalize-a-list fix-list nil rename-buffer-fn get-buffer-fn)) (defun uniquify-item-greaterp (item1 item2) (string-lessp (uniquify-item-proposed item2) (uniquify-item-proposed item1))) -(defun uniquify-rationalize-a-list (fix-list &optional depth) +(defun uniquify-rationalize-a-list (fix-list depth rename-buffer-fn get-buffer-fn) (unless depth (setq depth uniquify-min-dir-content)) (let (conflicting-sublist ; all elements have the same proposed name (old-proposed "") @@ -370,12 +375,14 @@ uniquify-rationalize-a-list (setq proposed (uniquify-item-proposed item)) (unless (equal proposed old-proposed) (uniquify-rationalize-conflicting-sublist conflicting-sublist - old-proposed depth) + old-proposed depth + rename-buffer-fn get-buffer-fn) (setq conflicting-sublist nil)) (push item conflicting-sublist) (setq old-proposed proposed)) (uniquify-rationalize-conflicting-sublist conflicting-sublist - old-proposed depth))) + old-proposed depth + rename-buffer-fn get-buffer-fn))) (defun uniquify-get-proposed-name (base dirname &optional depth) (unless depth (setq depth uniquify-min-dir-content)) @@ -427,12 +434,12 @@ uniquify-get-proposed-name ;; Deal with conflicting-sublist, all of whose elements have identical ;; "base" components. -(defun uniquify-rationalize-conflicting-sublist (conf-list old-name depth) +(defun uniquify-rationalize-conflicting-sublist (conf-list old-name depth rename-buffer-fn get-buffer-fn) (when conf-list (if (or (cdr conf-list) ;; Check that the proposed name doesn't conflict with some ;; existing buffer. - (let ((buf (get-buffer old-name))) + (let ((buf (funcall get-buffer-fn old-name))) (and buf (not (eq buf (uniquify-item-buffer (car conf-list))))))) (when uniquify-possibly-resolvable (setq uniquify-possibly-resolvable nil @@ -443,10 +450,9 @@ uniquify-rationalize-conflicting-sublist (uniquify-item-base item) (uniquify-item-dirname item) depth))) - (uniquify-rationalize-a-list conf-list depth)) + (uniquify-rationalize-a-list conf-list depth rename-buffer-fn get-buffer-fn)) (unless (string= old-name "") - (uniquify-rename-buffer (car conf-list) old-name))))) - + (funcall rename-buffer-fn (car conf-list) old-name))))) (defun uniquify-rename-buffer (item newname) (let ((buffer (uniquify-item-buffer item))) @@ -456,6 +462,43 @@ uniquify-rename-buffer ;; Pass the `unique' arg, so the advice doesn't mark it as unmanaged. (rename-buffer newname t)))))) +(defvar-local uniquify--stateless-curname nil + "The current unique name of this buffer in `uniquify-get-unique-names'.") + +(defun uniquify-get-unique-names (buffers) + "Return a hash table with a unique name for each buffer in BUFFERS. + +The names are unique only among BUFFERS, and may conflict with other +buffers not in that list. + +This does not rename the buffers or change any state; the unique name is +only present in the returned alist." + (let ((buffer-names (make-hash-table :size (length buffers) :test 'equal))) + (let (fix-lists-by-base) + (dolist (buf buffers) + (with-current-buffer buf + (setq uniquify--stateless-curname (buffer-name buf)) + (puthash (buffer-name buf) buf buffer-names) + (when uniquify-managed + (let ((base (uniquify-item-base (car uniquify-managed)))) + (push + (uniquify-make-item base (uniquify-buffer-file-name buf) buf nil) + (alist-get base fix-lists-by-base nil nil #'equal)))))) + (dolist (pair fix-lists-by-base) + (uniquify-rationalize--generic + (cdr pair) + (lambda (item name) ; rename-buffer + (with-current-buffer (uniquify-item-buffer item) + (remhash uniquify--stateless-curname buffer-names) + (setq uniquify--stateless-curname name) + (puthash name (current-buffer) buffer-names))) + (lambda (name) ; get-buffer + (gethash name buffer-names))))) + (dolist (buf buffers) + (with-current-buffer buf + (kill-local-variable 'uniquify--stateless-curname))) + buffer-names)) + ;;; Hooks from the rest of Emacs (defun uniquify-maybe-rerationalize-w/o-cb () -- 2.39.3 --=-=-=-- From unknown Sun Jun 15 08:44:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#77312: [PATCH] Add uniquify-get-unique-names Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 28 Mar 2025 18:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 77312 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: 77312@debbugs.gnu.org Cc: dmitry@gutov.dev Received: via spool by 77312-submit@debbugs.gnu.org id=B77312.17431878715064 (code B ref 77312); Fri, 28 Mar 2025 18:52:02 +0000 Received: (at 77312) by debbugs.gnu.org; 28 Mar 2025 18:51:11 +0000 Received: from localhost ([127.0.0.1]:55505 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tyEnP-0001Jc-0f for submit@debbugs.gnu.org; Fri, 28 Mar 2025 14:51:11 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:35769) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tyEnJ-0001J3-8T for 77312@debbugs.gnu.org; Fri, 28 Mar 2025 14:51:08 -0400 From: Spencer Baugh In-Reply-To: (Spencer Baugh's message of "Thu, 27 Mar 2025 11:03:17 -0400") References: Date: Fri, 28 Mar 2025 14:50:59 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1743187859; bh=89VXD1ldEHKy5NiAMmdyYkKDxm9HH4/8obSAKbrsnGo=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=qGxNi/JXqFP08BSaK8HDd3o5xU1BABMGuHWpLWFhfXk7iZKKzzGyvtNFz3tY8Be61 3Ph5GaaJhcUIk3R5k7qL80qDuSbCTkNSQzjpfLCXQEj1ufrvV2LbESBYZAf9vt68kB rZoNfGSGwBv6kxT9EPb3iHD4FhmoTY1+GLtEOUJ/HRHfMOjYtSpcZNSMtnSlIIPxL4 1sesBF7pnIeZ4GsW0T81zQYPcmy2crn4yx6edlepGzIdB8UlAcDp8L2q9Ds9leQYBf tRzsyBvy+oDJ/crFMVLMnNAapUVXRz1sGegMszyAtwqa+wPSwtuHJtUrPb7DWV3Qvc wLdedvQg2mWNw== X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --=-=-= Content-Type: text/plain After some use, it seems better to return an alist rather than a hash table from this function; that alist is in the same order as the buffer list that was passed in, which is nice for completion. So here's a version which does that. --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=0001-Add-uniquify-get-unique-names.patch >From 62ff7104ff2cc0ab5a258c2cd83d1278bc804961 Mon Sep 17 00:00:00 2001 From: Spencer Baugh Date: Thu, 27 Mar 2025 09:32:47 -0400 Subject: [PATCH] Add uniquify-get-unique-names This new function provides an interface to uniquify.el which doesn't change the actual names of the buffers. This is useful for any commands which deal with a subset of all buffers; for example, project.el. * lisp/uniquify.el (uniquify-rationalize--generic): Add. (uniquify-rationalize, uniquify-rationalize-a-list) (uniquify-rationalize-conflicting-sublist): Explicitly pass RENAME-BUFFER-FN and GET-BUFFER-FN. (uniquify--stateless-curname, uniquify-get-unique-names): Add. --- lisp/uniquify.el | 66 ++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 55 insertions(+), 11 deletions(-) diff --git a/lisp/uniquify.el b/lisp/uniquify.el index 358ae6af651..ac60228d9d8 100644 --- a/lisp/uniquify.el +++ b/lisp/uniquify.el @@ -320,14 +320,19 @@ uniquify-rerationalize-w/o-cb (defun uniquify-rationalize (fix-list) ;; Set up uniquify to re-rationalize after killing/renaming ;; if there is a conflict. + (dolist (item fix-list) + (with-current-buffer (uniquify-item-buffer item) + (setq uniquify-managed fix-list))) + (uniquify-rationalize--generic fix-list #'uniquify-rename-buffer #'get-buffer)) + +(defun uniquify-rationalize--generic (fix-list rename-buffer-fn get-buffer-fn) (dolist (item fix-list) (with-current-buffer (uniquify-item-buffer item) ;; Refresh the dirnames and proposed names. (setf (uniquify-item-proposed item) (uniquify-get-proposed-name (uniquify-item-base item) (uniquify-item-dirname item) - nil)) - (setq uniquify-managed fix-list))) + nil)))) ;; Strip any shared last directory names of the dirname. (when (and (cdr fix-list) uniquify-strip-common-suffix) (let ((strip t)) @@ -353,13 +358,13 @@ uniquify-rationalize fix-list))))) ;; If uniquify-min-dir-content is 0, this will end up just ;; passing fix-list to uniquify-rationalize-conflicting-sublist. - (uniquify-rationalize-a-list fix-list)) + (uniquify-rationalize-a-list fix-list nil rename-buffer-fn get-buffer-fn)) (defun uniquify-item-greaterp (item1 item2) (string-lessp (uniquify-item-proposed item2) (uniquify-item-proposed item1))) -(defun uniquify-rationalize-a-list (fix-list &optional depth) +(defun uniquify-rationalize-a-list (fix-list depth rename-buffer-fn get-buffer-fn) (unless depth (setq depth uniquify-min-dir-content)) (let (conflicting-sublist ; all elements have the same proposed name (old-proposed "") @@ -370,12 +375,14 @@ uniquify-rationalize-a-list (setq proposed (uniquify-item-proposed item)) (unless (equal proposed old-proposed) (uniquify-rationalize-conflicting-sublist conflicting-sublist - old-proposed depth) + old-proposed depth + rename-buffer-fn get-buffer-fn) (setq conflicting-sublist nil)) (push item conflicting-sublist) (setq old-proposed proposed)) (uniquify-rationalize-conflicting-sublist conflicting-sublist - old-proposed depth))) + old-proposed depth + rename-buffer-fn get-buffer-fn))) (defun uniquify-get-proposed-name (base dirname &optional depth) (unless depth (setq depth uniquify-min-dir-content)) @@ -427,12 +434,12 @@ uniquify-get-proposed-name ;; Deal with conflicting-sublist, all of whose elements have identical ;; "base" components. -(defun uniquify-rationalize-conflicting-sublist (conf-list old-name depth) +(defun uniquify-rationalize-conflicting-sublist (conf-list old-name depth rename-buffer-fn get-buffer-fn) (when conf-list (if (or (cdr conf-list) ;; Check that the proposed name doesn't conflict with some ;; existing buffer. - (let ((buf (get-buffer old-name))) + (let ((buf (funcall get-buffer-fn old-name))) (and buf (not (eq buf (uniquify-item-buffer (car conf-list))))))) (when uniquify-possibly-resolvable (setq uniquify-possibly-resolvable nil @@ -443,10 +450,9 @@ uniquify-rationalize-conflicting-sublist (uniquify-item-base item) (uniquify-item-dirname item) depth))) - (uniquify-rationalize-a-list conf-list depth)) + (uniquify-rationalize-a-list conf-list depth rename-buffer-fn get-buffer-fn)) (unless (string= old-name "") - (uniquify-rename-buffer (car conf-list) old-name))))) - + (funcall rename-buffer-fn (car conf-list) old-name))))) (defun uniquify-rename-buffer (item newname) (let ((buffer (uniquify-item-buffer item))) @@ -456,6 +462,44 @@ uniquify-rename-buffer ;; Pass the `unique' arg, so the advice doesn't mark it as unmanaged. (rename-buffer newname t)))))) +(defvar-local uniquify--stateless-curname nil + "The current unique name of this buffer in `uniquify-get-unique-names'.") + +(defun uniquify-get-unique-names (buffers) + "Return an alist with a unique name for each buffer in BUFFERS. + +The names are unique only among BUFFERS, and may conflict with other +buffers not in that list. + +This does not rename the buffers or change any state; the unique name is +only present in the returned alist." + (let ((buffer-names (make-hash-table :size (length buffers) :test 'equal)) + fix-lists-by-base) + (dolist (buf buffers) + (with-current-buffer buf + (setq uniquify--stateless-curname (buffer-name buf)) + (puthash (buffer-name buf) buf buffer-names) + (when uniquify-managed + (let ((base (uniquify-item-base (car uniquify-managed)))) + (push + (uniquify-make-item base (uniquify-buffer-file-name buf) buf nil) + (alist-get base fix-lists-by-base nil nil #'equal)))))) + (dolist (pair fix-lists-by-base) + (uniquify-rationalize--generic + (cdr pair) + (lambda (item name) ; rename-buffer + (with-current-buffer (uniquify-item-buffer item) + (remhash uniquify--stateless-curname buffer-names) + (setq uniquify--stateless-curname name) + (puthash name (current-buffer) buffer-names))) + (lambda (name) ; get-buffer + (gethash name buffer-names))))) + (mapcar (lambda (buf) + (with-current-buffer buf + (prog1 (cons uniquify--stateless-curname buf) + (kill-local-variable 'uniquify--stateless-curname)))) + buffers)) + ;;; Hooks from the rest of Emacs (defun uniquify-maybe-rerationalize-w/o-cb () -- 2.39.3 --=-=-=-- From unknown Sun Jun 15 08:44:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#77312: [PATCH] Add uniquify-get-unique-names Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 31 Mar 2025 19:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 77312 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Spencer Baugh , 77312@debbugs.gnu.org Received: via spool by 77312-submit@debbugs.gnu.org id=B77312.174345111221653 (code B ref 77312); Mon, 31 Mar 2025 19:59:02 +0000 Received: (at 77312) by debbugs.gnu.org; 31 Mar 2025 19:58:32 +0000 Received: from localhost ([127.0.0.1]:42982 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tzLHD-0005d8-Bs for submit@debbugs.gnu.org; Mon, 31 Mar 2025 15:58:31 -0400 Received: from fhigh-b5-smtp.messagingengine.com ([202.12.124.156]:40079) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tzLHA-0005cJ-3R for 77312@debbugs.gnu.org; Mon, 31 Mar 2025 15:58:29 -0400 Received: from phl-compute-05.internal (phl-compute-05.phl.internal [10.202.2.45]) by mailfhigh.stl.internal (Postfix) with ESMTP id A407825401DD; Mon, 31 Mar 2025 15:58:22 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Mon, 31 Mar 2025 15:58:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1743451102; x=1743537502; bh=gkHdxZF9eb hd29fiYtgl7tLIHFMyyTUjCVbGKtX1hzE=; b=HbxV/IOO0NVKMti70WoXvKyUUO WwmnE7AR/ei66xTD6N3PyGSwJoFLbJDJCpfNBlA7dDnipthEfN8ZrzjrGeQW3Ui+ 0vcESonjZLmd1TpsrA6oHdFAoI0uv8RbM2u1XO7+Zut8IlCc/2CMnDx457pLouO7 oJ/eHkVT7fT6Jqo1/D63ME/iOifBzPlKZ7IeGJEQ5mW2/jI8e0IIsFUwhhYJdFDb 16HeHm6C3R4pjNnwU/OHBeg7msYfIvv7fD4edN8nIGiN8o2SxtZ5gSx66BPv+8DL JQsjH0sI5F4tXaeNSQ21lmd3EPaR4d5/XT1DRBoVmi9N5s1KY228HsSrWmuA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1743451102; x=1743537502; bh=gkHdxZF9ebhd29fiYtgl7tLIHFMyyTUjCVb GKtX1hzE=; b=ZxvD9trTlFRy7jRRZndsDRDAXL+DSwjazbp0n+qFNY/hqkQ8Y6P Mz/PEoB0yIkntQTKUaiMyJj58cYM4U3YnUtDIPS/gVkKZi/XzLOP/V5MTzFboLI2 6ixBLQw74MjQjGc1tHqBF0OwiFQtfh5ZG6ACNbjEUOlKMykYh+jHNnZ/W119FgbW qtuWZeYZwufUi2DpfSkANBibTWeTnoBWXA0lHgBMttrKiX+UUiMvP/9/xT2PxE2/ uujRHJ9tQgXqFjtHS6M8qA1V4GOqr43bol2d6TEYXlve4YX9yxxgyYORMjv89Heo kFE9xCdkziSQ9uIDyc5IQbw6WkCqTKZ0FzQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddukedtkedvucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurheptgfkffggfgfuvfhfhfgjsehmtderredtvdej necuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdrug gvvheqnecuggftrfgrthhtvghrnhepkefhieejheehjefhhefhuddvteettedvgeelteei geelueegheffueffleduvdffnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphhtthho pedvpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehssggruhhghhesjhgrnhgvsh htrhgvvghtrdgtohhmpdhrtghpthhtohepjeejfeduvdesuggvsggsuhhgshdrghhnuhdr ohhrgh X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 31 Mar 2025 15:58:21 -0400 (EDT) Content-Type: multipart/mixed; boundary="------------ZzhO5q6RjgBdZ1GLZSf4Yxaf" Message-ID: Date: Mon, 31 Mar 2025 22:58:19 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: Content-Language: en-US From: Dmitry Gutov In-Reply-To: X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) This is a multi-part message in MIME format. --------------ZzhO5q6RjgBdZ1GLZSf4Yxaf Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi all, On 28/03/2025 20:50, Spencer Baugh wrote: > After some use, it seems better to return an alist rather than a hash > table from this function; that alist is in the same order as the buffer > list that was passed in, which is nice for completion. So here's a > version which does that. Here's the corresponding patch to project.el to use the new function. The use of new logic is predicated on the non-nil value of uniquify-buffer-name-style. The latter doesn't necessarily imply that the user wants the former, but seems a safe enough bet. --------------ZzhO5q6RjgBdZ1GLZSf4Yxaf Content-Type: text/x-patch; charset=UTF-8; name="project--read-project-buffer-reuniquify.diff" Content-Disposition: attachment; filename="project--read-project-buffer-reuniquify.diff" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL2xpc3AvcHJvZ21vZGVzL3Byb2plY3QuZWwgYi9saXNwL3Byb2dtb2Rl cy9wcm9qZWN0LmVsCmluZGV4IGQ5NTRiNzhhNzQ1Li4wMjBkZWI0MzVmOCAxMDA2NDQKLS0t IGEvbGlzcC9wcm9nbW9kZXMvcHJvamVjdC5lbAorKysgYi9saXNwL3Byb2dtb2Rlcy9wcm9q ZWN0LmVsCkBAIC0xNTYyLDEzICsxNTYyLDI3IEBAIHByb2plY3QtLXJlYWQtcHJvamVjdC1i dWZmZXIKICAgICAgICAgICAgIChhbmQgKG1lbXEgKGNkciBidWZmZXIpIGJ1ZmZlcnMpCiAg ICAgICAgICAgICAgICAgIChub3QKICAgICAgICAgICAgICAgICAgIChwcm9qZWN0LS1idWZm ZXItY2hlY2sKLSAgICAgICAgICAgICAgICAgICAoY2RyIGJ1ZmZlcikgcHJvamVjdC1pZ25v cmUtYnVmZmVyLWNvbmRpdGlvbnMpKSkpKQotICAgICAgICAgKGJ1ZmZlciAocmVhZC1idWZm ZXIKLSAgICAgICAgICAgICAgICAgICJTd2l0Y2ggdG8gYnVmZmVyOiAiCi0gICAgICAgICAg ICAgICAgICAod2hlbiAoZnVuY2FsbCBwcmVkaWNhdGUgKGNvbnMgb3RoZXItbmFtZSBvdGhl ci1idWZmZXIpKQotICAgICAgICAgICAgICAgICAgICBvdGhlci1uYW1lKQotICAgICAgICAg ICAgICAgICAgbmlsCi0gICAgICAgICAgICAgICAgICBwcmVkaWNhdGUpKSkKKyAgICAgICAg ICAgICAgICAgICBidWZmZXIgcHJvamVjdC1pZ25vcmUtYnVmZmVyLWNvbmRpdGlvbnMpKSkp KQorICAgICAgICAgKGJ1ZmZlcgorICAgICAgICAgIChpZiB1bmlxdWlmeS1idWZmZXItbmFt ZS1zdHlsZQorICAgICAgICAgICAgICA7OyBGb3JnbyB0aGUgdXNlIG9mIGBidWZmZXItcmVh ZC1mdW5jdGlvbicgKG9mdGVuIG5pbCkgaW4KKyAgICAgICAgICAgICAgOzsgZmF2b3Igb2Yg dW5pcXVpZnlpbmcgdGhlIGJ1ZmZlcnMgYmV0dGVyLgorICAgICAgICAgICAgICAobGV0KiAo KHVuaXF1ZS1uYW1lcyAodW5pcXVpZnktZ2V0LXVuaXF1ZS1uYW1lcyBidWZmZXJzKSkKKyAg ICAgICAgICAgICAgICAgICAgIChvdGhlci1uYW1lICh3aGVuIChmdW5jYWxsIHByZWRpY2F0 ZSAoY29ucyBvdGhlci1uYW1lIG90aGVyLWJ1ZmZlcikpCisgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIChjYXIgKHJhc3NvYyBvdGhlci1idWZmZXIgdW5pcXVlLW5hbWVz KSkpKQorICAgICAgICAgICAgICAgICAgICAgKHJlc3VsdCAoY29tcGxldGluZy1yZWFkCisg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiU3dpdGNoIHRvIGJ1ZmZlcjogIgorICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5pcXVlLW5hbWVzCisgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBwcmVkaWNhdGUKKyAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIG5pbCBuaWwgbmlsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvdGhlci1u YW1lKSkpCisgICAgICAgICAgICAgICAgKGFzc29jLWRlZmF1bHQgcmVzdWx0IHVuaXF1ZS1u YW1lcyAjJ2VxdWFsIHJlc3VsdCkpCisgICAgICAgICAgICAocmVhZC1idWZmZXIKKyAgICAg ICAgICAgICAiU3dpdGNoIHRvIGJ1ZmZlcjogIgorICAgICAgICAgICAgICh3aGVuIChmdW5j YWxsIHByZWRpY2F0ZSAoY29ucyBvdGhlci1uYW1lIG90aGVyLWJ1ZmZlcikpCisgICAgICAg ICAgICAgICBvdGhlci1uYW1lKQorICAgICAgICAgICAgIG5pbAorICAgICAgICAgICAgIHBy ZWRpY2F0ZSkpKSkKICAgICA7OyBYWFg6IFRoaXMgY2hlY2sgaGFyZGNvZGVzIHRoZSBkZWZh dWx0IGJ1ZmZlci1iZWxvbmdpbmcgcmVsYXRpb24KICAgICA7OyB3aGljaCBgcHJvamVjdC1i dWZmZXJzJyBpcyBhbGxvd2VkIHRvIG92ZXJyaWRlLiAgU3RyYWlnaHRlbgogICAgIDs7IHRo aXMgdXAgc29tZXRpbWUgbGF0ZXIuICBPciBub3QuICBTaW5jZSB3ZSBjYW4gYWRkIGEgbWV0 aG9kCg== --------------ZzhO5q6RjgBdZ1GLZSf4Yxaf-- From unknown Sun Jun 15 08:44:16 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Spencer Baugh Subject: bug#77312: closed (Re: bug#77312: [PATCH] Add uniquify-get-unique-names) Message-ID: References: <5919de07-9849-4257-b448-af45f46b3181@gutov.dev> X-Gnu-PR-Message: they-closed 77312 X-Gnu-PR-Package: emacs X-Gnu-PR-Keywords: patch Reply-To: 77312@debbugs.gnu.org Date: Fri, 06 Jun 2025 02:46:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1749177962-24865-1" This is a multi-part message in MIME format... ------------=_1749177962-24865-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #77312: [PATCH] Add uniquify-get-unique-names which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 77312@debbugs.gnu.org. --=20 77312: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D77312 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1749177962-24865-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 77312-done) by debbugs.gnu.org; 6 Jun 2025 02:45:35 +0000 Received: from localhost ([127.0.0.1]:40187 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uNN5L-0006Ri-3O for submit@debbugs.gnu.org; Thu, 05 Jun 2025 22:45:35 -0400 Received: from fout-b8-smtp.messagingengine.com ([202.12.124.151]:51169) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uNN5H-0006RE-SP for 77312-done@debbugs.gnu.org; Thu, 05 Jun 2025 22:45:32 -0400 Received: from phl-compute-03.internal (phl-compute-03.phl.internal [10.202.2.43]) by mailfout.stl.internal (Postfix) with ESMTP id 76AB21140154; Thu, 5 Jun 2025 22:45:25 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-03.internal (MEProxy); Thu, 05 Jun 2025 22:45:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1749177925; x=1749264325; bh=GnThgPayWp1mXIQ2v9NhD3t9EUJdv7E2GIexgtg7yMY=; b= SBoBYQwcJIn8lAF1u4JfmpAeD/fTeQRd09I1kEfkbBfM73JDsAox+DZXfuw3SsKd awmLsENixqPSnw9NJKgNVIix8ezSoGef/P31RX7q50i3KE58sVeC4uoreJjwN3od 58La2FfMt1RrEIpjm/vkSq0IVawfwD7x7I6l8XUZMxZoBO1YXqUtr8Rrq6unViAv OwTl1PWRgfNwuphC2jRzb/h5Y7YCYEMzlHRImq+EQVDc3uzAUTOkUzsi/SpiQ8PJ qtJOcmllLAm8fMPJrGTNuYww5yyPSTXD++b6ZvklIdo7CWVZRm+JiHGjaqgvcSpP RDfIbS7YzMBZK56Dozh52A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; t=1749177925; x=1749264325; bh=G nThgPayWp1mXIQ2v9NhD3t9EUJdv7E2GIexgtg7yMY=; b=jBoJPHuhy5oPi7Vbm KA/EXO2qzLD80mk1pZr4TDFa1heKMDpqvYul47bFigYKyGktoGbbQSI65YbNa61Z 8kCHN+8rRNjTt9M9YGO45PCpExaRL6r1kW52FiQ6UcJ0ywQJL6mbPckRBz79+zgy +2ncccosSelfPiMZu706q1wx3zv5t1v1puGyzBkKImdSM1pmdF0toPVakS5CYxt0 /1gD9FEb1n/FaM/3ZqBWpffDpkV239F0KR0VNRdVfPuPpscH6SKbsRCGepuVwNMW A6MpfP+Nnp+baBzVqDb4gBtz7X3LbvFVHqASd8qwLAWCBYukOYDL59JxbqdIGS3k E7Ekg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugdeggeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhepkfffgggfuffhvfhfjggtgfesthejredttddvjeen ucfhrhhomhepffhmihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvg hvqeenucggtffrrghtthgvrhhnpefgieetieduhfefgeegveekfeevfeevjedtleejgeei vdevudefvedtkeegiedvleenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvhdpnhgspghrtghpthhtohep vddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepshgsrghughhhsehjrghnvghsth hrvggvthdrtghomhdprhgtphhtthhopeejjeefuddvqdguohhnvgesuggvsggsuhhgshdr ghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 5 Jun 2025 22:45:24 -0400 (EDT) Message-ID: <5919de07-9849-4257-b448-af45f46b3181@gutov.dev> Date: Fri, 6 Jun 2025 05:45:22 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#77312: [PATCH] Add uniquify-get-unique-names From: Dmitry Gutov To: Spencer Baugh , 77312-done@debbugs.gnu.org References: Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 77312-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 31/03/2025 22:58, Dmitry Gutov wrote: > Here's the corresponding patch to project.el to use the new function. > > The use of new logic is predicated on the non-nil value of uniquify- > buffer-name-style. The latter doesn't necessarily imply that the user > wants the former, but seems a safe enough bet. No further comments from anybody, so I've pushed the two patches and am closing the bug. If anybody dislikes the change in project-switch-to-buffer's behavior, let me know. ------------=_1749177962-24865-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 27 Mar 2025 15:03:35 +0000 Received: from localhost ([127.0.0.1]:50818 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1txolY-0005bN-6r for submit@debbugs.gnu.org; Thu, 27 Mar 2025 11:03:35 -0400 Received: from lists.gnu.org ([2001:470:142::17]:36430) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1txolU-0005Zm-H1 for submit@debbugs.gnu.org; Thu, 27 Mar 2025 11:03:31 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1txolP-0001bx-03 for bug-gnu-emacs@gnu.org; Thu, 27 Mar 2025 11:03:23 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1txolM-0001Te-4i for bug-gnu-emacs@gnu.org; Thu, 27 Mar 2025 11:03:22 -0400 From: Spencer Baugh To: bug-gnu-emacs@gnu.org Subject: [PATCH] Add uniquify-get-unique-names X-Debbugs-Cc: dmitry@gutov.dev Date: Thu, 27 Mar 2025 11:03:17 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1743087797; bh=C2bQrXJNDsdEnC7XcH/9zbP5u1wSdXxQYMo9Gr77Cfw=; h=From:To:Subject:Date; b=ZOpHNvybOU2MdPIQN4zVlP7RDfwFfvdU6BpY0oHXSIsK65GSDctTfCLuSVl6Q9OLe r6F1Vvt/LrEQD2ID+ezzSRV+KeogDtoMGYwd8pv5DKDTisaKx/cujMyC1t0qtsjy19 TX3OdJlJ6UcjTJG1LPck1YyXIoP4beVJ+JpNrQrl6vRRzju3Tt4zYqjTa82Bcfg98q ujbY5M4eusWn48+lpLWK97rj1EVx+vzDKSaQphkVSmk+Pg/cd+G8fG+XMXYf/lEiEH dOoDG/HFpKaZVMc+2vfeTPKXtACYWgumzYJ4cQM6uleMQ8WbFqLXBoMZXsGKi+UIKw /cFJTu6TE2wYg== Received-SPF: pass client-ip=64.215.233.18; envelope-from=sbaugh@janestreet.com; helo=mxout5.mail.janestreet.com X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) --=-=-= Content-Type: text/plain Tags: patch This new function provides an interface to uniquify.el which doesn't change the actual names of the buffers. This is useful for any commands which deal with a subset of all buffers; for example, project.el. * lisp/uniquify.el (uniquify-rationalize--generic): Add. (uniquify-rationalize, uniquify-rationalize-a-list) (uniquify-rationalize-conflicting-sublist): Explicitly pass RENAME-BUFFER-FN and GET-BUFFER-FN. (uniquify--stateless-curname, uniquify-get-unique-names): Add. In GNU Emacs 30.1.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.15.12, Xaw scroll bars) of 2025-03-11 built on igm-qws-u22796a Repository revision: 516d1e6463a9659951f7567e038efc5ee2a19bbf Windowing system distributor 'The X.Org Foundation', version 11.0.12011000 System Description: Rocky Linux 8.10 (Green Obsidian) Configured using: 'configure --config-cache --with-x-toolkit=lucid --without-gpm --without-gconf --without-selinux --without-imagemagick --with-modules --with-gif=no --with-cairo --with-rsvg --without-compress-install --with-tree-sitter --with-native-compilation=aot --prefix=/usr/local/home/garnish/raw-emacs/30-20250311_131404' --=-=-= Content-Type: text/patch Content-Disposition: attachment; filename=0001-Add-uniquify-get-unique-names.patch >From afd867ef7577bab1cf83a62c5acaa1bfc5da6305 Mon Sep 17 00:00:00 2001 From: Spencer Baugh Date: Thu, 27 Mar 2025 09:32:47 -0400 Subject: [PATCH] Add uniquify-get-unique-names This new function provides an interface to uniquify.el which doesn't change the actual names of the buffers. This is useful for any commands which deal with a subset of all buffers; for example, project.el. * lisp/uniquify.el (uniquify-rationalize--generic): Add. (uniquify-rationalize, uniquify-rationalize-a-list) (uniquify-rationalize-conflicting-sublist): Explicitly pass RENAME-BUFFER-FN and GET-BUFFER-FN. (uniquify--stateless-curname, uniquify-get-unique-names): Add. --- lisp/uniquify.el | 65 ++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 54 insertions(+), 11 deletions(-) diff --git a/lisp/uniquify.el b/lisp/uniquify.el index 358ae6af651..50971e115b0 100644 --- a/lisp/uniquify.el +++ b/lisp/uniquify.el @@ -320,14 +320,19 @@ uniquify-rerationalize-w/o-cb (defun uniquify-rationalize (fix-list) ;; Set up uniquify to re-rationalize after killing/renaming ;; if there is a conflict. + (dolist (item fix-list) + (with-current-buffer (uniquify-item-buffer item) + (setq uniquify-managed fix-list))) + (uniquify-rationalize--generic fix-list #'uniquify-rename-buffer #'get-buffer)) + +(defun uniquify-rationalize--generic (fix-list rename-buffer-fn get-buffer-fn) (dolist (item fix-list) (with-current-buffer (uniquify-item-buffer item) ;; Refresh the dirnames and proposed names. (setf (uniquify-item-proposed item) (uniquify-get-proposed-name (uniquify-item-base item) (uniquify-item-dirname item) - nil)) - (setq uniquify-managed fix-list))) + nil)))) ;; Strip any shared last directory names of the dirname. (when (and (cdr fix-list) uniquify-strip-common-suffix) (let ((strip t)) @@ -353,13 +358,13 @@ uniquify-rationalize fix-list))))) ;; If uniquify-min-dir-content is 0, this will end up just ;; passing fix-list to uniquify-rationalize-conflicting-sublist. - (uniquify-rationalize-a-list fix-list)) + (uniquify-rationalize-a-list fix-list nil rename-buffer-fn get-buffer-fn)) (defun uniquify-item-greaterp (item1 item2) (string-lessp (uniquify-item-proposed item2) (uniquify-item-proposed item1))) -(defun uniquify-rationalize-a-list (fix-list &optional depth) +(defun uniquify-rationalize-a-list (fix-list depth rename-buffer-fn get-buffer-fn) (unless depth (setq depth uniquify-min-dir-content)) (let (conflicting-sublist ; all elements have the same proposed name (old-proposed "") @@ -370,12 +375,14 @@ uniquify-rationalize-a-list (setq proposed (uniquify-item-proposed item)) (unless (equal proposed old-proposed) (uniquify-rationalize-conflicting-sublist conflicting-sublist - old-proposed depth) + old-proposed depth + rename-buffer-fn get-buffer-fn) (setq conflicting-sublist nil)) (push item conflicting-sublist) (setq old-proposed proposed)) (uniquify-rationalize-conflicting-sublist conflicting-sublist - old-proposed depth))) + old-proposed depth + rename-buffer-fn get-buffer-fn))) (defun uniquify-get-proposed-name (base dirname &optional depth) (unless depth (setq depth uniquify-min-dir-content)) @@ -427,12 +434,12 @@ uniquify-get-proposed-name ;; Deal with conflicting-sublist, all of whose elements have identical ;; "base" components. -(defun uniquify-rationalize-conflicting-sublist (conf-list old-name depth) +(defun uniquify-rationalize-conflicting-sublist (conf-list old-name depth rename-buffer-fn get-buffer-fn) (when conf-list (if (or (cdr conf-list) ;; Check that the proposed name doesn't conflict with some ;; existing buffer. - (let ((buf (get-buffer old-name))) + (let ((buf (funcall get-buffer-fn old-name))) (and buf (not (eq buf (uniquify-item-buffer (car conf-list))))))) (when uniquify-possibly-resolvable (setq uniquify-possibly-resolvable nil @@ -443,10 +450,9 @@ uniquify-rationalize-conflicting-sublist (uniquify-item-base item) (uniquify-item-dirname item) depth))) - (uniquify-rationalize-a-list conf-list depth)) + (uniquify-rationalize-a-list conf-list depth rename-buffer-fn get-buffer-fn)) (unless (string= old-name "") - (uniquify-rename-buffer (car conf-list) old-name))))) - + (funcall rename-buffer-fn (car conf-list) old-name))))) (defun uniquify-rename-buffer (item newname) (let ((buffer (uniquify-item-buffer item))) @@ -456,6 +462,43 @@ uniquify-rename-buffer ;; Pass the `unique' arg, so the advice doesn't mark it as unmanaged. (rename-buffer newname t)))))) +(defvar-local uniquify--stateless-curname nil + "The current unique name of this buffer in `uniquify-get-unique-names'.") + +(defun uniquify-get-unique-names (buffers) + "Return a hash table with a unique name for each buffer in BUFFERS. + +The names are unique only among BUFFERS, and may conflict with other +buffers not in that list. + +This does not rename the buffers or change any state; the unique name is +only present in the returned alist." + (let ((buffer-names (make-hash-table :size (length buffers) :test 'equal))) + (let (fix-lists-by-base) + (dolist (buf buffers) + (with-current-buffer buf + (setq uniquify--stateless-curname (buffer-name buf)) + (puthash (buffer-name buf) buf buffer-names) + (when uniquify-managed + (let ((base (uniquify-item-base (car uniquify-managed)))) + (push + (uniquify-make-item base (uniquify-buffer-file-name buf) buf nil) + (alist-get base fix-lists-by-base nil nil #'equal)))))) + (dolist (pair fix-lists-by-base) + (uniquify-rationalize--generic + (cdr pair) + (lambda (item name) ; rename-buffer + (with-current-buffer (uniquify-item-buffer item) + (remhash uniquify--stateless-curname buffer-names) + (setq uniquify--stateless-curname name) + (puthash name (current-buffer) buffer-names))) + (lambda (name) ; get-buffer + (gethash name buffer-names))))) + (dolist (buf buffers) + (with-current-buffer buf + (kill-local-variable 'uniquify--stateless-curname))) + buffer-names)) + ;;; Hooks from the rest of Emacs (defun uniquify-maybe-rerationalize-w/o-cb () -- 2.39.3 --=-=-=-- ------------=_1749177962-24865-1-- From unknown Sun Jun 15 08:44:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#77312: [PATCH] Add uniquify-get-unique-names Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 07 Jun 2025 08:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 77312 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: 77312@debbugs.gnu.org Cc: dmitry@gutov.dev, sbaugh@janestreet.com Received: via spool by 77312-submit@debbugs.gnu.org id=B77312.174928391315845 (code B ref 77312); Sat, 07 Jun 2025 08:12:01 +0000 Received: (at 77312) by debbugs.gnu.org; 7 Jun 2025 08:11:53 +0000 Received: from localhost ([127.0.0.1]:46666 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uNoef-00047V-Dm for submit@debbugs.gnu.org; Sat, 07 Jun 2025 04:11:53 -0400 Received: from server.qxqx.de ([2a01:4f8:c012:9177::1]:43147 helo=mail.qxqx.de) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uNoec-000478-D1 for 77312@debbugs.gnu.org; Sat, 07 Jun 2025 04:11:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daniel-mendler.de; s=key; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=vyFCT245TbkkokpRqPYjHzmTFCUuaDB551w9BR/qXXA=; b=LCcLDwgUEuz37tloTqagQOkKSZ zeO9ckp3/Ztg/PDfO8VSTPOgwpdj9yBKshWUpBDoqfA1kMkMAEHlpMSIKToGelw0ugpRzgPoQb9lL WSDmzdhPSAZGUeSYckRvsKTeTlmRq9aH2mtHJgBYZtUXkMGQ29nTGlbo16wEOciSMzY8=; From: Daniel Mendler In-Reply-To: <5919de07-9849-4257-b448-af45f46b3181@gutov.dev> References: <5919de07-9849-4257-b448-af45f46b3181@gutov.dev> Date: Sat, 07 Jun 2025 10:11:42 +0200 Message-ID: <87jz5o9dj5.fsf@daniel-mendler.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Hello Dmitry! Dmitry Gutov writes: > On 31/03/2025 22:58, Dmitry Gutov wrote: >> Here's the corresponding patch to project.el to use the new function. >> The use of new logic is predicated on the non-nil value of uniquify- >> buffer-name-style. The latter doesn't necessarily imply that the user wants >> the former, but seems a safe enough bet. > > No further comments from anybody, so I've pushed the two patches and am closing > the bug. > > If anybody dislikes the change in project-switch-to-buffer's behavior, let me > know. Would it be possible to attach the buffer object or the original buffer name to the completion candidate string as text property? This would make it possible to attach annotations via Marginalia or to execute buffer actions via Embark. Otherwise I don't see a possibility to access the original buffer, since they are only present in the `unique-names` alist local variable. Daniel From unknown Sun Jun 15 08:44:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#77312: [PATCH] Add uniquify-get-unique-names Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 08 Jun 2025 02:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 77312 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Daniel Mendler , 77312@debbugs.gnu.org Cc: sbaugh@janestreet.com Received: via spool by 77312-submit@debbugs.gnu.org id=B77312.174934841527647 (code B ref 77312); Sun, 08 Jun 2025 02:07:02 +0000 Received: (at 77312) by debbugs.gnu.org; 8 Jun 2025 02:06:55 +0000 Received: from localhost ([127.0.0.1]:50176 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uO5R0-0007Br-Qh for submit@debbugs.gnu.org; Sat, 07 Jun 2025 22:06:55 -0400 Received: from fout-a8-smtp.messagingengine.com ([103.168.172.151]:35819) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uO5Qs-0007BV-TI for 77312@debbugs.gnu.org; Sat, 07 Jun 2025 22:06:51 -0400 Received: from phl-compute-01.internal (phl-compute-01.phl.internal [10.202.2.41]) by mailfout.phl.internal (Postfix) with ESMTP id 492D5138013A; Sat, 7 Jun 2025 22:06:41 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-01.internal (MEProxy); Sat, 07 Jun 2025 22:06:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1749348401; x=1749434801; bh=gOADxLSs7QCCurTNSruUGQOySfoVES/5kNuxZVC13zg=; b= cDZ8319gZ4VCq6wWuOwjmRpRulu+sVEVeN98v0EcAQ087hxaYyV/gfRF01qQtUrh Qb2//SV5cgTZ+rf9sw82wZCxOw/V2+9ST+W1rMt8a2YByeC3nC6aRzv9rLSALbDi YAT+TgOcF/9B1AefPADKvVkaPL7XGaxOeyBLrkN9DPbyOA0T+Zmmovt28pxssNMf 2fFy/B3SAi0mHx3L/RyNpjOyk+yCVyY4w0zk8R9jpv5sh25cZylI9GF4eMCKbMir 4qT9AL5BrIMKsyKW+kVWOYGmj/faQaT6vu6gYa4sVnwiTYWfgEOA8aIcZc3Ax19u cd1qsAvmRlQyzosaYcKfnA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1749348401; x= 1749434801; bh=gOADxLSs7QCCurTNSruUGQOySfoVES/5kNuxZVC13zg=; b=Y xfRlCpBELrHs2Sb93h+Fv1LN1/prdIthHLICfoCbONJRoSTmDbyEUIrEJhzHxYff R3RBF7VsiaUGmMAp5P/FglmoGBCzFAgRGlDq/ioGxuBwgYJ8BI4/Z+yOY33MAs53 5vXJExnCh4XyrTTyjcamz70A51PL2q8imDGedII7n7rvDeLcNtOL1PtepxeLLv0X OtdEK/rpDyYsglmxHiby8Q42fcC4TsEPOIQfvg4t+sveMGhGzbfwl2ycWC/LXSJS NVibj/cQXIk1PaQdrkE7reS7xCPeebHWvGcP+ghbRV5AGAIlXw5UOxh1dWW7Wz9P Wpy3QGIaXaz2BUoWUD01g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugdejfeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefkffggfg fuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhmihhtrhihucfiuhhtohhv uceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtthgvrhhnpeetudelje egheetgfehgeejkeeuhedvveeikeeufedtvddtveefhfdvveegudejheenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumhhithhrhiesghhuth hovhdruggvvhdpnhgspghrtghpthhtohepfedpmhhouggvpehsmhhtphhouhhtpdhrtghp thhtohepmhgrihhlsegurghnihgvlhdqmhgvnhgulhgvrhdruggvpdhrtghpthhtohepje ejfeduvdesuggvsggsuhhgshdrghhnuhdrohhrghdprhgtphhtthhopehssggruhhghhes jhgrnhgvshhtrhgvvghtrdgtohhm X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 7 Jun 2025 22:06:39 -0400 (EDT) Message-ID: <851a4f79-6789-4f60-9952-2f896b9ee187@gutov.dev> Date: Sun, 8 Jun 2025 05:06:36 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: <5919de07-9849-4257-b448-af45f46b3181@gutov.dev> <87jz5o9dj5.fsf@daniel-mendler.de> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <87jz5o9dj5.fsf@daniel-mendler.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Hey Daniel! On 07/06/2025 11:11, Daniel Mendler wrote: > Would it be possible to attach the buffer object or the original buffer > name to the completion candidate string as text property? This would > make it possible to attach annotations via Marginalia or to execute > buffer actions via Embark. Otherwise I don't see a possibility to access > the original buffer, since they are only present in the `unique-names` > alist local variable. That makes sense. Just call the property 'buffer'? I wonder if it would make sense to alter the calling convention for uniquify-get-unique-names itself to return a list of propertized strings instead. project--read-project-buffer can do the conversion (copy each string and attach the property), but it's just extra consing. Unless some more new callers are going to prefer the current convention. From unknown Sun Jun 15 08:44:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#77312: [PATCH] Add uniquify-get-unique-names Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 08 Jun 2025 05:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 77312 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Dmitry Gutov Cc: sbaugh@janestreet.com, 77312@debbugs.gnu.org Received: via spool by 77312-submit@debbugs.gnu.org id=B77312.17493612912602 (code B ref 77312); Sun, 08 Jun 2025 05:42:01 +0000 Received: (at 77312) by debbugs.gnu.org; 8 Jun 2025 05:41:31 +0000 Received: from localhost ([127.0.0.1]:50440 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uO8mh-0000fu-2H for submit@debbugs.gnu.org; Sun, 08 Jun 2025 01:41:31 -0400 Received: from server.qxqx.de ([2a01:4f8:c012:9177::1]:49797 helo=mail.qxqx.de) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uO8me-0000fZ-Bp for 77312@debbugs.gnu.org; Sun, 08 Jun 2025 01:41:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daniel-mendler.de; s=key; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=IYp8Wlykf9ZCyOBZWmXRObtgCJi0oPQtPRPcu6FGG3c=; b=HPZyKSNU3S2fHJ8ZKwJRyz0yoV SjTfesxqGkJzrtwr6kVVIVPfhnCxb1fuk7bbpYC5WcFQfd3UEwBIoltWeEH7xFrNmWy/CIKUSuCMO bUPst0QA2J0azttOWgT9i9UuV3iWTcu0BIP9Z7saDBe07wSCpPo33lPNGxF51W0y6Ay8=; From: Daniel Mendler In-Reply-To: <851a4f79-6789-4f60-9952-2f896b9ee187@gutov.dev> References: <5919de07-9849-4257-b448-af45f46b3181@gutov.dev> <87jz5o9dj5.fsf@daniel-mendler.de> <851a4f79-6789-4f60-9952-2f896b9ee187@gutov.dev> Date: Sun, 08 Jun 2025 07:41:19 +0200 Message-ID: <87ikl6yem8.fsf@daniel-mendler.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Dmitry Gutov writes: > Hey Daniel! > > On 07/06/2025 11:11, Daniel Mendler wrote: >> Would it be possible to attach the buffer object or the original buffer >> name to the completion candidate string as text property? This would >> make it possible to attach annotations via Marginalia or to execute >> buffer actions via Embark. Otherwise I don't see a possibility to access >> the original buffer, since they are only present in the `unique-names` >> alist local variable. > > That makes sense. Just call the property 'buffer'? That would work. I prefer a more specific property name to ease grepping/debugging. Also see below regarding the consing. > I wonder if it would make sense to alter the calling convention for > uniquify-get-unique-names itself to return a list of propertized strings > instead. project--read-project-buffer can do the conversion (copy each string > and attach the property), but it's just extra consing. I haven't checked if the current function is already working hard to avoid unnecessary allocations. If yes, it would be wasteful to add extra string allocations. In order to avoid them, we could only attach the property if the buffer name has really changed, such that no strings have to be copied. The property could be called `uniquify-orig-buffer-name`. If the property is present, it holds the original buffer name, if it is not present the string itself is the original buffer name. > Unless some more new callers are going to prefer the current convention. Both would be fine for me. Generally I think it is nice to push functionality to the lower level API, as long as the functionality is generic enough. Btw, would you be interested in having `uniquify-get-unique-names' in Compat, such that you avoid the fboundp check? project.el would have to depend on Compat for that, but that's essentially free on Emacs 30 and newer. Daniel From unknown Sun Jun 15 08:44:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#77312: [PATCH] Add uniquify-get-unique-names Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Jun 2025 02:52:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 77312 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Daniel Mendler Cc: sbaugh@janestreet.com, 77312@debbugs.gnu.org Received: via spool by 77312-submit@debbugs.gnu.org id=B77312.174952390812200 (code B ref 77312); Tue, 10 Jun 2025 02:52:03 +0000 Received: (at 77312) by debbugs.gnu.org; 10 Jun 2025 02:51:48 +0000 Received: from localhost ([127.0.0.1]:59624 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uOp5V-0003AM-MT for submit@debbugs.gnu.org; Mon, 09 Jun 2025 22:51:48 -0400 Received: from fout-b3-smtp.messagingengine.com ([202.12.124.146]:34373) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uOp5R-00038X-Ir for 77312@debbugs.gnu.org; Mon, 09 Jun 2025 22:51:43 -0400 Received: from phl-compute-03.internal (phl-compute-03.phl.internal [10.202.2.43]) by mailfout.stl.internal (Postfix) with ESMTP id 524661140173; Mon, 9 Jun 2025 22:51:35 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-03.internal (MEProxy); Mon, 09 Jun 2025 22:51:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1749523895; x=1749610295; bh=oG9IYhoEhO49Rqv+elbKRjEkJhIeKAyvR4sb7nM4A1I=; b= QbPUKUBpJKmhpG/Hw/tN7am0MoWerlRegsw9D418yORv9rXrX69xff0t6fh3eX0/ CowulyIKKm4YFm5WGP9hsMwr2eioPkFi7LRRchlErsGY/CnK760MMwu2g2glOCaQ aQRHRRUzy8IcNRY+5u5eXsUB6YKIKGp5sxx3cfL9cSFMyGX0XORQ7EdIVWxgMnoR VfuOa3ffkS9gv8I5mfpu6kzU6Uc8cDevHuLMN296Z1SBVBhZIGU5wnZ4w3sLLZMz 5XmLTyshjc/DO23GIkW46OWllk6Ri0hSxiQEaG2Ad2Y5ocH/3ERLynfcxK33aUWo +66q8MPKhB2hw4zbBH4gQQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1749523895; x= 1749610295; bh=oG9IYhoEhO49Rqv+elbKRjEkJhIeKAyvR4sb7nM4A1I=; b=e InY+FBRC/Ng73sF0WW27yxBzWzvO1xxySxlygzntDR28EpB3jGLj7ctXXvhnw7eJ t+CqMt/1f8nEcSDFDHgiATMuef0KUte92dsc02ov4sgP2elT4orrROKhw8ldiqWH R5lvMb5VO3UfFIx2o/2Ka9Lv5WwXbnb8l7nYWn1Cp74uH876skJd43YL/x5av612 XtZ92Htjmusvw1Uh8lPzCeVlkqMPJ7h94fbpBJlFE4FEGFCt3cSxG+4uLyl0yjR7 kTuDoUgh6bshQB72TK07zoGEpaycM3KK9lLZPDaBkNZwEa4JZuxyEUdQ1t72Qht+ V4q94oubiRVG3ifCJN5yg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugddutdduhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecunecujfgurhepkfffgg gfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhithhrhicuifhuthho vhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrthhtvghrnheptedule ejgeehtefgheegjeekueehvdevieekueeftddvtdevfefhvdevgedujeehnecuvehluhhs thgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughmihhtrhihsehguh htohhvrdguvghvpdhnsggprhgtphhtthhopeefpdhmohguvgepshhmthhpohhuthdprhgt phhtthhopehmrghilhesuggrnhhivghlqdhmvghnughlvghrrdguvgdprhgtphhtthhope ejjeefuddvseguvggssghughhsrdhgnhhurdhorhhgpdhrtghpthhtohepshgsrghughhh sehjrghnvghsthhrvggvthdrtghomh X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 9 Jun 2025 22:51:33 -0400 (EDT) Message-ID: <1ac34a13-b0be-4229-a0ac-a9b6507dcfd0@gutov.dev> Date: Tue, 10 Jun 2025 05:51:29 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: <5919de07-9849-4257-b448-af45f46b3181@gutov.dev> <87jz5o9dj5.fsf@daniel-mendler.de> <851a4f79-6789-4f60-9952-2f896b9ee187@gutov.dev> <87ikl6yem8.fsf@daniel-mendler.de> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <87ikl6yem8.fsf@daniel-mendler.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 08/06/2025 08:41, Daniel Mendler wrote: >> On 07/06/2025 11:11, Daniel Mendler wrote: >>> Would it be possible to attach the buffer object or the original buffer >>> name to the completion candidate string as text property? This would >>> make it possible to attach annotations via Marginalia or to execute >>> buffer actions via Embark. Otherwise I don't see a possibility to access >>> the original buffer, since they are only present in the `unique-names` >>> alist local variable. >> >> That makes sense. Just call the property 'buffer'? > > That would work. I prefer a more specific property name to ease > grepping/debugging. Also see below regarding the consing. All right. >> I wonder if it would make sense to alter the calling convention for >> uniquify-get-unique-names itself to return a list of propertized strings >> instead. project--read-project-buffer can do the conversion (copy each string >> and attach the property), but it's just extra consing. > > I haven't checked if the current function is already working hard to > avoid unnecessary allocations. If yes, it would be wasteful to add extra > string allocations. Also when you provide the same information via different ways, over time they tend to get out of sync. The simpler the better. > In order to avoid them, we could only attach the property if the buffer > name has really changed, such that no strings have to be copied. The > property could be called `uniquify-orig-buffer-name`. If the property is > present, it holds the original buffer name, if it is not present the > string itself is the original buffer name. Yeah, that's a good idea. > Btw, would you be interested in having `uniquify-get-unique-names' in > Compat, such that you avoid the fboundp check? project.el would have to > depend on Compat for that, but that's essentially free on Emacs 30 and > newer. I usually try to avoid extra deps, but this can make sense, at least for users of Emacs>30. Especially if it leads to simplification in multiple places. Can you see other compatibility checks we could forgo this way? Offhand, I see another fboundp in 'project-ignores' (default definition) and a version< inside 'project-list-buffers-buffer-menu'. From unknown Sun Jun 15 08:44:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#77312: [PATCH] Add uniquify-get-unique-names Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Jun 2025 03:15:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 77312 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Dmitry Gutov Cc: sbaugh@janestreet.com, 77312@debbugs.gnu.org Received: via spool by 77312-submit@debbugs.gnu.org id=B77312.174952528425982 (code B ref 77312); Tue, 10 Jun 2025 03:15:05 +0000 Received: (at 77312) by debbugs.gnu.org; 10 Jun 2025 03:14:44 +0000 Received: from localhost ([127.0.0.1]:59702 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uOpRg-0006ki-Uq for submit@debbugs.gnu.org; Mon, 09 Jun 2025 23:14:43 -0400 Received: from server.qxqx.de ([2a01:4f8:c012:9177::1]:39375 helo=mail.qxqx.de) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uOpRc-0006j5-VM for 77312@debbugs.gnu.org; Mon, 09 Jun 2025 23:14:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daniel-mendler.de; s=key; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=qg8cZM6YKywqwYu0Y83f/muPz27T0j5dDfux86bbpvQ=; b=uPEGRmFisPFFyTNkW/tM4HFAwR l7+jaeIzlcU3eIhoxJcwUI6J14bkmM+lykcjcR1+Hnk6InJKf2sD4UHy644dyALgOtV2eygNQ56+U TgeZBIw0Ct1ag9ggB9sngW6ZOJcegrnVYk7pi8P6oSnw2eWcewqtZ5/+bOfaNZPXV750=; From: Daniel Mendler In-Reply-To: <1ac34a13-b0be-4229-a0ac-a9b6507dcfd0@gutov.dev> References: <5919de07-9849-4257-b448-af45f46b3181@gutov.dev> <87jz5o9dj5.fsf@daniel-mendler.de> <851a4f79-6789-4f60-9952-2f896b9ee187@gutov.dev> <87ikl6yem8.fsf@daniel-mendler.de> <1ac34a13-b0be-4229-a0ac-a9b6507dcfd0@gutov.dev> Date: Tue, 10 Jun 2025 05:14:28 +0200 Message-ID: <87plfc70ff.fsf@daniel-mendler.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Dmitry Gutov writes: >> Btw, would you be interested in having `uniquify-get-unique-names' in >> Compat, such that you avoid the fboundp check? project.el would have to >> depend on Compat for that, but that's essentially free on Emacs 30 and >> newer. > > I usually try to avoid extra deps, but this can make sense, at least for users > of Emacs>30. Especially if it leads to simplification in multiple places. I also find it good to avoid extra deps, in particular if they introduce their own idioms. Compat doesn't invent functionality, it just provides some APIs from the latest stable Emacs versions, so it will help keeping your code up to date. Compat is made such that the dependency cost is minimized, since it is not installed if Emacs is sufficiently new. > Can you see other compatibility checks we could forgo this way? Offhand, I see > another fboundp in 'project-ignores' (default definition) and a version< inside > 'project-list-buffers-buffer-menu'. I think these checks cannot be avoided. But you could start using some new functions or macros like `defvar-keymap'. See the Compat manual for a list of backported functionality. Daniel From unknown Sun Jun 15 08:44:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#77312: [PATCH] Add uniquify-get-unique-names Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Jun 2025 15:06:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 77312 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Daniel Mendler Cc: Dmitry Gutov , 77312@debbugs.gnu.org Received: via spool by 77312-submit@debbugs.gnu.org id=B77312.17495679164550 (code B ref 77312); Tue, 10 Jun 2025 15:06:03 +0000 Received: (at 77312) by debbugs.gnu.org; 10 Jun 2025 15:05:16 +0000 Received: from localhost ([127.0.0.1]:39144 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uP0XL-0001B9-Ut for submit@debbugs.gnu.org; Tue, 10 Jun 2025 11:05:16 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:50057) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uP0XI-00019X-Ce for 77312@debbugs.gnu.org; Tue, 10 Jun 2025 11:05:13 -0400 From: Spencer Baugh In-Reply-To: <87ikl6yem8.fsf@daniel-mendler.de> (Daniel Mendler's message of "Sun, 08 Jun 2025 07:41:19 +0200") References: <5919de07-9849-4257-b448-af45f46b3181@gutov.dev> <87jz5o9dj5.fsf@daniel-mendler.de> <851a4f79-6789-4f60-9952-2f896b9ee187@gutov.dev> <87ikl6yem8.fsf@daniel-mendler.de> Date: Tue, 10 Jun 2025 11:05:06 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1749567906; bh=NQ2NnqzZo7g0MfD4fRH/23FOPpdiLNiqg1IALI+bIMM=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=U0rMU2ZiPUyApu7lKZTC8yG/uGL4jAQSMQv8InS9tYuREJQeDWbZFnidZrua6xGTF Ee8dhkKyD9mYbNm44o81Ws0JQLJsidf9Ai2XLgdSmT88gzUWQ9p4TWhudoTTElz14Q YG4VC4o6851aY+rF7jp4HjF77zk7EAmWJOm7hDDzbZeamF6yzN4qjVbj/eslP/TWsh NvFubBHXeNfbABFISBWVRtZk1+St8/H0QCCOjtXRWvauiDPKN3LWAukEg61cjziIfw INoahx6A0oOzXo1suXaydQVeoPs654DrjfXbveQn7FTOeqwp6ZiYCjHw8t8D/Ra34y TusfxzGWIyA9w== X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Daniel Mendler writes: > Dmitry Gutov writes: > >> Hey Daniel! >> >> On 07/06/2025 11:11, Daniel Mendler wrote: >>> Would it be possible to attach the buffer object or the original buffer >>> name to the completion candidate string as text property? This would >>> make it possible to attach annotations via Marginalia or to execute >>> buffer actions via Embark. Otherwise I don't see a possibility to access >>> the original buffer, since they are only present in the `unique-names` >>> alist local variable. >> >> That makes sense. Just call the property 'buffer'? > > That would work. I prefer a more specific property name to ease > grepping/debugging. Also see below regarding the consing. > >> I wonder if it would make sense to alter the calling convention for >> uniquify-get-unique-names itself to return a list of propertized strings >> instead. project--read-project-buffer can do the conversion (copy each string >> and attach the property), but it's just extra consing. > > I haven't checked if the current function is already working hard to > avoid unnecessary allocations. If yes, it would be wasteful to add extra > string allocations. > > In order to avoid them, we could only attach the property if the buffer > name has really changed, such that no strings have to be copied. The > property could be called `uniquify-orig-buffer-name`. If the property is > present, it holds the original buffer name, if it is not present the > string itself is the original buffer name. All else being equal, I think changing uniquify-get-unique-names to return a list of strings which have the original buffer names as a property is a reasonable and easy thing to do. uniquify.el is generally pretty allocation heavy, so I wouldn't worry about the excess allocations, just stick the property on all the returned strings. Also, some future work I was considering, which I hope we can accomodate: making this be internal functionality of read-buffer. That is, when read-buffer is passed a predicate, it could: - use the predicate to filter the buffers - then use uniquify-get-unique-names to get less-verbose buffer names - then call completing-read with those buffer names I think the text property approach would indeed work with this, but just mentioning it. Some unnecessary speculation about alternatives to the text property approach follows: One alternative to the text property approach is to have the alist returned by uniquify-get-unique-names be let-bound in some special variable around the call to completing-read. Then Embark/Marginalia could look up strings in that alist to figure out the underlying buffer that a string is referring to. Or, we could have a completion table action (ACTION='get-buffer or something) which ignores PRED and returns the buffer corresponding to the passed in STRING. No new special variables at all. I am reminded of the perennial discussions about how completing-read is an API for "read string with completion", not "select a value by its string name from a set of possible values", maybe this would be useful for that...) >> Unless some more new callers are going to prefer the current convention. > > Both would be fine for me. Generally I think it is nice to push > functionality to the lower level API, as long as the functionality is > generic enough. > > Btw, would you be interested in having `uniquify-get-unique-names' in > Compat, such that you avoid the fboundp check? project.el would have to > depend on Compat for that, but that's essentially free on Emacs 30 and > newer. I think adding uniquify-get-unique-names to compat might be difficult because it depends on non-trivial changes to the rest of the code in uniquify.el. From unknown Sun Jun 15 08:44:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#77312: [PATCH] Add uniquify-get-unique-names Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Jun 2025 16:55:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 77312 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: 77312@debbugs.gnu.org Cc: sbaugh@janestreet.com, dmitry@gutov.dev X-Debbugs-Original-To: Spencer Baugh via "Bug reports for GNU Emacs, the Swiss army knife of text editors" X-Debbugs-Original-Cc: Spencer Baugh , 77312@debbugs.gnu.org, Dmitry Gutov Received: via spool by submit@debbugs.gnu.org id=B.174957448817381 (code B ref -1); Tue, 10 Jun 2025 16:55:03 +0000 Received: (at submit) by debbugs.gnu.org; 10 Jun 2025 16:54:48 +0000 Received: from localhost ([127.0.0.1]:39349 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uP2FI-0004Vd-Fd for submit@debbugs.gnu.org; Tue, 10 Jun 2025 12:54:48 -0400 Received: from lists.gnu.org ([2001:470:142::17]:35174) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uP2FE-0004Tf-TS for submit@debbugs.gnu.org; Tue, 10 Jun 2025 12:54:41 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uP2Ev-0002Gn-F1 for bug-gnu-emacs@gnu.org; Tue, 10 Jun 2025 12:54:27 -0400 Received: from server.qxqx.de ([2a01:4f8:c012:9177::1] helo=mail.qxqx.de) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uP2Eq-0001Il-UY for bug-gnu-emacs@gnu.org; Tue, 10 Jun 2025 12:54:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daniel-mendler.de; s=key; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Jzm8WmL1oV3yDpj23ahiLHFU7H42O/PVdqexMCV3sqo=; b=OBOGApwX7SUAWHhtUHkYIIfjMT Elek0xIAwOgmKOJJ7QC7vVx2keAFLBVTOkn9W77wJcwITb/5EUX1P8QsXMd9ntNvlasXBCXI0voxX Xm3GMrvbnx7UxPuieKTtd4idUOCIABuzetRHzOmoNP+AB1jkxjZEBQ5qE0JR1pxXtoH0=; From: Daniel Mendler In-Reply-To: References: <5919de07-9849-4257-b448-af45f46b3181@gutov.dev> <87jz5o9dj5.fsf@daniel-mendler.de> <851a4f79-6789-4f60-9952-2f896b9ee187@gutov.dev> <87ikl6yem8.fsf@daniel-mendler.de> Date: Tue, 10 Jun 2025 18:54:12 +0200 Message-ID: <87sek7tu4r.fsf@daniel-mendler.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2a01:4f8:c012:9177::1; envelope-from=mail@daniel-mendler.de; helo=mail.qxqx.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) Spencer Baugh via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: > Daniel Mendler writes: > >> Dmitry Gutov writes: >> >>> Hey Daniel! >>> >>> On 07/06/2025 11:11, Daniel Mendler wrote: >>>> Would it be possible to attach the buffer object or the original buffer >>>> name to the completion candidate string as text property? This would >>>> make it possible to attach annotations via Marginalia or to execute >>>> buffer actions via Embark. Otherwise I don't see a possibility to access >>>> the original buffer, since they are only present in the `unique-names` >>>> alist local variable. >>> >>> That makes sense. Just call the property 'buffer'? >> >> That would work. I prefer a more specific property name to ease >> grepping/debugging. Also see below regarding the consing. >> >>> I wonder if it would make sense to alter the calling convention for >>> uniquify-get-unique-names itself to return a list of propertized strings >>> instead. project--read-project-buffer can do the conversion (copy each string >>> and attach the property), but it's just extra consing. >> >> I haven't checked if the current function is already working hard to >> avoid unnecessary allocations. If yes, it would be wasteful to add extra >> string allocations. >> >> In order to avoid them, we could only attach the property if the buffer >> name has really changed, such that no strings have to be copied. The >> property could be called `uniquify-orig-buffer-name`. If the property is >> present, it holds the original buffer name, if it is not present the >> string itself is the original buffer name. > > All else being equal, I think changing uniquify-get-unique-names to > return a list of strings which have the original buffer names as a > property is a reasonable and easy thing to do. uniquify.el is generally > pretty allocation heavy, so I wouldn't worry about the excess > allocations, just stick the property on all the returned strings. Okay. > Some unnecessary speculation about alternatives to the text property > approach follows: > > One alternative to the text property approach is to have the alist > returned by uniquify-get-unique-names be let-bound in some special > variable around the call to completing-read. Then Embark/Marginalia > could look up strings in that alist to figure out the underlying buffer > that a string is referring to. Yes, this would work too. Or more ideally set a local variable in the minibuffer setup hook, since then buffer unification can be detected by checking if the variable is non-nil. >>> Unless some more new callers are going to prefer the current convention. >> >> Both would be fine for me. Generally I think it is nice to push >> functionality to the lower level API, as long as the functionality is >> generic enough. >> >> Btw, would you be interested in having `uniquify-get-unique-names' in >> Compat, such that you avoid the fboundp check? project.el would have to >> depend on Compat for that, but that's essentially free on Emacs 30 and >> newer. > > I think adding uniquify-get-unique-names to compat might be difficult > because it depends on non-trivial changes to the rest of the code in > uniquify.el. That's unfortunate. I have not looked in detail at it, but if the effort is disproportionate, and half of uniquify.el would need to be replicated, then we cannot port it back as part of Compat. Daniel From unknown Sun Jun 15 08:44:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#77312: [PATCH] Add uniquify-get-unique-names Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Jun 2025 17:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 77312 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Daniel Mendler Cc: dmitry@gutov.dev, 77312@debbugs.gnu.org Received: via spool by 77312-submit@debbugs.gnu.org id=B77312.174957505024283 (code B ref 77312); Tue, 10 Jun 2025 17:05:02 +0000 Received: (at 77312) by debbugs.gnu.org; 10 Jun 2025 17:04:10 +0000 Received: from localhost ([127.0.0.1]:39384 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uP2ON-0006JH-8V for submit@debbugs.gnu.org; Tue, 10 Jun 2025 13:04:10 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:36485) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uP2OF-0006Gf-Pm for 77312@debbugs.gnu.org; Tue, 10 Jun 2025 13:04:03 -0400 From: Spencer Baugh In-Reply-To: <87sek7tu4r.fsf@daniel-mendler.de> (Daniel Mendler's message of "Tue, 10 Jun 2025 18:54:12 +0200") References: <5919de07-9849-4257-b448-af45f46b3181@gutov.dev> <87jz5o9dj5.fsf@daniel-mendler.de> <851a4f79-6789-4f60-9952-2f896b9ee187@gutov.dev> <87ikl6yem8.fsf@daniel-mendler.de> <87sek7tu4r.fsf@daniel-mendler.de> Date: Tue, 10 Jun 2025 13:03:53 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1749575033; bh=sop1UEnJZ3497V0rZNXoJYaQvO5FZUCja5idVC1SaoM=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=J4pVLsGhblpn/bK0uSmyp20vRz24BC3uZ551M6GyoUvN9GHJfzRbYrQbM4Hz4L0so 8j3PxXGNhkOpM+/nKgp9HUqii509b10Ov103/0Qyl5j/iZoalaOXIxcGdtG/EReFX0 9VA64tLagLe+yf/P346gKtanwB8HYG0ibX1K8YR4hpf2J6HfZUWg621WHJpUeNJ9I4 j8uRUwjJNAdynPjyNKysx23/dkMCfu6F3XxeJZnPKBdzOKHBKeuhXTo/lqt2fFviFI T7yBRulQCyKEgmmopE3H9HTPCCNJCm3r2z/oGOuMu5khxIaLlzV40GXO6RANX23JV/ rNCi8vp835FLA== X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Daniel Mendler writes: > Spencer Baugh via "Bug reports for GNU Emacs, the Swiss army knife of > text editors" writes: > >> Daniel Mendler writes: >> >>> Dmitry Gutov writes: >>> >>>> Hey Daniel! >>>> >>>> On 07/06/2025 11:11, Daniel Mendler wrote: >>>>> Would it be possible to attach the buffer object or the original buffer >>>>> name to the completion candidate string as text property? This would >>>>> make it possible to attach annotations via Marginalia or to execute >>>>> buffer actions via Embark. Otherwise I don't see a possibility to access >>>>> the original buffer, since they are only present in the `unique-names` >>>>> alist local variable. >>>> >>>> That makes sense. Just call the property 'buffer'? >>> >>> That would work. I prefer a more specific property name to ease >>> grepping/debugging. Also see below regarding the consing. >>> >>>> I wonder if it would make sense to alter the calling convention for >>>> uniquify-get-unique-names itself to return a list of propertized strings >>>> instead. project--read-project-buffer can do the conversion (copy each string >>>> and attach the property), but it's just extra consing. >>> >>> I haven't checked if the current function is already working hard to >>> avoid unnecessary allocations. If yes, it would be wasteful to add extra >>> string allocations. >>> >>> In order to avoid them, we could only attach the property if the buffer >>> name has really changed, such that no strings have to be copied. The >>> property could be called `uniquify-orig-buffer-name`. If the property is >>> present, it holds the original buffer name, if it is not present the >>> string itself is the original buffer name. >> >> All else being equal, I think changing uniquify-get-unique-names to >> return a list of strings which have the original buffer names as a >> property is a reasonable and easy thing to do. uniquify.el is generally >> pretty allocation heavy, so I wouldn't worry about the excess >> allocations, just stick the property on all the returned strings. > > Okay. Er, sorry, crucial typo/miscommunication here: I think uniquify-get-unique-names should return a list of strings, each of which has a text property containing the original *buffer*. Not the original buffer name - the buffer itself. That would just be slightly more efficient. > >> Some unnecessary speculation about alternatives to the text property >> approach follows: >> >> One alternative to the text property approach is to have the alist >> returned by uniquify-get-unique-names be let-bound in some special >> variable around the call to completing-read. Then Embark/Marginalia >> could look up strings in that alist to figure out the underlying buffer >> that a string is referring to. > > Yes, this would work too. Or more ideally set a local variable in the > minibuffer setup hook, since then buffer unification can be detected by > checking if the variable is non-nil. Ah right, because otherwise a recursive edit could cause problems... so a local variable set in the minibuffer setup hook would indeed be bettter. >>>> Unless some more new callers are going to prefer the current convention. >>> >>> Both would be fine for me. Generally I think it is nice to push >>> functionality to the lower level API, as long as the functionality is >>> generic enough. >>> >>> Btw, would you be interested in having `uniquify-get-unique-names' in >>> Compat, such that you avoid the fboundp check? project.el would have to >>> depend on Compat for that, but that's essentially free on Emacs 30 and >>> newer. >> >> I think adding uniquify-get-unique-names to compat might be difficult >> because it depends on non-trivial changes to the rest of the code in >> uniquify.el. > > That's unfortunate. I have not looked in detail at it, but if the effort > is disproportionate, and half of uniquify.el would need to be > replicated, then we cannot port it back as part of Compat. Yep. Maybe about 120 lines would need to be replicated.