From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Spencer Baugh Newsgroups: gmane.emacs.bugs Subject: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename Date: Fri, 14 Jul 2023 08:20:02 -0400 Message-ID: References: <87bkgfjugn.fsf@catern.com> <83edlb3t0t.fsf@gnu.org> <878rbika0i.fsf@catern.com> <83h6q6g0qx.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33238"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: sbaugh@catern.com, 62621@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jul 14 14:21:23 2023 Return-path: Envelope-to: geb-bug-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 1qKHnW-0008Re-UQ for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 14 Jul 2023 14:21:23 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qKHnD-0004Yu-KV; Fri, 14 Jul 2023 08:21:03 -0400 Original-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 1qKHnB-0004Yd-UU for bug-gnu-emacs@gnu.org; Fri, 14 Jul 2023 08:21:01 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qKHnB-0003e4-Lh for bug-gnu-emacs@gnu.org; Fri, 14 Jul 2023 08:21:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qKHnB-0006VA-HN for bug-gnu-emacs@gnu.org; Fri, 14 Jul 2023 08:21:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Jul 2023 12:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62621 X-GNU-PR-Package: emacs Original-Received: via spool by 62621-submit@debbugs.gnu.org id=B62621.168933720924868 (code B ref 62621); Fri, 14 Jul 2023 12:21:01 +0000 Original-Received: (at 62621) by debbugs.gnu.org; 14 Jul 2023 12:20:09 +0000 Original-Received: from localhost ([127.0.0.1]:41591 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKHmL-0006T2-18 for submit@debbugs.gnu.org; Fri, 14 Jul 2023 08:20:09 -0400 Original-Received: from mxout5.mail.janestreet.com ([64.215.233.18]:54033) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKHmJ-0006SW-Bh for 62621@debbugs.gnu.org; Fri, 14 Jul 2023 08:20:08 -0400 In-Reply-To: <83h6q6g0qx.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 14 Jul 2023 15:01:58 +0300") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:265086 Archived-At: Eli Zaretskii writes: >> From: sbaugh@catern.com >> Date: Fri, 14 Jul 2023 11:28:13 +0000 (UTC) >> Cc: sbaugh@janestreet.com, 62621@debbugs.gnu.org >> >> Eli Zaretskii writes: >> >> > If there are a couple of simpler alternatives which could be offered >> > via simple symbolic values, we should not force everyone to write >> > functions, IMNSHO. IOW, we should NOT immediately generalize to >> > functions only because such generalization could make sense in some >> > use cases. Repeat after me: Use options whose values are functions >> > are hard on our users, because they require them to be Lisp >> > programmers. >> >> I agree, and I'm happy to change it to use a simple symbolic value >> 'project instead for the transform I wrote, but I'm not sure how best to >> handle the dependencies: uniquify.el is in loadup.el, is it OK for it to >> rely on project-uniquify-dirname-transform being autoloaded? > > I don't understand the difficulty. If the function value could be > defined in uniquify.el, why cannot a symbolic value be defined there? I don't understand your question :) Here's concretely the diff I would apply. This makes uniquify.el mention a function from project.el. Is that OK? diff --git a/lisp/uniquify.el b/lisp/uniquify.el index bd49346da45..4783830b184 100644 --- a/lisp/uniquify.el +++ b/lisp/uniquify.el @@ -168,14 +168,10 @@ uniquify-list-buffers-directory-modes That means that when `buffer-file-name' is set to nil, `list-buffers-directory' contains the name of the directory which the buffer is visiting.") -(defcustom uniquify-dirname-transform #'identity - "A function to transform the dirname used to uniquify a buffer. - -It takes a single argument: the directory of the buffer. It -should return a string filename (which does not need to actually -exist in the filesystem) to use for uniquifying the buffer name." - :type '(choice (function-item :tag "Don't change the dirname" identity) - function) +(defcustom uniquify-dirname-transform nil + "How to transform the dirname used to uniquify a buffer." + :type '(choice (const :tag "Don't change the dirname" nil) + (const :tag "Include project-name when uniquifying" 'project)) :group 'uniquify) ;;; Utilities @@ -279,11 +275,14 @@ uniquify-buffer-file-name (if (memq major-mode uniquify-list-buffers-directory-modes) list-buffers-directory)))) (when filename - (funcall uniquify-dirname-transform - (directory-file-name - (file-name-directory - (expand-file-name - (directory-file-name filename))))))))) + (funcall + (cond ((not uniquify-dirname-transform) #'identity) + ((eq uniquify-dirname-transform 'project) #'project-uniquify-dirname-transform) + (t (error "bad uniquify-dirname-transform: %s" uniquify-dirname-transform))) + (directory-file-name + (file-name-directory + (expand-file-name + (directory-file-name filename))))))))) (defun uniquify-rerationalize-w/o-cb (fix-list) "Re-rationalize the buffers in FIX-LIST, but ignoring `current-buffer'." > If the symbolic values are specific to project, simply let-bind > uniquify-dirname-transform to the value of the appropriate project.el > defcustom when project.el calls uniquify. These customizations are in effect all the time, not just when the user is calling a project.el command. e.g. rename-buffer triggers uniquify. >> >> +(defcustom uniquify-dirname-transform #'identity >> >> + "A function to transform the dirname used to uniquify a buffer. >> > >> > "Function to transform buffer's `default-directory' for uniquifying its name." >> >> Unfortunately, this isn't quite right. uniquify never uses >> default-directory, counterintuitively - by default, it uses the >> directory of buffer-file-name, which can differ from default-directory. > > That's a minor issue, just use "buffer's directory" instead. > > But I wonder why uniquify does something counterintuitive like that. I assume it's something like "default-directory changes (such as by M-x cd) shouldn't change the buffer name too". Although personally I would be totally fine with cd changing the buffer name... The fact that uniquify doesn't use default-directory also means it's unable to uniquify buffers which aren't visiting files, which can be annoying. For example, if uniquify used default-directory then it could uniquify *compilation* buffers for different projects, renaming them based on the directory. But because it can't, every package has to come up with their own special buffer-renaming scheme... include project.el. I could add support for making uniquify use default-directory instead, if that's interesting.