Subject: bug#78890: 31.0.50; Messy vc-annotate buffer names

From: Sean Whitton <[email-masked]>
Date: Fri, 27 Jun 2025 12:11:59 +0100

Hello,

On Thu 26 Jun 2025 at 12:13pm -07, Jim Porter wrote:

> On 6/26/2025 11:27 AM, Sean Whitton wrote:
>> I'm more concerned about an actual clash in buffer names between files
>> with the same name in different directories.  What do you think about
>> that?
>
> I think it would be fairly rare for us not to have the original buffer in the
> first place, but it would be even rarer to additionally have some *other*
> buffer with the same (non-directory) buffer name. Since the potential for
> confusion only comes up after two relatively rare conditions, I'd be ok with
> just the non-directory part of the file name in the Annotate buffer name.
>
> The ideal would be a function like, "What would the buffer name for this file
> be *if* I visited it?" A cursory look didn't show anything like that though.
>
> That said, since the first condition above is also probably rare, I wouldn't
> be *that* upset if we showed the full file name in that case. How often could
> it come up anyway?

It'll come up when vc-buffer-overriding-fileset is used to determine the
file to annotate, such as in the case where C-x v g is used from a
buffer generated by vc-find-revision called on a file name that is not
checked out (e.g. a file name only present on another branch).

What we really want here it to tap into the uniquify machinery in an
appropriate way, but we would also want the name of our buffer to get
updated in the way uniquify automatically updates buffer names when new
ambiguity would otherwise be introduced.

How about this (whitespace-only changes filtered out):

--8<---------------cut here---------------start------------->8---
diff --git a/lisp/vc/vc-annotate.el b/lisp/vc/vc-annotate.el
index de432e4e1c3..4f72faacaaf 100644
--- a/lisp/vc/vc-annotate.el
+++ b/lisp/vc/vc-annotate.el
@@ -419,7 +419,19 @@ vc-annotate
 		       (read-string (format-prompt "Annotate span days" 20)
 				    nil nil "20"))))))))
   (setq vc-annotate-display-mode display-mode) ;Not sure why.  --Stef
-  (let* ((temp-buffer-name (format "*Annotate %s (rev %s)*" (buffer-name) rev))
+  (let* ((backend (or backend
+                      (car vc-buffer-overriding-fileset)
+                      (vc-backend file)))
+         (file-buffer (get-file-buffer file))
+         (temp-buffer-name
+          (format "*Annotate %s (rev %s)*"
+                  (if file-buffer
+                      (buffer-name file-buffer)
+                    ;; Try to avoid ambiguity.
+                    (file-relative-name file
+                                        (vc-call-backend backend 'root
+                                                         default-directory)))
+                  rev))
          (temp-buffer-show-function 'vc-annotate-display-select)
          ;; If BUF is specified, we presume the caller maintains current line,
          ;; so we don't need to do it here.  This implementation may give
@@ -436,10 +436,7 @@
 		(rename-buffer temp-buffer-name t)
 		;; In case it had to be uniquified.
 		(setq temp-buffer-name (buffer-name))))
-    (let ((backend (or backend
-                       (car vc-buffer-overriding-fileset)
-                       (vc-backend file)))
-          (coding-system-for-read buffer-file-coding-system))
+    (let ((coding-system-for-read buffer-file-coding-system))
      (with-output-to-temp-buffer temp-buffer-name
        ;; For a VC backend running on DOS/Windows, it's normal to
        ;; produce CRLF EOLs even if the original file has Unix EOLs,
--8<---------------cut here---------------end--------------->8---

-- 
Sean Whitton