GNU bug report logs - #3224
23.0.92; vc-dir vs uniquify: wrong directory used

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 3224 in the body.
You can then email your comments to 3224 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Magnus Henoch <mange <at> freemail.hu>
To: emacs-pretest-bug <at> gnu.org
Subject: 23.0.92; vc-dir vs uniquify: wrong directory used
Date: Tue, 05 May 2009 16:19:07 +0100

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug <at> gnu.org mailing list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

I have uniquify-buffer-name-style set to post-forward, which means that
I expect buffers with the same name to be called BUFFER|DIR.  This
doesn't quite work with vc-dir: the DIR part corresponds to the setting
of `default-directory' in the buffer where I invoke the command, instead
of the directory I specify.

To reproduce, start "emacs -Q" and evaluate:

(progn
  (require 'uniquify)
  (setq uniquify-buffer-name-style 'post-forward)
  (cd "/tmp")
  (make-directory "foo")
  (make-directory "bar")
  (vc-dir "/tmp/foo")
  (cd "/tmp/foo")
  (vc-dir "/tmp/bar"))

You will get two buffers, "*vc-dir*|foo" displaying /tmp/bar, and
"*vc-dir*|/tmp" displaying /tmp/foo.

I tried to fix this by binding default-directory around
create-file-buffer in vc-dir-prepare-status-buffer, which partly fixed
the problem: the buffer for bar had a correct name, but the buffer for
foo was still "*vc-dir*|/tmp".

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
/usr/local/share/emacs/23.0.92/etc/DEBUG for instructions.


In GNU Emacs 23.0.92.1 (i686-pc-linux-gnu, GTK+ Version 2.14.4)
 of 2009-04-28 on linux-b2a3
Windowing system distributor `The X.Org Foundation', version 11.0.10502000
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: C
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=local
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Diff

Minor modes in effect:
  diff-auto-refine-mode: t
  shell-dirtrack-mode: t
  jabber-activity-mode: t
  jabber-mode-line-mode: t
  show-paren-mode: t
  server-mode: t
  icomplete-mode: t
  display-time-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
d <C-s-up> <tab> <return> <next> <up> <down> <down> 
<down> <down> <down> <down> <down> <down> M-f M-f M-f 
M-f s-i <return> C-x v d ~ / b l a <tab> s v <tab> 
a <tab> p <tab> <return> <C-s-down> C-h f u n i j <backspace> 
q <tab> <tab> r a t <tab> <M-backspace> b u <tab> f 
<tab> <return> <C-s-up> <tab> <return> <C-s-up> <tab> 
<return> <tab> <return> <down> <down> C-x b <return> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> C-h f <return> M-x l o c a 
t e <return> v c - d i r . e l <return> <down> <down> 
<return> s-i v <tab> i <return> s-i v c - d i r - p 
r e <return> p <return> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> C-e <return> <tab> ( l e t SPC ( ( d 
e f a u l t - d i r e c t o r y SPC d i r ) ) <down> 
<down> C-a C-k C-k <down> <down> <down> <down> C-e 
) C-x C-s C-x C-e C-x v d ~ / b l a <tab> s v <tab> 
n o <tab> <return> C-x v d <backspace> n o d <return> 
a d <return> <return> C-x v d <backspace> <backspace> 
a p <return> a d <return> <return> C-x b C-s <return> 
C-x v = C-h v u n i q u <tab> b u <return> M-x r e 
p o r t - e <tab> <return>

Message #8 received at 3224 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Dan Nicolaescu <dann <at> ics.uci.edu>
To: Magnus Henoch <mange <at> freemail.hu>
Cc: 3224 <at> debbugs.gnu.org
Subject: Re: bug#3224: 23.0.92; vc-dir vs uniquify: wrong directory used
Date: Tue, 4 Aug 2009 05:30:26 -0700 (PDT)

Magnus Henoch <mange <at> freemail.hu> writes:

  > Please write in English if possible, because the Emacs maintainers
  > usually do not have translators to read other languages for them.
  > 
  > Your bug report will be posted to the emacs-pretest-bug <at> gnu.org mailing list.
  > 
  > Please describe exactly what actions triggered the bug
  > and the precise symptoms of the bug:
  > 
  > I have uniquify-buffer-name-style set to post-forward, which means that
  > I expect buffers with the same name to be called BUFFER|DIR.  This
  > doesn't quite work with vc-dir: the DIR part corresponds to the setting
  > of `default-directory' in the buffer where I invoke the command, instead
  > of the directory I specify.
  > 
  > To reproduce, start "emacs -Q" and evaluate:
  > 
  > (progn
  >   (require 'uniquify)
  >   (setq uniquify-buffer-name-style 'post-forward)
  >   (cd "/tmp")
  >   (make-directory "foo")
  >   (make-directory "bar")
  >   (vc-dir "/tmp/foo")
  >   (cd "/tmp/foo")
  >   (vc-dir "/tmp/bar"))
  > 
  > You will get two buffers, "*vc-dir*|foo" displaying /tmp/bar, and
  > "*vc-dir*|/tmp" displaying /tmp/foo.
  > 
  > I tried to fix this by binding default-directory around
  > create-file-buffer in vc-dir-prepare-status-buffer, which partly fixed
  > the problem: the buffer for bar had a correct name, but the buffer for
  > foo was still "*vc-dir*|/tmp".

I am not familiar with uniquify, but after binding default-directory in
vc-dir-prepare-status-buffer, I get the result above.
And it is identical to what happens when doing:


(progn
  (require 'uniquify)
  (setq uniquify-buffer-name-style 'post-forward)
  (cd "/tmp")
  (make-directory "foo")
  (make-directory "bar")
  (cd "/tmp/foo")
  (create-file-buffer "*vc-dir*")
  (cd "/tmp/bar")
  (create-file-buffer "*vc-dir*"))


so either this is a problem with uniquify, or uniquify it's just working
as expected.

Message #13 received at 3224 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Dan Nicolaescu <dann <at> ics.uci.edu>
Cc: Magnus Henoch <mange <at> freemail.hu>, 3224 <at> debbugs.gnu.org
Subject: Re: bug#3224: 23.0.92; vc-dir vs uniquify: wrong directory used
Date: Wed, 6 Jan 2010 05:00:38 +0100

On Tue, Aug 4, 2009 at 13:30, Dan Nicolaescu <dann <at> ics.uci.edu> wrote:

> I am not familiar with uniquify, but after binding default-directory in
> vc-dir-prepare-status-buffer, I get the result above.
> And it is identical to what happens when doing:
>
>
> (progn
>  (require 'uniquify)
>  (setq uniquify-buffer-name-style 'post-forward)
>  (cd "/tmp")
>  (make-directory "foo")
>  (make-directory "bar")
>  (cd "/tmp/foo")
>  (create-file-buffer "*vc-dir*")
>  (cd "/tmp/bar")
>  (create-file-buffer "*vc-dir*"))

In fact, I think the two problems are not exactly the same, though
they are related. If my analysis, and the following patch, are
correct, Dan's example is caused by a bug in
`uniquify-rationalize-file-buffer-names', which sometimes, while
trying to refresh the dirname of a candidate, fails to check that it
is setting it to nil. Fixing that problem makes Dan's example to work,
but Magnus' vc-dir example still fails.

The reason of the other bug is twofold:

On one hand, vc-dir (specifically `vc-dir-prepare-status-buffer') is
calling `create-file-buffer' passing "*vc-dir*" to it; but that
function expects to be passed a filename; in this case, the difference
is relevant because uniquify tries to use that filename's directory
information to decide the dirname for the candidates.

On the other hand, `uniquify-buffer-file-name' should return a
directory, but fails to deal with the case that the "filename" is
already a directory (which can happen, for example, when it is getting
this "filename" from `list-buffers-directory'). In this case it should
just remove any trailing slash and pass it back unscathed.

Please, try the attached patch to see whether it helps.

Thanks,

    Juanma



2010-01-06  Juanma Barranquero  <lekktu <at> gmail.com>

	Bug#3224
	
	* uniquify.el (uniquify-rationalize-file-buffer-names):
	Don't set uniquify-item-dirname to nil.
	(uniquify-buffer-file-name): If the "filename" is already a directory
	name, do not modify it.

	* vc-dir.el (vc-dir-prepare-status-buffer): Pass a (fake) filename
	to `create-file-buffer' as it expects, not just a buffer name.



=== modified file 'lisp/uniquify.el'
--- lisp/uniquify.el	2010-01-04 05:35:18 +0000
+++ lisp/uniquify.el	2010-01-06 03:22:51 +0000
@@ -232,9 +232,9 @@
 	    ;; of code like in set-visited-file-name:
 	    ;; (or (string= new-name (buffer-name)) (rename-buffer new-name t))
 	    ;; So we need to refresh the dirname of the uniquify-item.
-	    (setf (uniquify-item-dirname (car items))
-		  (uniquify-buffer-file-name
-		   (uniquify-item-buffer (car items))))
+	    (let ((bfn (uniquify-buffer-file-name (uniquify-item-buffer (car
items)))))
+	      (when bfn
+		(setf (uniquify-item-dirname (car items)) bfn)))
 	    ;; This shouldn't happen, but maybe there's no dirname any more.
 	    (unless (uniquify-item-dirname (car items))
 	      (with-current-buffer (uniquify-item-buffer (car items))
@@ -265,9 +265,11 @@
 		   list-buffers-directory))))
       (when filename
 	(directory-file-name
-	 (file-name-directory
-	  (expand-file-name
-	   (directory-file-name filename))))))))
+	 (if (file-directory-p filename)
+	     (file-name-as-directory filename)
+	   (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'."

=== modified file 'lisp/vc-dir.el'
--- lisp/vc-dir.el	2009-12-05 00:24:03 +0000
+++ lisp/vc-dir.el	2010-01-06 03:26:33 +0000
@@ -101,7 +101,7 @@
                       (return buffer))))))))
     (or buf
         ;; Create a new buffer named BNAME.
-        (with-current-buffer (create-file-buffer bname)
+        (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

Message #16 received at 3224 <at> debbugs.gnu.org (full text, mbox):

From: Dan Nicolaescu <dann <at> ics.uci.edu>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 3224 <at> debbugs.gnu.org
Subject: Re: bug#3224: 23.0.92; vc-dir vs uniquify: wrong directory used
Date: Tue, 5 Jan 2010 20:55:28 -0800 (PST)

Juanma Barranquero <lekktu <at> gmail.com> writes:

  > === modified file 'lisp/vc-dir.el'
  > --- lisp/vc-dir.el	2009-12-05 00:24:03 +0000
  > +++ lisp/vc-dir.el	2010-01-06 03:26:33 +0000
  > @@ -101,7 +101,7 @@
  >                        (return buffer))))))))
  >      (or buf
  >          ;; Create a new buffer named BNAME.
  > -        (with-current-buffer (create-file-buffer bname)
  > +        (with-current-buffer (create-file-buffer (expand-file-name bname dir))

Please also add a comment explaining why that is done.

Message #19 received at 3224 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 3224 <at> debbugs.gnu.org
Subject: Re: bug#3224: 23.0.92; vc-dir vs uniquify: wrong directory used
Date: Wed, 06 Jan 2010 00:38:07 -0500

> --- lisp/uniquify.el	2010-01-04 05:35:18 +0000
> +++ lisp/uniquify.el	2010-01-06 03:22:51 +0000
> @@ -232,9 +232,9 @@
>  	    ;; of code like in set-visited-file-name:
>  	    ;; (or (string= new-name (buffer-name)) (rename-buffer new-name t))
>  	    ;; So we need to refresh the dirname of the uniquify-item.
> -	    (setf (uniquify-item-dirname (car items))
> -		  (uniquify-buffer-file-name
> -		   (uniquify-item-buffer (car items))))
> +	    (let ((bfn (uniquify-buffer-file-name (uniquify-item-buffer (car
> items)))))
> +	      (when bfn
> +		(setf (uniquify-item-dirname (car items)) bfn)))

That doesn't sound right.
Why is bfn nil in your case, and why should we not update
uniquify-item-dirname correspondingly?

> @@ -265,9 +265,11 @@
>  		   list-buffers-directory))))
>        (when filename
>  	(directory-file-name
> -	 (file-name-directory
> -	  (expand-file-name
> -	   (directory-file-name filename))))))))
> +	 (if (file-directory-p filename)
> +	     (file-name-as-directory filename)
> +	   (file-name-directory
> +	    (expand-file-name
> +	     (directory-file-name filename)))))))))

I don't thing that's right.  Instead, you probably want to set
list-buffers-directory to something like (expand-file-name "*vc-dir*"),
as is done in PCL-CVS.


        Stefan

Message #22 received at 3224 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 3224 <at> debbugs.gnu.org
Subject: Re: bug#3224: 23.0.92; vc-dir vs uniquify: wrong directory used
Date: Wed, 6 Jan 2010 11:17:29 +0100

On Wed, Jan 6, 2010 at 06:38, Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:

> That doesn't sound right.
> Why is bfn nil in your case, and why should we not update
> uniquify-item-dirname correspondingly?

Sorry, you're right. It failed because of the problem with
`unquify-buffer-file-name'. This part of the patch isn't really needed
anymore.

> I don't thing that's right.  Instead, you probably want to set
> list-buffers-directory to something like (expand-file-name "*vc-dir*"),
> as is done in PCL-CVS.

OK, that's the other alternative, although that function should get
the right thing when it happens to receive a directory name.

I'll test it and send a new patch.

    Juanma

Message #25 received at 3224 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 3224 <at> debbugs.gnu.org
Subject: Re: bug#3224: 23.0.92; vc-dir vs uniquify: wrong directory used
Date: Wed, 06 Jan 2010 09:28:52 -0500

> OK, that's the other alternative, although that function should get
> the right thing when it happens to receive a directory name.

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.


        Stefan

Message #28 received at 3224 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 3224 <at> debbugs.gnu.org
Subject: Re: bug#3224: 23.0.92; vc-dir vs uniquify: wrong directory used
Date: Thu, 7 Jan 2010 12:14:01 +0100

On Wed, Jan 6, 2010 at 15:28, Stefan Monnier <monnier <at> 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.

Message #31 received at 3224 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 3224 <at> debbugs.gnu.org
Subject: Re: bug#3224: 23.0.92; vc-dir vs uniquify: wrong directory used
Date: Thu, 07 Jan 2010 09:54:57 -0500

> The dired and vc-dired cases are not exactly equivalent.

I know.  The right way to think about it is in terms of file names.
If you want uniquify to show you "dir-1|A" and "dir-2|A", then the file
names should be "/foo/dir-1/A" and "/foo/dir-2/A".
So for vc-dir, you want "*vc-dir*" instead of A, right?  So you want
file names of the form "/foo/dir-1/*vc-dir*" and "/foo/dir-2/*vc-dir*".

> 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.

Yes, the docstring has been wrong since day one and I'm guilty of never
fixing it.


        Stefan

Message #34 received at 3224 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 3224 <at> debbugs.gnu.org
Subject: Re: bug#3224: 23.0.92; vc-dir vs uniquify: wrong directory used
Date: Thu, 7 Jan 2010 16:09:48 +0100

On Thu, Jan 7, 2010 at 15:54, Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:

> So for vc-dir, you want "*vc-dir*" instead of A, right?  So you want
> file names of the form "/foo/dir-1/*vc-dir*" and "/foo/dir-2/*vc-dir*".

For such dired-style buffers, uniquify uses list-buffers-directory, so
the only way is as I did in the patch I just sent.

Do you want that patch installed, assuming Dan does not oppose it?

> Yes, the docstring has been wrong since day one

Well, I'm glad we agree on this, then.

(As an aside: the previous time we discussed this, you suggested that
`list-buffers-directory' has the wrong name, and also that perhaps it
would be safer/wiser to create another variable for uses like the one
in uniquify. I think we should revisit this issue after the release.)

    Juanma

Message #37 received at 3224 <at> debbugs.gnu.org (full text, mbox):

From: Dan Nicolaescu <dann <at> ics.uci.edu>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 3224 <at> debbugs.gnu.org
Subject: Re: bug#3224: 23.0.92; vc-dir vs uniquify: wrong directory used
Date: Thu, 7 Jan 2010 07:10:15 -0800 (PST)

Juanma Barranquero <lekktu <at> gmail.com> writes:

  > On Wed, Jan 6, 2010 at 15:28, Stefan Monnier <monnier <at> 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?

Does it work if you have multiple *vc-dir* buffers for the same
directory?
Do something like:
mkdir /tmp/test
cd /tmp/test
git init
bzr init

C-u C-x v d /tmp/test RET Bzr RET
C-u C-x v d /tmp/test RET Git RET

I'm fine with it if you convince Stefan this is TRTD.

Message #40 received at 3224 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Dan Nicolaescu <dann <at> ics.uci.edu>
Cc: 3224 <at> debbugs.gnu.org
Subject: Re: bug#3224: 23.0.92; vc-dir vs uniquify: wrong directory used
Date: Thu, 7 Jan 2010 16:19:03 +0100

On Thu, Jan 7, 2010 at 16:10, Dan Nicolaescu <dann <at> ics.uci.edu> wrote:

> Does it work if you have multiple *vc-dir* buffers for the same
> directory?
>
> C-u C-x v d /tmp/test RET Bzr RET
> C-u C-x v d /tmp/test RET Git RET

In this case, uniquify is unable to "fix" the names (because they are
identical), and reverts to using "*vc-dir*" and "*vc-dir*<2>".

We could work around it, by using the backend name as part of the
path, but it's quite hackish and horrible (there's nothing precluding
a directory being named "git" or "bzr").

If such double-VCS directories are common, I'd suggest using it as
part of the buffer name: "*vc-dir* [Bazaar]", "*vc-dir* [Git]", etc.
But that's unrelated to #3224.

> I'm fine with it if you convince Stefan this is TRTD.

OK, thanks.

    Juanma

Message #43 received at 3224 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 3224 <at> debbugs.gnu.org
Subject: Re: bug#3224: 23.0.92; vc-dir vs uniquify: wrong directory used
Date: Thu, 07 Jan 2010 14:53:44 -0500

>> So for vc-dir, you want "*vc-dir*" instead of A, right?  So you want
>> file names of the form "/foo/dir-1/*vc-dir*" and "/foo/dir-2/*vc-dir*".
> For such dired-style buffers, uniquify uses list-buffers-directory, so
> the only way is as I did in the patch I just sent.
> Do you want that patch installed, assuming Dan does not oppose it?

Yes, it looks OK.

>> Yes, the docstring has been wrong since day one
> Well, I'm glad we agree on this, then.

Feel free to rename it to uniquify-buffer-dir-name and adjust the docstring.

> (As an aside: the previous time we discussed this, you suggested that
> `list-buffers-directory' has the wrong name, and also that perhaps it
> would be safer/wiser to create another variable for uses like the one
> in uniquify. I think we should revisit this issue after the release.)

Agreed,


        Stefan

Message #46 received at 3224 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Dan Nicolaescu <dann <at> ics.uci.edu>
Cc: 3224 <at> debbugs.gnu.org
Subject: Re: bug#3224: 23.0.92; vc-dir vs uniquify: wrong directory used
Date: Thu, 07 Jan 2010 14:57:09 -0500

> Does it work if you have multiple *vc-dir* buffers for the same
> directory?
> Do something like:
> mkdir /tmp/test
> cd /tmp/test
> git init
> bzr init

> C-u C-x v d /tmp/test RET Bzr RET
> C-u C-x v d /tmp/test RET Git RET

Depending on what you mean by "work", I think it does work, but probably
not ideally.  To make it work better, maybe the backend name should
appear in the list-buffers-directory.  E.g.
/foo/bar/*vc-dir-BACKEND* or /foo/bar/BACKEND/*vc-dir*.
OTOH it should not be a common case, so maybe it's not that important to
make it work well.

> I'm fine with it if you convince Stefan this is TRTD.

It's what I use in PCL-CVS.


        Stefan

Message #49 received at 3224 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 3224 <at> debbugs.gnu.org
Subject: Re: bug#3224: 23.0.92; vc-dir vs uniquify: wrong directory used
Date: Fri, 8 Jan 2010 00:05:51 +0100

On Thu, Jan 7, 2010 at 20:53, Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:

> Feel free to rename it to uniquify-buffer-dir-name and adjust the docstring.

I'm not sure how to describe what it does. It returns the name of the
parent directory of the buffer; something like that.

BTW, in that function, this bit

	       (if (memq major-mode uniquify-list-buffers-directory-modes)
		   list-buffers-directory))))

and the whole `uniquify-list-buffers-directory-modes' seem a bit
redundant; adding a mode to the variable won't work unless the mode
function defines `list-buffers-directory', and even so, if the buffer
has a `buffer-file-name', `list-buffers-directory' won't be used. So
it would be easier to remove the variable and do the check so:

     (let ((filename
 	   (or buffer-file-name
-	       (if (memq major-mode uniquify-list-buffers-directory-modes)
-		   list-buffers-directory))))
+	       (bound-and-true-p list-buffers-directory))))
       (when filename
 	(directory-file-name

It is even more general, because any mode for buffers that do not have
a buffer-file-name but do define list-buffers-directory will
automatically work with uniquify.

    Juanma

Message #52 received at 3224 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 3224 <at> debbugs.gnu.org
Subject: Re: bug#3224: 23.0.92; vc-dir vs uniquify: wrong directory used
Date: Thu, 07 Jan 2010 22:22:19 -0500

> -	       (if (memq major-mode uniquify-list-buffers-directory-modes)
> -		   list-buffers-directory))))
> +	       (bound-and-true-p list-buffers-directory))))

Problem is that some modes use list-buffers-directory for incompatible
purposes.  E.g. shell-mode uses it to display the CWD of the shell in
the buffer-menu.


        Stefan

Message #57 received at 3224-done <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 3224-done <at> debbugs.gnu.org
Subject: Re: bug#3224: 23.0.92; vc-dir vs uniquify: wrong directory used
Date: Fri, 8 Jan 2010 04:40:33 +0100

On Fri, Jan 8, 2010 at 04:22, Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:

> Problem is that some modes use list-buffers-directory for incompatible
> purposes.  E.g. shell-mode uses it to display the CWD of the shell in
> the buffer-menu.

In the particular case of shell that would not cause trouble anyway;
shell for the same buffer name just pops to that buffer, and C-u M-x
shell calls `generate-new-buffer-name' and bypasses uniquify. AFAICS,
eshell does the same thing (C-u M-x eshell brings a "*eshell*<2>"
buffer).

But this is all best left post-release, for the introduction of a new variable.

I'm closing this bug now, as the patch is already installed.

    Juanma

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.