unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Dan Nicolaescu <dann@ics.uci.edu>
To: Juanma Barranquero <lekktu@gmail.com>
Cc: 3224@debbugs.gnu.org
Subject: bug#3224: 23.0.92; vc-dir vs uniquify: wrong directory used
Date: Thu, 7 Jan 2010 07:10:15 -0800 (PST)	[thread overview]
Message-ID: <201001071510.o07FAFip016867@godzilla.ics.uci.edu> (raw)
In-Reply-To: <f7ccd24b1001070314k6114cbcep296ad50dc44eb533@mail.gmail.com> (Juanma Barranquero's message of "Thu, 7 Jan 2010 12:14:01 +0100")

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.








  parent reply	other threads:[~2010-01-07 15:10 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
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 [this message]
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=201001071510.o07FAFip016867@godzilla.ics.uci.edu \
    --to=dann@ics.uci.edu \
    --cc=3224@debbugs.gnu.org \
    --cc=lekktu@gmail.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 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).