unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Juanma Barranquero <lekktu@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 3224@debbugs.gnu.org
Subject: bug#3224: 23.0.92; vc-dir vs uniquify: wrong directory used
Date: Thu, 7 Jan 2010 12:14:01 +0100	[thread overview]
Message-ID: <f7ccd24b1001070314k6114cbcep296ad50dc44eb533@mail.gmail.com> (raw)
In-Reply-To: <jwv7hrvgvgo.fsf-monnier+emacs@gnu.org>

On Wed, Jan 6, 2010 at 15:28, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> AFAIK it already *does* the right thing (try it with Dired buffers,
> since these are the (only?) ones that should have a directory name),
> unless maybe we don't agree on what is the right thing in that case.

The dired and vc-dired cases are not exactly equivalent. In the dired
case, uniquify-buffer-file-name is called when there's a conflict like

  (dired "/my/dir-1/A")
  (dired "/my/dir-2/A")

(because /my/dir/A vs my/dir/B obviously does not produce any conflict).

In this case, u-b-f-n gets, via `list-buffers-directory', the full
path including the A:  /my/dir1/A, and strips the last element and
returns /my/dir1. That works for uniquify, because it will be getting
path elements from /my/dir1 vs. /my/dir2, just as it needs. The
resulting buffers (with forward syntax) will be "A|dir-1" and
"A|dir-2".

In the OP's vc-dir case, the conflicts happens in this:

  (vc-dir "/my/dir/A")
  (vc-dir "/my/dir/B")

because the conflict uniquify tries to solve is at the buffer-name
level, which is always *vc-dir*. /my/dir/A and /my/dir/B are
directories, and so elements for uniquifying; the expected result is
"*vc-dir*|A" and "*vc-dir*|B". However, u-b-f-n gets "/my/dir/B" (via
list-buffers-directory), which is correct, and again strips the last
element and returns "/my/dir". So uniquify ends producting
"*vc-dir*|A" and "*vc-dir*|dir", which is incorrect.

Now, if you consider than always removing an element from BUFFER is
the right thing to do for u-b-f-n, we'll have to agree to disagree;
IMHO, that's not what its docstring says. From it, I would expect
u-b-f-n to return a directory unchanged. That said, my "fix" to
u-b-f-n would break uniquifying of dired buffers (thanks for pointing
that out), so perhaps we'll have to live with such behavior. In that
case, I'd suggest reworking the docstring of u-b-f-n.

Going with your proposed fix via `list-buffers-directory', the
following patch works. I have not added a comment to the change to
`list-buffers-directory' because I don't really know how to explain
it; it seems a hack to me to force a variable named
`list-buffers-directory' to contain a bogus name part just to help
uniquify.

Comments? Dan, what do you think?

    Juanma



=== modified file 'lisp/vc-dir.el'
--- lisp/vc-dir.el	2009-12-05 00:24:03 +0000
+++ lisp/vc-dir.el	2010-01-07 11:09:16 +0000
@@ -101,7 +101,9 @@
                       (return buffer))))))))
     (or buf
         ;; Create a new buffer named BNAME.
-        (with-current-buffer (create-file-buffer bname)
+	;; We pass a filename to create-file-buffer because it is what
+	;; the function expects, and also what uniquify needs (if active)
+        (with-current-buffer (create-file-buffer (expand-file-name bname dir))
           (cd dir)
           (vc-setup-buffer (current-buffer))
           ;; Reset the vc-parent-buffer-name so that it does not appear
@@ -928,7 +930,7 @@
     (set (make-local-variable 'vc-ewoc) (ewoc-create #'vc-dir-printer))
     (set (make-local-variable 'revert-buffer-function)
 	 'vc-dir-revert-buffer-function)
-    (setq list-buffers-directory default-directory)
+    (setq list-buffers-directory (expand-file-name "*vc-dir*"
default-directory))
     (add-to-list 'vc-dir-buffers (current-buffer))
     ;; Make sure that if the directory buffer is killed, the update
     ;; process running in the background is also killed.






  reply	other threads:[~2010-01-07 11:14 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <f7ccd24b1001071940k28f0f35y508b7f1c26640f9f@mail.gmail.com>
2009-05-05 15:19 ` bug#3224: 23.0.92; vc-dir vs uniquify: wrong directory used Magnus Henoch
2009-08-04 12:30   ` Dan Nicolaescu
2010-01-06  4:00     ` Juanma Barranquero
2010-01-06  4:55       ` Dan Nicolaescu
2010-01-06  5:38       ` Stefan Monnier
2010-01-06 10:17         ` Juanma Barranquero
2010-01-06 14:28           ` Stefan Monnier
2010-01-07 11:14             ` Juanma Barranquero [this message]
2010-01-07 14:54               ` Stefan Monnier
2010-01-07 15:09                 ` Juanma Barranquero
2010-01-07 19:53                   ` Stefan Monnier
2010-01-07 23:05                     ` Juanma Barranquero
2010-01-08  3:22                       ` Stefan Monnier
2010-01-07 15:10               ` Dan Nicolaescu
2010-01-07 15:19                 ` Juanma Barranquero
2010-01-07 19:57                 ` Stefan Monnier
2010-01-08  3:41   ` bug#3224: marked as done (23.0.92; vc-dir vs uniquify: wrong directory used) Emacs bug Tracking System
2009-09-24 20:53 ` bug#4553: 23.1; uniquify gives *vc-dir* buffer the wrong name Tom Tromey
2009-09-24 21:32   ` Dan Nicolaescu
2009-09-24 21:40     ` Processed: " Emacs bug Tracking System
2010-01-08  3:41   ` bug#4553: marked as done (23.1; uniquify gives *vc-dir* buffer the wrong name) Emacs bug Tracking System

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=f7ccd24b1001070314k6114cbcep296ad50dc44eb533@mail.gmail.com \
    --to=lekktu@gmail.com \
    --cc=3224@debbugs.gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).