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

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

[Magnus Henoch]

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

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

[Dan Nicolaescu]

Magnus Henoch <mange@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@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.

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

[Juanma Barranquero]

On Tue, Aug 4, 2009 at 13:30, Dan Nicolaescu <dann@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@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

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

[Dan Nicolaescu]

Juanma Barranquero <lekktu@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.

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

[Stefan Monnier]

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

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

[Juanma Barranquero]

On Wed, Jan 6, 2010 at 06:38, Stefan Monnier <monnier@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

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

[Stefan Monnier]

> 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

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

[Juanma Barranquero]

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.

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

[Stefan Monnier]

> 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

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

[Juanma Barranquero]

On Thu, Jan 7, 2010 at 15:54, Stefan Monnier <monnier@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

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

[Stefan Monnier]

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

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

[Juanma Barranquero]

On Thu, Jan 7, 2010 at 20:53, Stefan Monnier <monnier@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

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

[Stefan Monnier]

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

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

[Dan Nicolaescu]

Juanma Barranquero <lekktu@gmail.com> writes:

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

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.

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

[Juanma Barranquero]

On Thu, Jan 7, 2010 at 16:10, Dan Nicolaescu <dann@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

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

[Stefan Monnier]

> 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

bug#3224: marked as done (23.0.92; vc-dir vs uniquify: wrong directory used)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 886 bytes --]

Your message dated Fri, 8 Jan 2010 04:40:33 +0100
with message-id <f7ccd24b1001071940k28f0f35y508b7f1c26640f9f@mail.gmail.com>
and subject line Re: bug#3224: 23.0.92; vc-dir vs uniquify: wrong directory used
has caused the Emacs bug report #3224,
regarding 23.0.92; vc-dir vs uniquify: wrong directory used
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact bug-gnu-emacs@gnu.org
immediately.)


-- 
3224: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3224
Emacs Bug Tracking System
Contact bug-gnu-emacs@gnu.org with problems

[-- Attachment #2: Type: message/rfc822, Size: 6173 bytes --]

From: Magnus Henoch <mange@freemail.hu>
To: emacs-pretest-bug@gnu.org
Subject: 23.0.92; vc-dir vs uniquify: wrong directory used
Date: Tue, 05 May 2009 16:19:07 +0100
Message-ID: <84my9rfuhg.fsf@linux-b2a3.site>


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



[-- Attachment #3: Type: message/rfc822, Size: 4041 bytes --]

From: Juanma Barranquero <lekktu@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 3224-done@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
Message-ID: <f7ccd24b1001071940k28f0f35y508b7f1c26640f9f@mail.gmail.com>

On Fri, Jan 8, 2010 at 04:22, Stefan Monnier <monnier@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

bug#4553: 23.1; uniquify gives *vc-dir* buffer the wrong name

[Tom Tromey]

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 bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

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


I have a *vc-dir* buffer opened on a directory:

    VC backend : Git
    Working dir: ~/gnu/archer/archer/
    Branch     : archer-tromey-python
    [...]

And, I have:

    uniquify-buffer-name-style is a variable defined in `uniquify.el'.
    Its value is 
    post-forward-angle-brackets

    uniquify-strip-common-suffix is a variable defined in `uniquify.el'.
    Its value is t

However, the aforementioned buffer is named *vc-dir*<testsuite>.
This is simply wrong.  I think I would expect *vc-dir*<archer>.

I managed to get one named *vc-dir*</tmp> as well.  I don't know how,
but that one was also clearly wrong, as the directory in question was in
/home/tromey, not /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/share/emacs/23.1/etc/DEBUG for instructions.


In GNU Emacs 23.1.1 (i386-redhat-linux-gnu, GTK+ Version 2.16.5)
 of 2009-08-26 on x86-2.fedora.phx.redhat.com
Windowing system distributor `The X.Org Foundation', version 11.0.10601901
configured using `configure  '--build=i386-redhat-linux-gnu' '--host=i386-redhat-linux-gnu' '--target=i586-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-dbus' '--with-gif' '--with-jpeg' '--with-png' '--with-rsvg' '--with-tiff' '--with-xft' '--with-xpm' '--with-x-toolkit=gtk' 'build_alias=i386-redhat-linux-gnu' 'host_alias=i386-redhat-linux-gnu' 'target_alias=i586-redhat-linux-gnu' 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-bu
 ffer-size=4 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  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: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Group

Minor modes in effect:
  gnus-agent-mode: t
  shell-dirtrack-mode: t
  erc-list-mode: t
  erc-menu-mode: t
  erc-autojoin-mode: t
  erc-ring-mode: t
  erc-pcomplete-mode: t
  erc-track-mode: t
  erc-track-minor-mode: t
  erc-match-mode: t
  erc-button-mode: t
  erc-fill-mode: t
  erc-stamp-mode: t
  erc-netsplit-mode: t
  erc-spelling-mode: t
  erc-truncate-mode: t
  diff-auto-refine-mode: t
  gnus-undo-mode: t
  erc-status-mode: t
  erc-services-mode: t
  erc-networks-mode: t
  erc-irccontrols-mode: t
  erc-noncommands-mode: t
  erc-move-to-prompt-mode: t
  erc-readonly-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-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:
n SPC 5 0 <return> M-> q C-v C-u C-u C-n C-u C-n C-u 
C-n n n SPC 5 0 <return> M-> C-p C-p C-p SPC E SPC 
E S-SPC E SPC q s M-v M-v M-v C-z o C-x b # g d b <return> 
d j <tab> C-a C-k I SPC r e b u i l t SPC a n d SPC 
t h e SPC t e s t SPC s t i l l SPC p a s s C-a M-f 
SPC u p d a t e d , <backspace> SPC & S-SPC M-SPC C-e 
s <backspace> e s SPC f o r SPC m e <return> <f10> 
<f10> <f10> C-z o C-l n n n M-g M-g M-g p SPC c SPC 
s C-u C-n = 9 7 <return> M-> Q y C-z o <f10> <f10> 
C-z o C-z o <f10> <f10> <f10> <switch-frame> <switch-frame> 
C-z o C-s r <backspace> f r y C-a SPC 5 0 <return> 
C-u C-n n SPC C-z o <f10> <f10> <f10> <f10> <f10> <f10> 
<f10> <f10> C-z o <help-echo> <down-mouse-5> <mouse-5> 
<double-down-mouse-5> <double-mouse-5> M SPC <down> 
<down> <down> <down> <down> SPC <down-mouse-5> <mouse-5> 
= Q y s <help-echo> C-z o <f10> <f10> <f10> <f10> <f10> 
<f10> C-x b * v c - d i r <tab> <tab> < a r <M-backspace> 
/ t <tab> <return> C-x k <return> C-x b * v c - d <tab> 
<tab> <tab> r <tab> <tab> <return> C-x k <return> C-x 
b * v c - d i r <tab> <tab> g d <tab> <return> C-x 
v * C-g C-x v d <M-backspace> <M-backspace> <M-backspace> 
<M-backspace> a r <tab> a r <tab> <return> C-x 1 C-z 
o M-x r e p o r t - e m <tab> <return> b <tab> <re
turn>

Recent messages:
Generating summary...done
Discard changes to this group and exit? (y or n) 
(No changes need to be saved)
Saving /home/tromey/.newsrc.eld...
Saving file /home/tromey/.newsrc.eld...
Wrote /home/tromey/.newsrc.eld
Saving /home/tromey/.newsrc.eld...done
Making completion list... [4 times]
Quit
Making completion list...

Tom

bug#4553: 23.1; uniquify gives *vc-dir* buffer the wrong name

[Dan Nicolaescu]

forcemerge 3224 4553 
quit

Tom Tromey <tromey@redhat.com> writes:

  > I have a *vc-dir* buffer opened on a directory:
  > 
  >     VC backend : Git
  >     Working dir: ~/gnu/archer/archer/
  >     Branch     : archer-tromey-python
  >     [...]
  > 
  > And, I have:
  > 
  >     uniquify-buffer-name-style is a variable defined in `uniquify.el'.
  >     Its value is 
  >     post-forward-angle-brackets
  > 
  >     uniquify-strip-common-suffix is a variable defined in `uniquify.el'.
  >     Its value is t
  > 
  > However, the aforementioned buffer is named *vc-dir*<testsuite>.
  > This is simply wrong.  I think I would expect *vc-dir*<archer>.
  > 
  > I managed to get one named *vc-dir*</tmp> as well.  I don't know how,
  > but that one was also clearly wrong, as the directory in question was in
  > /home/tromey, not /tmp.

This is the same a Bug#3224.
Please comment on the info there.

Processed: Re: bug#4553: 23.1; uniquify gives *vc-dir* buffer the wrong name

[Emacs bug Tracking System]

Processing commands for control@emacsbugs.donarmstrong.com:

> forcemerge 3224 4553
bug#3224: 23.0.92; vc-dir vs uniquify: wrong directory used
bug#4553: 23.1; uniquify gives *vc-dir* buffer the wrong name
Forcibly Merged 3224 4553.

> quit
Stopping processing here.

Please contact me if you need assistance.

Don Armstrong
(administrator, Emacs bugs database)

bug#4553: marked as done (23.1; uniquify gives *vc-dir* buffer the wrong name)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 888 bytes --]

Your message dated Fri, 8 Jan 2010 04:40:33 +0100
with message-id <f7ccd24b1001071940k28f0f35y508b7f1c26640f9f@mail.gmail.com>
and subject line Re: bug#3224: 23.0.92; vc-dir vs uniquify: wrong directory used
has caused the Emacs bug report #3224,
regarding 23.1; uniquify gives *vc-dir* buffer the wrong name
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact bug-gnu-emacs@gnu.org
immediately.)


-- 
3224: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3224
Emacs Bug Tracking System
Contact bug-gnu-emacs@gnu.org with problems

[-- Attachment #2: Type: message/rfc822, Size: 7762 bytes --]

From: Tom Tromey <tromey@redhat.com>
To: bug-gnu-emacs@gnu.org
Subject: 23.1; uniquify gives *vc-dir* buffer the wrong name
Date: Thu, 24 Sep 2009 14:53:12 -0600
Message-ID: <m3skecawuf.fsf@fleche.redhat.com>


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 bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

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


I have a *vc-dir* buffer opened on a directory:

    VC backend : Git
    Working dir: ~/gnu/archer/archer/
    Branch     : archer-tromey-python
    [...]

And, I have:

    uniquify-buffer-name-style is a variable defined in `uniquify.el'.
    Its value is 
    post-forward-angle-brackets

    uniquify-strip-common-suffix is a variable defined in `uniquify.el'.
    Its value is t

However, the aforementioned buffer is named *vc-dir*<testsuite>.
This is simply wrong.  I think I would expect *vc-dir*<archer>.

I managed to get one named *vc-dir*</tmp> as well.  I don't know how,
but that one was also clearly wrong, as the directory in question was in
/home/tromey, not /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/share/emacs/23.1/etc/DEBUG for instructions.


In GNU Emacs 23.1.1 (i386-redhat-linux-gnu, GTK+ Version 2.16.5)
 of 2009-08-26 on x86-2.fedora.phx.redhat.com
Windowing system distributor `The X.Org Foundation', version 11.0.10601901
configured using `configure  '--build=i386-redhat-linux-gnu' '--host=i386-redhat-linux-gnu' '--target=i586-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-dbus' '--with-gif' '--with-jpeg' '--with-png' '--with-rsvg' '--with-tiff' '--with-xft' '--with-xpm' '--with-x-toolkit=gtk' 'build_alias=i386-redhat-linux-gnu' 'host_alias=i386-redhat-linux-gnu' 'target_alias=i586-redhat-linux-gnu' 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-bu
 ffer-size=4 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  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: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Group

Minor modes in effect:
  gnus-agent-mode: t
  shell-dirtrack-mode: t
  erc-list-mode: t
  erc-menu-mode: t
  erc-autojoin-mode: t
  erc-ring-mode: t
  erc-pcomplete-mode: t
  erc-track-mode: t
  erc-track-minor-mode: t
  erc-match-mode: t
  erc-button-mode: t
  erc-fill-mode: t
  erc-stamp-mode: t
  erc-netsplit-mode: t
  erc-spelling-mode: t
  erc-truncate-mode: t
  diff-auto-refine-mode: t
  gnus-undo-mode: t
  erc-status-mode: t
  erc-services-mode: t
  erc-networks-mode: t
  erc-irccontrols-mode: t
  erc-noncommands-mode: t
  erc-move-to-prompt-mode: t
  erc-readonly-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-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:
n SPC 5 0 <return> M-> q C-v C-u C-u C-n C-u C-n C-u 
C-n n n SPC 5 0 <return> M-> C-p C-p C-p SPC E SPC 
E S-SPC E SPC q s M-v M-v M-v C-z o C-x b # g d b <return> 
d j <tab> C-a C-k I SPC r e b u i l t SPC a n d SPC 
t h e SPC t e s t SPC s t i l l SPC p a s s C-a M-f 
SPC u p d a t e d , <backspace> SPC & S-SPC M-SPC C-e 
s <backspace> e s SPC f o r SPC m e <return> <f10> 
<f10> <f10> C-z o C-l n n n M-g M-g M-g p SPC c SPC 
s C-u C-n = 9 7 <return> M-> Q y C-z o <f10> <f10> 
C-z o C-z o <f10> <f10> <f10> <switch-frame> <switch-frame> 
C-z o C-s r <backspace> f r y C-a SPC 5 0 <return> 
C-u C-n n SPC C-z o <f10> <f10> <f10> <f10> <f10> <f10> 
<f10> <f10> C-z o <help-echo> <down-mouse-5> <mouse-5> 
<double-down-mouse-5> <double-mouse-5> M SPC <down> 
<down> <down> <down> <down> SPC <down-mouse-5> <mouse-5> 
= Q y s <help-echo> C-z o <f10> <f10> <f10> <f10> <f10> 
<f10> C-x b * v c - d i r <tab> <tab> < a r <M-backspace> 
/ t <tab> <return> C-x k <return> C-x b * v c - d <tab> 
<tab> <tab> r <tab> <tab> <return> C-x k <return> C-x 
b * v c - d i r <tab> <tab> g d <tab> <return> C-x 
v * C-g C-x v d <M-backspace> <M-backspace> <M-backspace> 
<M-backspace> a r <tab> a r <tab> <return> C-x 1 C-z 
o M-x r e p o r t - e m <tab> <return> b <tab> <re
turn>

Recent messages:
Generating summary...done
Discard changes to this group and exit? (y or n) 
(No changes need to be saved)
Saving /home/tromey/.newsrc.eld...
Saving file /home/tromey/.newsrc.eld...
Wrote /home/tromey/.newsrc.eld
Saving /home/tromey/.newsrc.eld...done
Making completion list... [4 times]
Quit
Making completion list...

Tom



[-- Attachment #3: Type: message/rfc822, Size: 4041 bytes --]

From: Juanma Barranquero <lekktu@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 3224-done@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
Message-ID: <f7ccd24b1001071940k28f0f35y508b7f1c26640f9f@mail.gmail.com>

On Fri, Jan 8, 2010 at 04:22, Stefan Monnier <monnier@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