From: Bob Rogers <rogers@rgrjr.dyndns.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 7350@debbugs.gnu.org
Subject: bug#7350: 24.0.50; make vc-deduce-backend smarter
Date: Mon, 8 Nov 2010 16:05:43 -0500 [thread overview]
Message-ID: <19672.26151.150217.308712@rgr.rgrjr.com> (raw)
In-Reply-To: <jwv62w7u79o.fsf-monnier+emacs@gnu.org>
From: Stefan Monnier <monnier@iro.umontreal.ca>
Date: Mon, 08 Nov 2010 12:47:49 -0500
> Could you give an example use-case where you'd want vc-deduce-backend to
> be run in a shell-mode buffer?
> I have gotten into the habit of using a shell buffer to disambiguate
> which repo I want to use for general VC commands like vc-root-diff and
> vc-dir.
Hmm... I use a VC-Dir buffer for that ;-)
Me too -- when I'm already there. But if not, as I've said, it's
usually faster for me to go through the shell buffer. Besides, it also
avoids the annoying (and often unneeded) refresh from re-invoking
vc-dir.
> Since I bind "shell" to f8, it is often faster to type "f8 C-x
> v d RET" than to supply an explicit pathname to vc-dir. (I'm often in
> the right shell buffer already, having just typed "make test".)
I don't follow: if you're already in the right shell buffer, then f8
won't do anything.
Yes, and that saves me a keystroke. The point being that I frequently
find myself doing VC commands from the shell buffer anyway.
> Since vc-root-diff doesn't take a pathname arg, I have to do something
> explicit to get into the right tree anyway. So it makes sense to me
> that vc-root-diff should work like vc-dir in a non-VC buffer.
> There is already an exception for dired-mode; why not generalize?
It can definitely be generalized, but I'd rather stick to buffers where
there's a clear association with a particular file or directory.
E.g. *Help* buffers aren't good candidates.
Fair enough. Seems odd that default-directory is not nil for these.
shell-mode doesn't sound like a bad candidate, actually. The only
problem I see with it is that a shell buffer's default-directory is
easily out-of-sync with the underlying process's own notion of cwd.
In my experience, it's not too bad. I do find myself using
shell-resync-dirs now and then, but it's almost always after exiting a
subshell, and I've trained myself to resync when needed. (Maybe the
shell-dirtrack thing should resync automatically when it sees "exit"?)
Does the patch below solve your immediate problem?
Works for me. It doesn't cover the cases where I'm looking at a
generated file, or test output, but (in my workflow anyway) those cases
are rarer.
> In fact, this is something of a regression from Emacs 22.x, where
> "C-u C-x v = . RET RET RET" would do the equivalent of
> (vc-version-diff (expand-file-name ".") nil nil)
> which is nearly vc-root-diff, regardless of buffer mode. This no longer
> works in the brave new world of filesets,
This was the result of a trade-off (get rid of one RET since it's
almost never used). But I guess we could/should prompt the user for
a file/dir rather than signal "File is not under version control" or
some such error.
Stefan
That would be much nicer, especially since the underlying functionality
(i.e. support for vc-diff of directories) still works.
-- Bob
P.S. I mailed the signed copyright assignment today, so FSF should have
it tomorrow.
next prev parent reply other threads:[~2010-11-08 21:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-06 22:18 bug#7350: 24.0.50; make vc-deduce-backend smarter Bob Rogers
2010-11-07 20:03 ` Stefan Monnier
2010-11-07 21:41 ` Bob Rogers
2010-11-08 17:47 ` Stefan Monnier
2010-11-08 21:05 ` Bob Rogers [this message]
2010-11-12 13:48 ` Stefan Monnier
2010-11-14 23:21 ` Bob Rogers
2010-11-15 16:05 ` Stefan Monnier
2010-11-17 4:43 ` Bob Rogers
2010-11-17 13:31 ` Stefan Monnier
2010-11-19 2:27 ` Bob Rogers
2010-11-20 19:54 ` Bob Rogers
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=19672.26151.150217.308712@rgr.rgrjr.com \
--to=rogers@rgrjr.dyndns.org \
--cc=7350@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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.