all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Spencer Baugh <sbaugh@janestreet.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: sbaugh@catern.com, 62621@debbugs.gnu.org
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	[thread overview]
Message-ID: <ierh6q6it1p.fsf@janestreet.com> (raw)
In-Reply-To: <83h6q6g0qx.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 14 Jul 2023 15:01:58 +0300")

Eli Zaretskii <eliz@gnu.org> 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 <eliz@gnu.org> 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.





  reply	other threads:[~2023-07-14 12:20 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-02 17:37 bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename Spencer Baugh
2023-04-02 17:57 ` Eli Zaretskii
2023-04-02 21:59   ` Drew Adams
2023-04-02 18:25 ` Juri Linkov
2023-04-14 16:08 ` Spencer Baugh
2023-07-13 22:51 ` sbaugh
2023-07-14  6:29   ` Eli Zaretskii
2023-07-14 11:28     ` sbaugh
2023-07-14 12:01       ` Eli Zaretskii
2023-07-14 12:20         ` Spencer Baugh [this message]
2023-07-14 12:29           ` Eli Zaretskii
2023-07-14 12:46             ` Spencer Baugh
2023-07-14 13:51               ` Eli Zaretskii
2023-07-14 14:14                 ` Spencer Baugh
2023-07-14 19:10                   ` Eli Zaretskii
2023-07-14 19:15                     ` sbaugh
2023-07-15  5:42                       ` Eli Zaretskii
2023-07-15  6:20                         ` Eli Zaretskii
2023-07-18  0:19                       ` Dmitry Gutov
2023-07-18  1:37               ` Dmitry Gutov
2023-07-18 16:03                 ` Spencer Baugh
2023-07-19  2:47                   ` Dmitry Gutov
2023-07-19  6:56                     ` Juri Linkov
2023-07-18 17:51                 ` Juri Linkov
2023-07-19  2:24                   ` Dmitry Gutov
2023-07-14 16:31           ` Juri Linkov
2023-07-18  0:34     ` Dmitry Gutov
2023-07-18 11:07       ` Eli Zaretskii
2023-07-19  2:22         ` Dmitry Gutov
2023-07-19 12:14           ` Eli Zaretskii
2023-07-19 12:31             ` Spencer Baugh
2023-07-19 13:25               ` Eli Zaretskii
2023-07-21 13:34                 ` Spencer Baugh
2023-07-21 14:37                   ` Eli Zaretskii
2023-07-22 18:00                     ` Spencer Baugh
2023-07-24 19:18                       ` Spencer Baugh
2023-07-26 15:18                         ` Eli Zaretskii
2023-08-03  8:00                           ` Eli Zaretskii
2023-08-03 11:54                             ` Spencer Baugh
2023-08-03 14:05                               ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ierh6q6it1p.fsf@janestreet.com \
    --to=sbaugh@janestreet.com \
    --cc=62621@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=sbaugh@catern.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.