GNU bug report logs -
#50344
C-x v keybinding for vc-print-branch-log
Previous Next
Reported by: Juri Linkov <juri <at> linkov.net>
Date: Thu, 2 Sep 2021 18:46:01 UTC
Severity: wishlist
Fixed in version 29.0.50
Done: Juri Linkov <juri <at> linkov.net>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 50344 in the body.
You can then email your comments to 50344 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 02 Sep 2021 18:46:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Juri Linkov <juri <at> linkov.net>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 02 Sep 2021 18:46:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
While vc-print-branch-log is a frequently used command, it still has no
keybinding in vc-prefix-map. But it has a keybinding in vc-dir-mode-map.
Many keys are already shared between vc-prefix-map and vc-dir-mode-map, e.g.:
(defvar vc-dir-mode-map
;; VC commands
(define-key map "v" #'vc-next-action) ;; C-x v v
(define-key map "=" #'vc-diff) ;; C-x v =
(define-key map "D" #'vc-root-diff) ;; C-x v D
(define-key map "i" #'vc-register) ;; C-x v i
(define-key map "+" #'vc-update) ;; C-x v +
(define-key map "P" #'vc-push) ;; C-x v P
(define-key map "l" #'vc-print-log) ;; C-x v l
(define-key map "L" #'vc-print-root-log) ;; C-x v L
(define-key map "I" #'vc-log-incoming) ;; C-x v I
(define-key map "O" #'vc-log-outgoing) ;; C-x v O
Also vc-dir-mode-map has branch keys:
(let ((branch-map (make-sparse-keymap)))
(define-key map "B" branch-map)
(define-key branch-map "c" #'vc-create-tag)
(define-key branch-map "l" #'vc-print-branch-log)
(define-key branch-map "s" #'vc-retrieve-tag))
So it makes sense to copy branch keys from vc-dir-mode-map
to vc-prefix-map:
diff --git a/lisp/vc/vc-hooks.el b/lisp/vc/vc-hooks.el
index 4b3c829a2c..d039c400c5 100644
--- a/lisp/vc/vc-hooks.el
+++ b/lisp/vc/vc-hooks.el
@@ -865,6 +865,9 @@ vc-prefix-map
(let ((map (make-sparse-keymap)))
(define-key map "a" #'vc-update-change-log)
(define-key map "b" #'vc-switch-backend)
+ (define-key map "Bc" #'vc-create-tag)
+ (define-key map "Bl" #'vc-print-branch-log)
+ (define-key map "Bs" #'vc-retrieve-tag)
(define-key map "d" #'vc-dir)
(define-key map "g" #'vc-annotate)
(define-key map "G" #'vc-ignore)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 02 Sep 2021 23:25:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 50344 <at> debbugs.gnu.org (full text, mbox):
On 02.09.2021 21:43, Juri Linkov wrote:
> So it makes sense to copy branch keys from vc-dir-mode-map
> to vc-prefix-map:
>
> diff --git a/lisp/vc/vc-hooks.el b/lisp/vc/vc-hooks.el
> index 4b3c829a2c..d039c400c5 100644
> --- a/lisp/vc/vc-hooks.el
> +++ b/lisp/vc/vc-hooks.el
> @@ -865,6 +865,9 @@ vc-prefix-map
> (let ((map (make-sparse-keymap)))
> (define-key map "a" #'vc-update-change-log)
> (define-key map "b" #'vc-switch-backend)
> + (define-key map "Bc" #'vc-create-tag)
> + (define-key map "Bl" #'vc-print-branch-log)
> + (define-key map "Bs" #'vc-retrieve-tag)
> (define-key map "d" #'vc-dir)
> (define-key map "g" #'vc-annotate)
> (define-key map "G" #'vc-ignore)
Makes sense to me as well. Thanks!
Do we want to remove the vc-retrieve-tag from 'C-x v r' sometime later?
It does have a dual function (branches/tags and commits as well), but it
would be nice to free this combination.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Fri, 03 Sep 2021 08:20:03 GMT)
Full text and
rfc822 format available.
Message #11 received at 50344 <at> debbugs.gnu.org (full text, mbox):
>> + (define-key map "Bc" #'vc-create-tag)
>> + (define-key map "Bl" #'vc-print-branch-log)
>> + (define-key map "Bs" #'vc-retrieve-tag)
>
> Makes sense to me as well. Thanks!
>
> Do we want to remove the vc-retrieve-tag from 'C-x v r' sometime later?
I guess, yes. But is it possible to deprecate a keybinding like
there are 'make-obsolete' for functions and 'make-obsolete-variable'?
> It does have a dual function (branches/tags and commits as well), but it would
> be nice to free this combination.
Do you mean to create two separate commands and separate keybindings
for switching a branch vs tags?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Fri, 03 Sep 2021 12:27:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 50344 <at> debbugs.gnu.org (full text, mbox):
On 03.09.2021 11:15, Juri Linkov wrote:
>>> + (define-key map "Bc" #'vc-create-tag)
>>> + (define-key map "Bl" #'vc-print-branch-log)
>>> + (define-key map "Bs" #'vc-retrieve-tag)
>>
>> Makes sense to me as well. Thanks!
>>
>> Do we want to remove the vc-retrieve-tag from 'C-x v r' sometime later?
>
> I guess, yes. But is it possible to deprecate a keybinding like
> there are 'make-obsolete' for functions and 'make-obsolete-variable'?
Probably not. Only by writing in the NEWS, or something.
>> It does have a dual function (branches/tags and commits as well), but it would
>> be nice to free this combination.
>
> Do you mean to create two separate commands and separate keybindings
> for switching a branch vs tags?
No, just removing one binding. It's not urgent or very important, just
something to think about.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Fri, 03 Sep 2021 16:22:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 50344 <at> debbugs.gnu.org (full text, mbox):
>> + (define-key map "Bc" #'vc-create-tag)
>> + (define-key map "Bl" #'vc-print-branch-log)
>> + (define-key map "Bs" #'vc-retrieve-tag)
>
> Do we want to remove the vc-retrieve-tag from 'C-x v r' sometime later? It
> does have a dual function (branches/tags and commits as well), but it would
> be nice to free this combination.
I think we want more to remove another duplicate key 'C-x v s'
because then we could bind it to 'vc-log-search'.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Fri, 03 Sep 2021 16:42:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 50344 <at> debbugs.gnu.org (full text, mbox):
On 03.09.2021 19:18, Juri Linkov wrote:
> I think we want more to remove another duplicate key 'C-x v s'
> because then we could bind it to 'vc-log-search'.
That works for me. And indeed vc-log-search seems more important.
What do others think?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Sat, 04 Sep 2021 06:34:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 50344 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> On 03.09.2021 19:18, Juri Linkov wrote:
>> I think we want more to remove another duplicate key 'C-x v s'
>> because then we could bind it to 'vc-log-search'.
>
> That works for me. And indeed vc-log-search seems more important.
>
> What do others think?
Then it would be only on `B c' in vc-dir-mode? `C-x v s' isn't very
mnemonic, but would removing it from global map inconvenience people?
(I've never used it myself.)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Sun, 05 Sep 2021 16:42:04 GMT)
Full text and
rfc822 format available.
Message #26 received at 50344 <at> debbugs.gnu.org (full text, mbox):
>>> I think we want more to remove another duplicate key 'C-x v s'
>>> because then we could bind it to 'vc-log-search'.
>>
>> That works for me. And indeed vc-log-search seems more important.
>>
>> What do others think?
>
> Then it would be only on `B c' in vc-dir-mode? `C-x v s' isn't very
> mnemonic, but would removing it from global map inconvenience people?
> (I've never used it myself.)
Indeed, it seems there is no way to remove old keybindings, especially
by rebinding them to other commands, so I propose to add new keybindings:
diff --git a/lisp/vc/vc-hooks.el b/lisp/vc/vc-hooks.el
index 4b3c829a2c..4d3f642796 100644
--- a/lisp/vc/vc-hooks.el
+++ b/lisp/vc/vc-hooks.el
@@ -865,6 +865,9 @@ vc-prefix-map
(let ((map (make-sparse-keymap)))
(define-key map "a" #'vc-update-change-log)
(define-key map "b" #'vc-switch-backend)
+ (define-key map "Bc" #'vc-create-tag)
+ (define-key map "Bl" #'vc-print-branch-log)
+ (define-key map "Bs" #'vc-retrieve-tag)
(define-key map "d" #'vc-dir)
(define-key map "g" #'vc-annotate)
(define-key map "G" #'vc-ignore)
@@ -879,6 +882,7 @@ vc-prefix-map
(define-key map "m" #'vc-merge)
(define-key map "r" #'vc-retrieve-tag)
(define-key map "s" #'vc-create-tag)
+ (define-key map "S" #'vc-log-search)
(define-key map "u" #'vc-revert)
(define-key map "v" #'vc-next-action)
(define-key map "+" #'vc-update)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Mon, 06 Sep 2021 08:26:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 50344 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
>> Then it would be only on `B c' in vc-dir-mode? `C-x v s' isn't very
>> mnemonic, but would removing it from global map inconvenience people?
>> (I've never used it myself.)
>
> Indeed, it seems there is no way to remove old keybindings, especially
> by rebinding them to other commands, so I propose to add new keybindings:
We do remove old keybindings if we think that makes sense. Like I said,
I've never used that command myself, ever, so I was wondering whether
that was generally the case. If we believe that it's a rarely used
binding, then we could indeed remove it (or use it for something else).
(Especially since it seems quite un-mnemonic currently.)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Mon, 06 Sep 2021 15:42:03 GMT)
Full text and
rfc822 format available.
Message #32 received at 50344 <at> debbugs.gnu.org (full text, mbox):
>>> Then it would be only on `B c' in vc-dir-mode? `C-x v s' isn't very
>>> mnemonic, but would removing it from global map inconvenience people?
>>> (I've never used it myself.)
>>
>> Indeed, it seems there is no way to remove old keybindings, especially
>> by rebinding them to other commands, so I propose to add new keybindings:
>
> We do remove old keybindings if we think that makes sense. Like I said,
> I've never used that command myself, ever, so I was wondering whether
> that was generally the case. If we believe that it's a rarely used
> binding, then we could indeed remove it (or use it for something else).
>
> (Especially since it seems quite un-mnemonic currently.)
I don't know, if someone types a familiar key and it does
something completely different...
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Tue, 07 Sep 2021 15:06:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 50344 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
> I don't know, if someone types a familiar key and it does
> something completely different...
Yeah, I didn't mean rebind it immediately -- we can remove the binding
now, and then reuse the binding in a couple of releases.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Wed, 08 Sep 2021 02:51:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 50344 <at> debbugs.gnu.org (full text, mbox):
On 04.09.2021 09:33, Lars Ingebrigtsen wrote:
>> On 03.09.2021 19:18, Juri Linkov wrote:
>>> I think we want more to remove another duplicate key 'C-x v s'
>>> because then we could bind it to 'vc-log-search'.
>>
>> That works for me. And indeed vc-log-search seems more important.
>>
>> What do others think?
>
> Then it would be only on `B c' in vc-dir-mode?
Yup.
> `C-x v s' isn't very
> mnemonic,
Apparently the original name was "snapshot". Like, when you create a
tag, you snapshot the whole current state of the repo.
See commit 370fded4f6c where the mass renaming was made.
> but would removing it from global map inconvenience people?
> (I've never used it myself.)
I don't use a whole bunch of commands that are easy to type in the
console (and fish completion helps a lot), so maybe others will chime in.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Wed, 08 Sep 2021 02:59:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 50344 <at> debbugs.gnu.org (full text, mbox):
On 07.09.2021 18:05, Lars Ingebrigtsen wrote:
> Juri Linkov<juri <at> linkov.net> writes:
>
>> I don't know, if someone types a familiar key and it does
>> something completely different...
As long as it doesn't do anything dangerous right away, that could fly.
Of course, people can still complain. Depends on how popular it is.
> Yeah, I didn't mean rebind it immediately -- we can remove the binding
> now, and then reuse the binding in a couple of releases.
Speaking of (re)moving bindings: 'C-x v b' (vc-switch-backend) seems
particularly useless. If it weren't there, the newly added branch
commands could use the nicer prefix instead of 'C-x v B'. branch-map in
vc-dir could also be changed to use 'b' (not sure why 'B' was chosen
there originally: there is no conflict).
Maybe vc-switch-backend sees some occasional use, but moving it to
something like 'C-x v B' would be more appropriate. Or some other
longer/complex sequence.
If we do this the conservative way, though, the whole procedure can span
half a decade:
- Move vc-switch-backend to 'C-x v B' (Emacs 28)
- Move branch-map to 'b' and vc-create-tag to 'C-x v b c' (Emacs 29)
- Finally move vc-search-log to 'C-x v s' (Emacs 30)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Wed, 08 Sep 2021 07:54:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 50344 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
>> `C-x v s' isn't very
>> mnemonic,
>
> Apparently the original name was "snapshot". Like, when you create a
> tag, you snapshot the whole current state of the repo.
Ah, I see -- that makes sense.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Wed, 08 Sep 2021 08:01:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 50344 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> Speaking of (re)moving bindings: 'C-x v b' (vc-switch-backend) seems
> particularly useless.
Oh, wow. What's the use case for that command? I can't imagine when
that would actually do something useful... And it's a really old
command, too -- perhaps this was something that made sense in an RCS
world?
> If we do this the conservative way, though, the whole procedure can
> span half a decade:
>
> - Move vc-switch-backend to 'C-x v B' (Emacs 28)
> - Move branch-map to 'b' and vc-create-tag to 'C-x v b c' (Emacs 29)
> - Finally move vc-search-log to 'C-x v s' (Emacs 30)
We could do the first two steps in Emacs 28, perhaps -- if anybody's
actually using `C-x v b', they'll then get
C-x v b-
in the echo area, which should tell them that something's different is
happening now...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Wed, 08 Sep 2021 12:00:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 50344 <at> debbugs.gnu.org (full text, mbox):
On 08.09.2021 11:00, Lars Ingebrigtsen wrote:
> Dmitry Gutov <dgutov <at> yandex.ru> writes:
>
>> Speaking of (re)moving bindings: 'C-x v b' (vc-switch-backend) seems
>> particularly useless.
>
> Oh, wow. What's the use case for that command? I can't imagine when
> that would actually do something useful... And it's a really old
> command, too -- perhaps this was something that made sense in an RCS
> world?
I think it's for the case of nested repositories, like in bug#42966 and
other linked reports. And perhaps our detection might make the wrong
choice, thus it can be tweaked manually.
I don't have any specific scenario in mind, though. Or personal
experience with such nesting.
>> If we do this the conservative way, though, the whole procedure can
>> span half a decade:
>>
>> - Move vc-switch-backend to 'C-x v B' (Emacs 28)
>> - Move branch-map to 'b' and vc-create-tag to 'C-x v b c' (Emacs 29)
>> - Finally move vc-search-log to 'C-x v s' (Emacs 30)
>
> We could do the first two steps in Emacs 28, perhaps -- if anybody's
> actually using `C-x v b', they'll then get
>
> C-x v b-
>
> in the echo area, which should tell them that something's different is
> happening now...
Works for me.
Juri, what do you say?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 09 Sep 2021 17:59:03 GMT)
Full text and
rfc822 format available.
Message #53 received at 50344 <at> debbugs.gnu.org (full text, mbox):
>>> Speaking of (re)moving bindings: 'C-x v b' (vc-switch-backend) seems
>>> particularly useless.
>> Oh, wow. What's the use case for that command? I can't imagine when
>> that would actually do something useful... And it's a really old
>> command, too -- perhaps this was something that made sense in an RCS
>> world?
>
> I think it's for the case of nested repositories, like in bug#42966 and
> other linked reports. And perhaps our detection might make the wrong
> choice, thus it can be tweaked manually.
>
> I don't have any specific scenario in mind, though. Or personal experience
> with such nesting.
>
>>> If we do this the conservative way, though, the whole procedure can
>>> span half a decade:
>>>
>>> - Move vc-switch-backend to 'C-x v B' (Emacs 28)
>>> - Move branch-map to 'b' and vc-create-tag to 'C-x v b c' (Emacs 29)
>>> - Finally move vc-search-log to 'C-x v s' (Emacs 30)
>> We could do the first two steps in Emacs 28, perhaps -- if anybody's
>> actually using `C-x v b', they'll then get
>> C-x v b-
>> in the echo area, which should tell them that something's different is
>> happening now...
>
> Works for me.
>
> Juri, what do you say?
I think in the long-term it would be nice to have these keybindings:
C-x v B - vc-switch-backend
C-x v b c - vc-create-tag (maybe it should have an alias 'vc-create-branch'?)
C-x v b l - vc-print-branch-log
C-x v b s - vc-retrieve-tag (maybe it should have an alias 'vc-switch-branch'?)
C-x v s - vc-log-search
C-x v r - free, any ideas what to bind to it?
Since `C-x v b' will show "C-x v b-" in the echo area,
and `C-x v s' will show "Search log with pattern: " in the minibuffer.
and `C-x v r' will show "C-x v r is undefined",
I see no problem in adding all keybindings before the next release.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 09 Sep 2021 23:19:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 50344 <at> debbugs.gnu.org (full text, mbox):
On 09.09.2021 20:39, Juri Linkov wrote:
>> Juri, what do you say?
>
> I think in the long-term it would be nice to have these keybindings:
>
> C-x v B - vc-switch-backend
> C-x v b c - vc-create-tag (maybe it should have an alias 'vc-create-branch'?)
> C-x v b l - vc-print-branch-log
> C-x v b s - vc-retrieve-tag (maybe it should have an alias 'vc-switch-branch'?)
> C-x v s - vc-log-search
> C-x v r - free, any ideas what to bind to it?
vc-rename-file, perhaps?
> Since `C-x v b' will show "C-x v b-" in the echo area,
> and `C-x v s' will show "Search log with pattern: " in the minibuffer.
> and `C-x v r' will show "C-x v r is undefined",
> I see no problem in adding all keybindings before the next release.
It's a bit too optimistic even for me. But no objections, really.
I'd like to leave it up to Lars to choose the exact line between being
conservative and bringing better bindings to the users sooner.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Fri, 10 Sep 2021 06:58:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 50344 <at> debbugs.gnu.org (full text, mbox):
>> C-x v B - vc-switch-backend
>> C-x v b c - vc-create-tag (maybe it should have an alias 'vc-create-branch'?)
>> C-x v b l - vc-print-branch-log
>> C-x v b s - vc-retrieve-tag (maybe it should have an alias 'vc-switch-branch'?)
>> C-x v s - vc-log-search
>> C-x v r - free, any ideas what to bind to it?
>
> vc-rename-file, perhaps?
Or use it as a prefix key to allow more keybindings, e.g.
with mnemonics "revision" to navigate the history like
in vc-annotate: 'C-x v r n' (revision-next), 'C-x v r p' (previous), ...
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Fri, 10 Sep 2021 10:33:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 50344 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
> I think in the long-term it would be nice to have these keybindings:
>
> C-x v B - vc-switch-backend
> C-x v b c - vc-create-tag (maybe it should have an alias 'vc-create-branch'?)
> C-x v b l - vc-print-branch-log
> C-x v b s - vc-retrieve-tag (maybe it should have an alias 'vc-switch-branch'?)
> C-x v s - vc-log-search
> C-x v r - free, any ideas what to bind to it?
>
> Since `C-x v b' will show "C-x v b-" in the echo area,
> and `C-x v s' will show "Search log with pattern: " in the minibuffer.
> and `C-x v r' will show "C-x v r is undefined",
> I see no problem in adding all keybindings before the next release.
It's an ambitious rebinding... but the new bindings are clearly an
improvement, and none of the commands that are being rebound to/from are
things that "do things immediately", but instead prompt for further
input, so the potential for this to destroy people's repositories should be
lessened.
But... perhaps we should take this to emacs-devel to see whether other
people feel differently?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Fri, 10 Sep 2021 11:27:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 50344 <at> debbugs.gnu.org (full text, mbox):
On 10.09.2021 13:32, Lars Ingebrigtsen wrote:
> But... perhaps we should take this to emacs-devel to see whether other
> people feel differently?
Some people might feel the desire to express general objection to seeing
anything changed.
But sure.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Fri, 10 Sep 2021 11:28:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 50344 <at> debbugs.gnu.org (full text, mbox):
On 10.09.2021 09:46, Juri Linkov wrote:
>>> C-x v B - vc-switch-backend
>>> C-x v b c - vc-create-tag (maybe it should have an alias 'vc-create-branch'?)
>>> C-x v b l - vc-print-branch-log
>>> C-x v b s - vc-retrieve-tag (maybe it should have an alias 'vc-switch-branch'?)
>>> C-x v s - vc-log-search
>>> C-x v r - free, any ideas what to bind to it?
>> vc-rename-file, perhaps?
> Or use it as a prefix key to allow more keybindings, e.g.
> with mnemonics "revision" to navigate the history like
> in vc-annotate: 'C-x v r n' (revision-next), 'C-x v r p' (previous), ...
Do you have some particular commands in mind?
In general, when we check out a file at a different revision, revision's
name is appended to the file name. So the same kind of iteration as with
vc-annotate will not work.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Mon, 13 Sep 2021 08:03:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 50344 <at> debbugs.gnu.org (full text, mbox):
>> But... perhaps we should take this to emacs-devel to see whether other
>> people feel differently?
>
> Some people might feel the desire to express general objection to seeing
> anything changed.
I realized that quite likely many users already rely on 'C-x v s'
and 'C-x v r' to create/switch branches because currently there is
no other quick way to do these frequent actions. OTOH, I don't
believe that 'vc-switch-backend' is used often. So it seems pretty safe
to just create a new prefix key map for 'C-x v b', and rebind 'vc-switch-backend'
to 'C-x v B'. Then leave 'C-x v r' and 'C-x v s' unchanged to give
users time to adopt to the new branch-related prefix map 'C-x v b'.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 16 Sep 2021 11:47:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 50344 <at> debbugs.gnu.org (full text, mbox):
On 09/09/2021 20:39 +0300, Juri Linkov wrote:
>>>> Speaking of (re)moving bindings: 'C-x v b' (vc-switch-backend) seems
>>>> particularly useless.
>>> Oh, wow. What's the use case for that command? I can't imagine when
>>> that would actually do something useful... And it's a really old
>>> command, too -- perhaps this was something that made sense in an RCS
>>> world?
>>
>> I think it's for the case of nested repositories, like in bug#42966 and
>> other linked reports. And perhaps our detection might make the wrong
>> choice, thus it can be tweaked manually.
>>
>> I don't have any specific scenario in mind, though. Or personal experience
>> with such nesting.
>>
>>>> If we do this the conservative way, though, the whole procedure can
>>>> span half a decade:
>>>>
>>>> - Move vc-switch-backend to 'C-x v B' (Emacs 28)
>>>> - Move branch-map to 'b' and vc-create-tag to 'C-x v b c' (Emacs 29)
>>>> - Finally move vc-search-log to 'C-x v s' (Emacs 30)
>>> We could do the first two steps in Emacs 28, perhaps -- if anybody's
>>> actually using `C-x v b', they'll then get
>>> C-x v b-
>>> in the echo area, which should tell them that something's different is
>>> happening now...
>>
>> Works for me.
>>
>> Juri, what do you say?
>
> I think in the long-term it would be nice to have these keybindings:
>
> C-x v B - vc-switch-backend
> C-x v b c - vc-create-tag (maybe it should have an alias 'vc-create-branch'?)
> C-x v b l - vc-print-branch-log
> C-x v b s - vc-retrieve-tag (maybe it should have an alias 'vc-switch-branch'?)
> C-x v s - vc-log-search
> C-x v r - free, any ideas what to bind to it?
>
> Since `C-x v b' will show "C-x v b-" in the echo area,
> and `C-x v s' will show "Search log with pattern: " in the minibuffer.
> and `C-x v r' will show "C-x v r is undefined",
> I see no problem in adding all keybindings before the next release.
Maybe I should express this wish in a separate bug, but:
It would be nice if vc-create-tag allowed to specify start-point
conveniently:
git checkout -b new-branch-name START-POINT
Currently I do this in shell.
Filipp.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 16 Sep 2021 11:55:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 50344 <at> debbugs.gnu.org (full text, mbox):
On 16.09.2021 14:46, Filipp Gunbin wrote:
> Maybe I should express this wish in a separate bug, but:
>
> It would be nice if vc-create-tag allowed to specify start-point
> conveniently:
>
> git checkout -b new-branch-name START-POINT
>
> Currently I do this in shell.
Perhaps we could do that with 'C-u C-u'.
Yes, a separate feature request is preferable.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Fri, 17 Sep 2021 15:16:01 GMT)
Full text and
rfc822 format available.
Message #80 received at 50344 <at> debbugs.gnu.org (full text, mbox):
On 16/09/2021 14:54 +0300, Dmitry Gutov wrote:
> On 16.09.2021 14:46, Filipp Gunbin wrote:
>> Maybe I should express this wish in a separate bug, but:
>>
>> It would be nice if vc-create-tag allowed to specify start-point
>> conveniently:
>>
>> git checkout -b new-branch-name START-POINT
>>
>> Currently I do this in shell.
>
> Perhaps we could do that with 'C-u C-u'.
>
> Yes, a separate feature request is preferable.
I'm also thinking of a separate command for branch creation, wrote all
that in bug#50643. Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Sat, 18 Sep 2021 00:10:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 50344 <at> debbugs.gnu.org (full text, mbox):
On 17.09.2021 18:15, Filipp Gunbin wrote:
> On 16/09/2021 14:54 +0300, Dmitry Gutov wrote:
>
>> On 16.09.2021 14:46, Filipp Gunbin wrote:
>>> Maybe I should express this wish in a separate bug, but:
>>>
>>> It would be nice if vc-create-tag allowed to specify start-point
>>> conveniently:
>>>
>>> git checkout -b new-branch-name START-POINT
>>>
>>> Currently I do this in shell.
>> Perhaps we could do that with 'C-u C-u'.
>>
>> Yes, a separate feature request is preferable.
> I'm also thinking of a separate command for branch creation, wrote all
> that in bug#50643. Thanks.
This part might actually fit better in this one: if we add a new command
which will create a branch by default, then it will fit the new 'b'
keymap best.
We could actually do the migration this way: create a new command which
"flips" the branch-tag relationship and put it on 'C-v b c'. Then, if
we're not removing the 'C-x s' binding in this release, we could
obsolete the command in favor of the new one because people create
branches more often tags tags these days (right?).
What do people think?
The command could also prompt for START-POINT by default: it shouldn't
really hurt to press RET once more at the end. It can also be useful to
double-check the branch you are currently branching from.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Sat, 18 Sep 2021 19:06:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 50344 <at> debbugs.gnu.org (full text, mbox):
>>>> It would be nice if vc-create-tag allowed to specify start-point
>>>> conveniently:
>>>>
>>>> git checkout -b new-branch-name START-POINT
>>>>
>>>> Currently I do this in shell.
>>> Perhaps we could do that with 'C-u C-u'.
>>>
>>> Yes, a separate feature request is preferable.
>> I'm also thinking of a separate command for branch creation, wrote all
>> that in bug#50643. Thanks.
>
> This part might actually fit better in this one: if we add a new command
> which will create a branch by default, then it will fit the new 'b'
> keymap best.
👍 for the new branch command. Until now, I avoided ‘vc-create-tag’
to not make a mistake that will create a tag instead of the branch.
> We could actually do the migration this way: create a new command which
> "flips" the branch-tag relationship and put it on 'C-v b c'. Then, if we're
> not removing the 'C-x s' binding in this release, we could obsolete the
> command in favor of the new one because people create branches more often
> tags tags these days (right?).
Shouldn't tag commands be moved to another prefix key ‘C-x v t’?
But I don't know how often tag commands are used.
> The command could also prompt for START-POINT by default: it shouldn't
> really hurt to press RET once more at the end. It can also be useful to
> double-check the branch you are currently branching from.
A prompt for START-POINT would be fine with completion on branch names,
and saying what the default value will be used when exiting with RET.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Sun, 19 Sep 2021 00:03:01 GMT)
Full text and
rfc822 format available.
Message #89 received at 50344 <at> debbugs.gnu.org (full text, mbox):
On 18.09.2021 22:03, Juri Linkov wrote:
>>>> Yes, a separate feature request is preferable.
>>> I'm also thinking of a separate command for branch creation, wrote all
>>> that in bug#50643. Thanks.
>>
>> This part might actually fit better in this one: if we add a new command
>> which will create a branch by default, then it will fit the new 'b'
>> keymap best.
>
> 👍 for the new branch command. Until now, I avoided ‘vc-create-tag’
> to not make a mistake that will create a tag instead of the branch.
>
>> We could actually do the migration this way: create a new command which
>> "flips" the branch-tag relationship and put it on 'C-v b c'. Then, if we're
>> not removing the 'C-x s' binding in this release, we could obsolete the
>> command in favor of the new one because people create branches more often
>> tags tags these days (right?).
>
> Shouldn't tag commands be moved to another prefix key ‘C-x v t’?
> But I don't know how often tag commands are used.
So far we only have one tag command, and it doubles for branches with
'C-u'. The other tag-related command doesn't differentiate between
branches and tags.
Would having essentially two copies of these, but with different names,
be a good idea?
Are there some VCS which would benefit from a more stricter
differentiation between the two? Hg, perhaps? I don't know how branches
work there.
Either way, we could put the same command in both keymaps, but I also
don't know how often the tag commands are used for working with _tags_
these days.
>> The command could also prompt for START-POINT by default: it shouldn't
>> really hurt to press RET once more at the end. It can also be useful to
>> double-check the branch you are currently branching from.
>
> A prompt for START-POINT would be fine with completion on branch names,
> and saying what the default value will be used when exiting with RET.
Yup!
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Sun, 19 Sep 2021 17:16:01 GMT)
Full text and
rfc822 format available.
Message #92 received at 50344 <at> debbugs.gnu.org (full text, mbox):
> So far we only have one tag command, and it doubles for branches with
> 'C-u'. The other tag-related command doesn't differentiate between branches
> and tags.
>
> Would having essentially two copies of these, but with different names, be
> a good idea?
It makes sense to create a copy where the meaning of its arg
is reversed, so by default it will operate on branches,
and only with C-u on tags.
> Are there some VCS which would benefit from a more stricter differentiation
> between the two? Hg, perhaps? I don't know how branches work there.
So the question is what backends already use the arg 'branchp'?
The search shows that vc-cvs-create-tag, vc-git-create-tag,
vc-hg-create-tag all use this arg.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Mon, 20 Sep 2021 00:35:01 GMT)
Full text and
rfc822 format available.
Message #95 received at 50344 <at> debbugs.gnu.org (full text, mbox):
On 19.09.2021 20:04, Juri Linkov wrote:
>> So far we only have one tag command, and it doubles for branches with
>> 'C-u'. The other tag-related command doesn't differentiate between branches
>> and tags.
>>
>> Would having essentially two copies of these, but with different names, be
>> a good idea?
>
> It makes sense to create a copy where the meaning of its arg
> is reversed, so by default it will operate on branches,
> and only with C-u on tags.
Yup.
But I also wonder if reading START-POINT with completion (with current
branch name as default) will make sense for creating tags in all
backends too.
>> Are there some VCS which would benefit from a more stricter differentiation
>> between the two? Hg, perhaps? I don't know how branches work there.
>
> So the question is what backends already use the arg 'branchp'?
> The search shows that vc-cvs-create-tag, vc-git-create-tag,
> vc-hg-create-tag all use this arg.
I thought of Hg in particular because there was a report or two citing
some problems with how we handle them.
And: "Mercurial offers a variety of approaches to branching, including
“named branches”, “bookmarks” (most similar to git), “anonymous
branches” and using clones."
(https://markheath.net/post/using-named-branches-in-mercurial)
That's basically all I know about it.
The introduction in
https://www.draketo.de/software/mercurial-branching-strategy, however,
sounds very similar to Git's approach.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Mon, 20 Sep 2021 07:11:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 50344 <at> debbugs.gnu.org (full text, mbox):
>> It makes sense to create a copy where the meaning of its arg
>> is reversed, so by default it will operate on branches,
>> and only with C-u on tags.
>
> Yup.
>
> But I also wonder if reading START-POINT with completion (with current
> branch name as default) will make sense for creating tags in all backends
> too.
You mean tag completion for creating tags? Maybe.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Mon, 20 Sep 2021 16:01:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 50344 <at> debbugs.gnu.org (full text, mbox):
On 18/09/2021 22:03 +0300, Juri Linkov wrote:
> Shouldn't tag commands be moved to another prefix key ‘C-x v t’?
> But I don't know how often tag commands are used.
Sounds good, C-x v t is where I'd look for tag-related commands first.
However, I don't use tags much (besides creation - only "git fetch
--tags"), so I cannot add anything meaningful here.
Otherwise, the plan for C-x v b prefix looks great.
Other commands, like maybe "C-x v b r" - rename, could be added then.
Filipp
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Mon, 20 Sep 2021 16:54:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 50344 <at> debbugs.gnu.org (full text, mbox):
On 20.09.2021 09:49, Juri Linkov wrote:
>>> It makes sense to create a copy where the meaning of its arg
>>> is reversed, so by default it will operate on branches,
>>> and only with C-u on tags.
>> Yup.
>>
>> But I also wonder if reading START-POINT with completion (with current
>> branch name as default) will make sense for creating tags in all backends
>> too.
> You mean tag completion for creating tags? Maybe.
Branch completion. To specify which branch tip to tag.
This seems like an unusual thing to need to do, but if we keep branch
and tag creation on the same command, and add START-POINT completion by
default, it might become the expected behavior in both scenarios, no?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Mon, 20 Sep 2021 17:32:02 GMT)
Full text and
rfc822 format available.
Message #107 received at 50344 <at> debbugs.gnu.org (full text, mbox):
On 20/09/2021 19:53 +0300, Dmitry Gutov wrote:
> On 20.09.2021 09:49, Juri Linkov wrote:
>>>> It makes sense to create a copy where the meaning of its arg
>>>> is reversed, so by default it will operate on branches,
>>>> and only with C-u on tags.
>>> Yup.
>>>
>>> But I also wonder if reading START-POINT with completion (with current
>>> branch name as default) will make sense for creating tags in all backends
>>> too.
>> You mean tag completion for creating tags? Maybe.
>
> Branch completion. To specify which branch tip to tag.
>
> This seems like an unusual thing to need to do, but if we keep branch
> and tag creation on the same command, and add START-POINT completion by
> default, it might become the expected behavior in both scenarios, no?
I think also (maybe that's obvious, but still) that START-POINT
auto-completion should include both branches and tags (because it's
common to create a branch off some tag). Of course, it should allow
specifying arbitrary commit hash.
Severity set to 'wishlist' from 'normal'
Request was from
Stefan Kangas <stefan <at> marxist.se>
to
control <at> debbugs.gnu.org.
(Tue, 21 Sep 2021 15:47:10 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Tue, 05 Oct 2021 17:47:01 GMT)
Full text and
rfc822 format available.
Message #112 received at 50344 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>>> Maybe I should express this wish in a separate bug, but:
>>>
>>> It would be nice if vc-create-tag allowed to specify start-point
>>> conveniently:
>>>
>>> git checkout -b new-branch-name START-POINT
>>>
>>> Currently I do this in shell.
>>
>> Perhaps we could do that with 'C-u C-u'.
>>
>> Yes, a separate feature request is preferable.
>
> I'm also thinking of a separate command for branch creation, wrote all
> that in bug#50643. Thanks.
The following patch adds two new branch commands.
> However, I don't use tags much (besides creation - only "git fetch
> --tags"), so I cannot add anything meaningful here.
> Otherwise, the plan for C-x v b prefix looks great.
> Other commands, like maybe "C-x v b r" - rename, could be added then.
I can't find the existing vc API method for renaming tags/branches.
> The command could have a mode for specifying START-POINT, so for Git the
> command becomes "git checkout -b new-branch-name START-POINT". This
> could be on C-u (unless there're other frequent "customization" cases).
The existing API method has no argument for START-POINT.
Maybe every backend could handle its prefix arg directly
from current-prefix-arg? For example,
(defun vc-git-create-tag (dir name branchp)
(if current-prefix-arg (completion-read "Start point: ") ...
[vc-switch-branch.patch (text/x-diff, inline)]
diff --git a/lisp/vc/vc-hooks.el b/lisp/vc/vc-hooks.el
index b7760e3bba..2b6ebdfb74 100644
--- a/lisp/vc/vc-hooks.el
+++ b/lisp/vc/vc-hooks.el
@@ -865,6 +865,9 @@ vc-prefix-map
(let ((map (make-sparse-keymap)))
(define-key map "a" #'vc-update-change-log)
(define-key map "b" #'vc-switch-backend)
+ (define-key map "Bc" #'vc-create-branch)
+ (define-key map "Bl" #'vc-print-branch-log)
+ (define-key map "Bs" #'vc-switch-branch)
(define-key map "d" #'vc-dir)
(define-key map "g" #'vc-annotate)
(define-key map "G" #'vc-ignore)
diff --git a/lisp/vc/vc.el b/lisp/vc/vc.el
index edc4169465..cdebf4a3d3 100644
--- a/lisp/vc/vc.el
+++ b/lisp/vc/vc.el
@@ -2350,7 +2372,23 @@ vc-create-tag
(message "Making %s... done" (if branchp "branch" "tag")))
;;;###autoload
-(defun vc-retrieve-tag (dir name)
+(defun vc-create-branch (dir name)
+ "Descending recursively from DIR, make a branch called NAME.
+After a new branch is made, the files are checked out in that new branch.
+Uses `vc-create-tag' with the non-nil arg `branchp'."
+ (interactive
+ (let ((granularity
+ (vc-call-backend (vc-responsible-backend default-directory)
+ 'revision-granularity)))
+ (list
+ (if (eq granularity 'repository)
+ default-directory
+ (read-directory-name "Directory: " default-directory default-directory t))
+ (read-string "New branch name: " nil 'vc-revision-history))))
+ (vc-create-tag dir name t))
+
+;;;###autoload
+(defun vc-retrieve-tag (dir name &optional branchp)
"For each file in or below DIR, retrieve their tagged version NAME.
NAME can name a branch, in which case this command will switch to the
named branch in the directory DIR.
@@ -2375,15 +2413,21 @@ vc-retrieve-tag
(read-directory-name "Directory: " default-directory nil t))))
(list
dir
- (vc-read-revision (format-prompt "Tag name to retrieve" "latest revisions")
+ (vc-read-revision (format-prompt
+ (if current-prefix-arg
+ "Branch name to retrieve"
+ "Tag name to retrieve")
+ "latest revisions")
(list dir)
- (vc-responsible-backend dir)))))
+ (vc-responsible-backend dir))
+ current-prefix-arg)))
(let* ((backend (vc-responsible-backend dir))
(update (when (vc-call-backend backend 'update-on-retrieve-tag)
(yes-or-no-p "Update any affected buffers? ")))
(msg (if (or (not name) (string= name ""))
(format "Updating %s... " (abbreviate-file-name dir))
- (format "Retrieving tag %s into %s... "
+ (format "Retrieving %s %s into %s... "
+ (if branchp "branch" "tag")
name (abbreviate-file-name dir)))))
(message "%s" msg)
(vc-call-backend backend 'retrieve-tag dir name update)
@@ -2391,6 +2435,25 @@ vc-retrieve-tag
(run-hooks 'vc-retrieve-tag-hook)
(message "%s" (concat msg "done"))))
+;;;###autoload
+(defun vc-switch-branch (dir name)
+ "Switch to the branch NAME in the directory DIR.
+If NAME is empty, it refers to the latest revisions of the current branch.
+Uses `vc-retrieve-tag' with the non-nil arg `branchp'."
+ (interactive
+ (let* ((granularity
+ (vc-call-backend (vc-responsible-backend default-directory)
+ 'revision-granularity))
+ (dir
+ (if (eq granularity 'repository)
+ (expand-file-name (vc-root-dir))
+ (read-directory-name "Directory: " default-directory nil t))))
+ (list
+ dir
+ (vc-read-revision (format-prompt "Branch name to retrieve" "latest revisions")
+ (list dir)
+ (vc-responsible-backend dir)))))
+ (vc-retrieve-tag dir name t))
;; Miscellaneous other entry points
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Wed, 06 Oct 2021 00:38:01 GMT)
Full text and
rfc822 format available.
Message #115 received at 50344 <at> debbugs.gnu.org (full text, mbox):
On 05.10.2021 20:43, Juri Linkov wrote:
>> I'm also thinking of a separate command for branch creation, wrote all
>> that in bug#50643. Thanks.
>
> The following patch adds two new branch commands.
>
>> However, I don't use tags much (besides creation - only "git fetch
>> --tags"), so I cannot add anything meaningful here.
>> Otherwise, the plan for C-x v b prefix looks great.
>> Other commands, like maybe "C-x v b r" - rename, could be added then.
>
> I can't find the existing vc API method for renaming tags/branches.
I think that's OK.
>> The command could have a mode for specifying START-POINT, so for Git the
>> command becomes "git checkout -b new-branch-name START-POINT". This
>> could be on C-u (unless there're other frequent "customization" cases).
>
> The existing API method has no argument for START-POINT.
> Maybe every backend could handle its prefix arg directly
> from current-prefix-arg? For example,
>
> (defun vc-git-create-tag (dir name branchp)
> (if current-prefix-arg (completion-read "Start point: ") ...
Maybe we should add a new argument, an optional one. Then backends which
don't support it can continue working without 'C-u' (we can make sure to
call them with appropriate number of arguments) but will obviously fail
when passed an extra argument. We could even catch the error and report
that the backend doesn't support this feature.
But maybe the command should prompt for START-POINT by default: one
doesn't create branches that often to be bothered by an extra RET, and
it can be useful to verify the branch you are branching off of every
time you do it. That would be my preferred behavior. And the
implementation could be the same if we manage to treat RET as
unspecified START-POINT.
As long as the ability to read and show the current ref/branch is there
for most backends (to show it as the default input in the prompt).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Wed, 06 Oct 2021 07:41:02 GMT)
Full text and
rfc822 format available.
Message #118 received at 50344 <at> debbugs.gnu.org (full text, mbox):
>>> The command could have a mode for specifying START-POINT, so for Git the
>>> command becomes "git checkout -b new-branch-name START-POINT". This
>>> could be on C-u (unless there're other frequent "customization" cases).
>> The existing API method has no argument for START-POINT.
>> Maybe every backend could handle its prefix arg directly
>> from current-prefix-arg? For example,
>> (defun vc-git-create-tag (dir name branchp)
>> (if current-prefix-arg (completion-read "Start point: ") ...
>
> Maybe we should add a new argument, an optional one. Then backends which
> don't support it can continue working without 'C-u' (we can make sure to
> call them with appropriate number of arguments) but will obviously fail
> when passed an extra argument. We could even catch the error and report
> that the backend doesn't support this feature.
We need to add new optional arguments to another VC-API methods anyway, e.g.
(vc-call-backend backend 'revision-completion-table files)
needs a new argument 'branchp' to avoid the recently added hack
'vc-git-revision-complete-only-branches' that can't be used
in the new command 'vc-switch-branch' by 'vc-read-revision'
(that also needs a new argument 'branchp').
> But maybe the command should prompt for START-POINT by default: one doesn't
> create branches that often to be bothered by an extra RET, and it can be
> useful to verify the branch you are branching off of every time you do
> it. That would be my preferred behavior. And the implementation could be
> the same if we manage to treat RET as unspecified START-POINT.
Prompting for START-POINT by default is ok. The problem is how to handle
existing backends after adding new optional arguments to VC-API methods.
Maybe first to call with an extra argument, catch an error, then call again
without an extra argument?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Wed, 06 Oct 2021 16:40:02 GMT)
Full text and
rfc822 format available.
Message #121 received at 50344 <at> debbugs.gnu.org (full text, mbox):
>>> Other commands, like maybe "C-x v b r" - rename, could be added then.
>> I can't find the existing vc API method for renaming tags/branches.
>
> I think that's OK.
But even the current branch creating command fails for git.
For example, 'C-u C-x v s new_branch RET' fails with the error:
(error "Failed (status 1): git --no-pager update-index --refresh .")
and shows the *vc* buffer saying that modified files need update.
Whereas `M-& git checkout -b new_branch` works fine with modified files.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 07 Oct 2021 00:48:02 GMT)
Full text and
rfc822 format available.
Message #124 received at 50344 <at> debbugs.gnu.org (full text, mbox):
On 06.10.2021 19:28, Juri Linkov wrote:
>>>> Other commands, like maybe "C-x v b r" - rename, could be added then.
>>> I can't find the existing vc API method for renaming tags/branches.
>> I think that's OK.
> But even the current branch creating command fails for git.
> For example, 'C-u C-x v s new_branch RET' fails with the error:
>
> (error "Failed (status 1): git --no-pager update-index --refresh .")
>
> and shows the*vc* buffer saying that modified files need update.
>
> Whereas `M-& git checkout -b new_branch` works fine with modified files.
All right, yes, the current behavior is weird. It's actually documented
in the description of the 'create-tag' action:
;; Attach the tag NAME to the state of the working copy. This
;; should make sure that files are up-to-date before proceeding with
;; the action.
Perhaps ESR or Dan N. have a good justification for this, but it seems
to me the contemporary expectation is that tags and branches are created
from the committed revision history, and not from the "working copy".
Some backends may choose to enforce this kind of limitation, but the
more modern ones like Git or Hg should skip the check IMHO.
And it seems, from looking at vc-hg-create-tag, Hg already skips it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 07 Oct 2021 00:58:01 GMT)
Full text and
rfc822 format available.
Message #127 received at 50344 <at> debbugs.gnu.org (full text, mbox):
On 06.10.2021 10:29, Juri Linkov wrote:
>>>> The command could have a mode for specifying START-POINT, so for Git the
>>>> command becomes "git checkout -b new-branch-name START-POINT". This
>>>> could be on C-u (unless there're other frequent "customization" cases).
>>> The existing API method has no argument for START-POINT.
>>> Maybe every backend could handle its prefix arg directly
>>> from current-prefix-arg? For example,
>>> (defun vc-git-create-tag (dir name branchp)
>>> (if current-prefix-arg (completion-read "Start point: ") ...
>>
>> Maybe we should add a new argument, an optional one. Then backends which
>> don't support it can continue working without 'C-u' (we can make sure to
>> call them with appropriate number of arguments) but will obviously fail
>> when passed an extra argument. We could even catch the error and report
>> that the backend doesn't support this feature.
>
> We need to add new optional arguments to another VC-API methods anyway, e.g.
>
> (vc-call-backend backend 'revision-completion-table files)
>
> needs a new argument 'branchp' to avoid the recently added hack
> 'vc-git-revision-complete-only-branches' that can't be used
> in the new command 'vc-switch-branch' by 'vc-read-revision'
> (that also needs a new argument 'branchp').
This will probably help in vc-switch-branch (when the user wants to
retrieve a tag, I guess they will use the tag-specific command).
Not sure about other places: if we're talking about the START-POSITION
argument, I suppose it is possible that the user will want to start a
branch from a tag instead. Or any other kind of ref, but "raw" commit
hashes aren't helpful in completion anyway.
>> But maybe the command should prompt for START-POINT by default: one doesn't
>> create branches that often to be bothered by an extra RET, and it can be
>> useful to verify the branch you are branching off of every time you do
>> it. That would be my preferred behavior. And the implementation could be
>> the same if we manage to treat RET as unspecified START-POINT.
>
> Prompting for START-POINT by default is ok. The problem is how to handle
> existing backends after adding new optional arguments to VC-API methods.
> Maybe first to call with an extra argument, catch an error, then call again
> without an extra argument?
Yes, that's the method I was thinking of.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 07 Oct 2021 07:32:02 GMT)
Full text and
rfc822 format available.
Message #130 received at 50344 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> I realized that quite likely many users already rely on 'C-x v s'
> and 'C-x v r' to create/switch branches because currently there is
> no other quick way to do these frequent actions. OTOH, I don't
> believe that 'vc-switch-backend' is used often. So it seems pretty safe
> to just create a new prefix key map for 'C-x v b', and rebind 'vc-switch-backend'
> to 'C-x v B'. Then leave 'C-x v r' and 'C-x v s' unchanged to give
> users time to adopt to the new branch-related prefix map 'C-x v b'.
It will take more time to create branch commands due to many problems.
So the best what we could do now is to rebind 'vc-switch-backend'
from 'C-x v b' to 'C-x v B' in emacs-28 to give time to adapt
to new keybinding. 'vc-switch-backend' was announced in NEWS thusly:
If a file is registered in multiple backends, you can switch to
another one using C-x v b (vc-switch-backend). This does not change
any files, it only changes VC's perspective on the file. Use this to
pick up changes from CVS while working under RCS locally.
So it was intended to switch backends between CVS and RCS.
[vc-switch-backend.patch (text/x-diff, inline)]
diff --git a/etc/NEWS b/etc/NEWS
index 8b327fac0f..26af52af58 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -3299,6 +3299,10 @@ Setting this to nil inhibits that.
** 'vc-print-branch-log' shows the change log from its root directory.
It previously used to use the default directory.
+---
+** 'vc-switch-backend' is rebound from 'C-x v b' to 'C-x v B'.
+The prefix key 'C-x v b' is reserved for coming branch commands.
+
---
** 'project-shell' and 'shell' now use 'pop-to-buffer-same-window'.
This is to keep the same behavior as Eshell.
diff --git a/lisp/vc/vc-hooks.el b/lisp/vc/vc-hooks.el
index b7760e3bba..7455a306bc 100644
--- a/lisp/vc/vc-hooks.el
+++ b/lisp/vc/vc-hooks.el
@@ -864,7 +864,8 @@ vc-kill-buffer-hook
(defvar vc-prefix-map
(let ((map (make-sparse-keymap)))
(define-key map "a" #'vc-update-change-log)
- (define-key map "b" #'vc-switch-backend)
+ ;; TODO: Use the prefix key "b" for branch commands.
+ (define-key map "B" #'vc-switch-backend)
(define-key map "d" #'vc-dir)
(define-key map "g" #'vc-annotate)
(define-key map "G" #'vc-ignore)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 07 Oct 2021 07:48:01 GMT)
Full text and
rfc822 format available.
Message #133 received at 50344 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Date: Thu, 07 Oct 2021 10:21:45 +0300
> Cc: 50344 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
>
> It will take more time to create branch commands due to many problems.
> So the best what we could do now is to rebind 'vc-switch-backend'
> from 'C-x v b' to 'C-x v B' in emacs-28 to give time to adapt
> to new keybinding.
Please don't change such old key bindings, not unless we are
deprecating the command (which we aren't, AFAIU).
>'vc-switch-backend' was announced in NEWS thusly:
>
> If a file is registered in multiple backends, you can switch to
> another one using C-x v b (vc-switch-backend). This does not change
> any files, it only changes VC's perspective on the file. Use this to
> pick up changes from CVS while working under RCS locally.
>
> So it was intended to switch backends between CVS and RCS.
It was then, but it can be used today with other backends.
So I'm opposed to such a change. (And it's too late for incompatible
changes on the emacs-28 branch anyway.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 07 Oct 2021 08:09:02 GMT)
Full text and
rfc822 format available.
Message #136 received at 50344 <at> debbugs.gnu.org (full text, mbox):
>> It will take more time to create branch commands due to many problems.
>> So the best what we could do now is to rebind 'vc-switch-backend'
>> from 'C-x v b' to 'C-x v B' in emacs-28 to give time to adapt
>> to new keybinding.
>
> Please don't change such old key bindings, not unless we are
> deprecating the command (which we aren't, AFAIU).
Sorry, I see no connection: why changing key bindings requires
deprecating the command?
>>'vc-switch-backend' was announced in NEWS thusly:
>>
>> If a file is registered in multiple backends, you can switch to
>> another one using C-x v b (vc-switch-backend). This does not change
>> any files, it only changes VC's perspective on the file. Use this to
>> pick up changes from CVS while working under RCS locally.
>>
>> So it was intended to switch backends between CVS and RCS.
>
> It was then, but it can be used today with other backends.
What backends do you switch with 'C-x v b' today?
> So I'm opposed to such a change. (And it's too late for incompatible
> changes on the emacs-28 branch anyway.)
It makes no sense to develop branch commands without 'C-x v b' binding.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 07 Oct 2021 08:30:01 GMT)
Full text and
rfc822 format available.
Message #139 received at 50344 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: dgutov <at> yandex.ru, 50344 <at> debbugs.gnu.org, larsi <at> gnus.org
> Date: Thu, 07 Oct 2021 10:58:10 +0300
>
> >> It will take more time to create branch commands due to many problems.
> >> So the best what we could do now is to rebind 'vc-switch-backend'
> >> from 'C-x v b' to 'C-x v B' in emacs-28 to give time to adapt
> >> to new keybinding.
> >
> > Please don't change such old key bindings, not unless we are
> > deprecating the command (which we aren't, AFAIU).
>
> Sorry, I see no connection: why changing key bindings requires
> deprecating the command?
Because people will expect the old binding to work as long as the
command is useful.
> > It was then, but it can be used today with other backends.
>
> What backends do you switch with 'C-x v b' today?
You mean, I personally? Why is that relevant? If you want to say
that no one uses this command anymore, then that points to deprecating
the command, and when it's obsolete for long enough time (at least one
major release, IMO), we can remove its binding.
> > So I'm opposed to such a change. (And it's too late for incompatible
> > changes on the emacs-28 branch anyway.)
>
> It makes no sense to develop branch commands without 'C-x v b' binding.
I don't see why it must end with 'b' to make any sense. I think you
are exaggerating.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 07 Oct 2021 09:58:01 GMT)
Full text and
rfc822 format available.
Message #142 received at 50344 <at> debbugs.gnu.org (full text, mbox):
>
> It makes no sense to develop branch commands without 'C-x v b' binding.
>
If C-x v b isn't available anymore, perhaps C-x v < or ^ would be a good
alternative?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 07 Oct 2021 11:13:02 GMT)
Full text and
rfc822 format available.
Message #145 received at 50344 <at> debbugs.gnu.org (full text, mbox):
On 07.10.2021 11:28, Eli Zaretskii wrote:
>> From: Juri Linkov <juri <at> linkov.net>
>> Cc: dgutov <at> yandex.ru, 50344 <at> debbugs.gnu.org, larsi <at> gnus.org
>> Date: Thu, 07 Oct 2021 10:58:10 +0300
>>
>>>> It will take more time to create branch commands due to many problems.
>>>> So the best what we could do now is to rebind 'vc-switch-backend'
>>>> from 'C-x v b' to 'C-x v B' in emacs-28 to give time to adapt
>>>> to new keybinding.
>>>
>>> Please don't change such old key bindings, not unless we are
>>> deprecating the command (which we aren't, AFAIU).
>>
>> Sorry, I see no connection: why changing key bindings requires
>> deprecating the command?
>
> Because people will expect the old binding to work as long as the
> command is useful.
They shouldn't: we have a lot of commands without dedicated bindings.
This command will retain some marginal utility, for some users out there
(though I don't know who or why), so removing it doesn't make sense.
But its utility is incommeasurable with the binding it's taking up.
Let's announce in Emacs 28's NEWS that we intend to remove (or take
away) the binding 'C-x v b'. Just like we did with the TAB binding in
*xref* buffers.
>>> It was then, but it can be used today with other backends.
>>
>> What backends do you switch with 'C-x v b' today?
>
> You mean, I personally? Why is that relevant? If you want to say
> that no one uses this command anymore, then that points to deprecating
> the command, and when it's obsolete for long enough time (at least one
> major release, IMO), we can remove its binding.
"No one" is a very strong criterion.
What if 2 people total, out of all users, were using this command?
Would you still deprecate it, with intent to remove? Or would you still
keep the binding?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 07 Oct 2021 11:15:01 GMT)
Full text and
rfc822 format available.
Message #148 received at 50344 <at> debbugs.gnu.org (full text, mbox):
On 07.10.2021 12:57, Gregory Heytings wrote:
>>
>> It makes no sense to develop branch commands without 'C-x v b' binding.
>>
>
> If C-x v b isn't available anymore, perhaps C-x v < or ^ would be a good
> alternative?
For vc-switch-backend?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 07 Oct 2021 11:26:01 GMT)
Full text and
rfc822 format available.
Message #151 received at 50344 <at> debbugs.gnu.org (full text, mbox):
>>> It makes no sense to develop branch commands without 'C-x v b'
>>> binding.
>>
>> If C-x v b isn't available anymore, perhaps C-x v < or ^ would be a
>> good alternative?
>
> For vc-switch-backend?
>
No, for vc-branch-* commands. vc-switch-backend is already on C-x v b.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 07 Oct 2021 11:36:02 GMT)
Full text and
rfc822 format available.
Message #154 received at 50344 <at> debbugs.gnu.org (full text, mbox):
On 07.10.2021 14:25, Gregory Heytings wrote:
>
>>>> It makes no sense to develop branch commands without 'C-x v b' binding.
>>>
>>> If C-x v b isn't available anymore, perhaps C-x v < or ^ would be a
>>> good alternative?
>>
>> For vc-switch-backend?
>>
>
> No, for vc-branch-* commands. vc-switch-backend is already on C-x v b.
It doesn't really make sense to move the branch commands to 'C-x v <'
while vc-dir-mode-map has branch commands on 'C-x v B'. We should make
the UI more uniform, not create more exceptions.
It's not mnemonic either.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 07 Oct 2021 11:43:01 GMT)
Full text and
rfc822 format available.
Message #157 received at 50344 <at> debbugs.gnu.org (full text, mbox):
>
> It doesn't really make sense to move the branch commands to 'C-x v <'
> while vc-dir-mode-map has branch commands on 'C-x v B'. We should make
> the UI more uniform, not create more exceptions.
>
These were my 2 cents, just an idea.
>
> It's not mnemonic either.
>
IMO it is, '<' is a visual representation of two branches. I wouldn't be
surprised if '<' was used (as an icon) to open a dialog for branch
operations in some other editor.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 07 Oct 2021 12:26:02 GMT)
Full text and
rfc822 format available.
Message #160 received at 50344 <at> debbugs.gnu.org (full text, mbox):
Gregory Heytings <gregory <at> heytings.org> writes:
>> It's not mnemonic either.
>>
>
> IMO it is, '<' is a visual representation of two branches. I wouldn't
> be surprised if '<' was used (as an icon) to open a dialog for branch
> operations in some other editor.
(With apologies for contributing to the bikeshed,)
'y' kinda works too by the same logic, and is unused by vc AFAICT?
Magit uses 'y' for "refs" commands[1], which bring up buffers
enumerating branches and tags).
(Magit does use 'b' for branch management in general though. IMO it is
more intuitive for a VC system to bind commonly used branch commands[2]
to 'b'; switching backends sounds like a one-off maintenance operation
that one would hopefully not need a dedicated binding for.)
[1] https://magit.vc/manual/magit/References-Buffer.html
[2] Such as those described upthread, e.g. creating branches, showing
their log, checking them out:
<878rz72wqg.fsf <at> mail.linkov.net>
https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-10/msg00483.html
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 07 Oct 2021 12:44:01 GMT)
Full text and
rfc822 format available.
Message #163 received at 50344 <at> debbugs.gnu.org (full text, mbox):
On 07/10/2021 14:35 +0300, Dmitry Gutov wrote:
> On 07.10.2021 14:25, Gregory Heytings wrote:
>>
>>>>> It makes no sense to develop branch commands without 'C-x v b' binding.
>>>>
>>>> If C-x v b isn't available anymore, perhaps C-x v < or ^ would be a
>>>> good alternative?
>>>
>>> For vc-switch-backend?
>>>
>>
>> No, for vc-branch-* commands. vc-switch-backend is already on C-x v b.
>
> It doesn't really make sense to move the branch commands to 'C-x v <'
> while vc-dir-mode-map has branch commands on 'C-x v B'. We should make
> the UI more uniform, not create more exceptions.
>
> It's not mnemonic either.
Maybe I missing something, but why can't we assign branch commands to
the C-x v B prefix?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 07 Oct 2021 12:47:01 GMT)
Full text and
rfc822 format available.
Message #166 received at 50344 <at> debbugs.gnu.org (full text, mbox):
Thanks, two very minor doc comments:
> +;;;###autoload
> +(defun vc-retrieve-tag (dir name &optional branchp)
> "For each file in or below DIR, retrieve their tagged version NAME.
> NAME can name a branch, in which case this command will switch to the
> named branch in the directory DIR.
> @@ -2375,15 +2413,21 @@ vc-retrieve-tag
> (read-directory-name "Directory: " default-directory nil t))))
> (list
> dir
> - (vc-read-revision (format-prompt "Tag name to retrieve" "latest revisions")
> + (vc-read-revision (format-prompt
> + (if current-prefix-arg
> + "Branch name to retrieve"
> + "Tag name to retrieve")
> + "latest revisions")
Mention prefix arg in the docstring?
> +(defun vc-switch-branch (dir name)
> + "Switch to the branch NAME in the directory DIR.
> +If NAME is empty, it refers to the latest revisions of the current branch.
> +Uses `vc-retrieve-tag' with the non-nil arg `branchp'."
"latest revision" instead of plural?
Filipp.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 07 Oct 2021 12:52:01 GMT)
Full text and
rfc822 format available.
Message #169 received at 50344 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 07 Oct 2021 09:57:24 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: Eli Zaretskii <eliz <at> gnu.org>, 50344 <at> debbugs.gnu.org, larsi <at> gnus.org,
> dgutov <at> yandex.ru
>
> If C-x v b isn't available anymore, perhaps C-x v < or ^ would be a good
> alternative?
Frankly, I don't understand why "C-x v B" suddenly stopped being a
good candidate. It was discussed at the beginning, but then was
suddenly dropped. I think it will make a better choice than what you
propose above, because it's somewhat easier to type, especially on
non-US keyboards (I think).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 07 Oct 2021 12:54:02 GMT)
Full text and
rfc822 format available.
Message #172 received at 50344 <at> debbugs.gnu.org (full text, mbox):
On 07.10.2021 15:42, Filipp Gunbin wrote:
> Maybe I missing something, but why can't we assign branch commands to
> the C-x v B prefix?
Yeah, we could.
But when someone else comes along and asks why we have everybody
pressing Shift every time they need to do something with a branch, I
won't have a good answer.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 07 Oct 2021 12:56:02 GMT)
Full text and
rfc822 format available.
Message #175 received at 50344 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 07 Oct 2021 15:46:47 +0300, Filipp Gunbin <fgunbin <at> fastmail.fm> said:
>> +(defun vc-switch-branch (dir name)
>> + "Switch to the branch NAME in the directory DIR.
>> +If NAME is empty, it refers to the latest revisions of the current branch.
>> +Uses `vc-retrieve-tag' with the non-nil arg `branchp'."
Filipp> "latest revision" instead of plural?
Some version control systems have branches, but also have per-file
revisions.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 07 Oct 2021 12:57:02 GMT)
Full text and
rfc822 format available.
Message #178 received at 50344 <at> debbugs.gnu.org (full text, mbox):
> Cc: 50344 <at> debbugs.gnu.org, larsi <at> gnus.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Thu, 7 Oct 2021 14:12:06 +0300
>
> >> Sorry, I see no connection: why changing key bindings requires
> >> deprecating the command?
> >
> > Because people will expect the old binding to work as long as the
> > command is useful.
>
> They shouldn't: we have a lot of commands without dedicated bindings.
>
> This command will retain some marginal utility, for some users out there
> (though I don't know who or why), so removing it doesn't make sense.
>
> But its utility is incommeasurable with the binding it's taking up.
>
> Let's announce in Emacs 28's NEWS that we intend to remove (or take
> away) the binding 'C-x v b'. Just like we did with the TAB binding in
> *xref* buffers.
>
> >>> It was then, but it can be used today with other backends.
> >>
> >> What backends do you switch with 'C-x v b' today?
> >
> > You mean, I personally? Why is that relevant? If you want to say
> > that no one uses this command anymore, then that points to deprecating
> > the command, and when it's obsolete for long enough time (at least one
> > major release, IMO), we can remove its binding.
>
> "No one" is a very strong criterion.
>
> What if 2 people total, out of all users, were using this command?
That's the same as "no one", for the purposes of this discussion.
> Would you still deprecate it, with intent to remove? Or would you still
> keep the binding?
I didn't say I was against deprecating the command. I said
deprecating it is the only way to eventually usurp its key binding.
But deprecation will take time, and I was under the impression that
Juri wanted the VC branch commands to have the binding NOW.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 07 Oct 2021 13:07:02 GMT)
Full text and
rfc822 format available.
Message #181 received at 50344 <at> debbugs.gnu.org (full text, mbox):
On 07.10.2021 15:56, Eli Zaretskii wrote:
>> What if 2 people total, out of all users, were using this command?
>
> That's the same as "no one", for the purposes of this discussion.
If the command is still useful to a handful of people (some subset of
CVS/RSC users, apparently), and it doesn't take effort to maintain it,
it doesn't seem helpful to deprecate it.
Unlike the key binding.
>> Would you still deprecate it, with intent to remove? Or would you still
>> keep the binding?
>
> I didn't say I was against deprecating the command. I said
> deprecating it is the only way to eventually usurp its key binding.
And I questioned this statement.
> But deprecation will take time, and I was under the impression that
> Juri wanted the VC branch commands to have the binding NOW.
As Juri said, the new branch commands are not ready yet.
His patch was to prepare the users to this prefix being used for branch
commands in the next Emacs version. You didn't like the proposed method,
that's okay.
Let's deprecate the binding in Emacs 28, so it can be used for branch
commands in Emacs 29.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 07 Oct 2021 13:12:02 GMT)
Full text and
rfc822 format available.
Message #184 received at 50344 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 07 Oct 2021 15:56:30 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
Eli> That's the same as "no one", for the purposes of this discussion.
>> Would you still deprecate it, with intent to remove? Or would you still
>> keep the binding?
Eli> I didn't say I was against deprecating the command. I said
Eli> deprecating it is the only way to eventually usurp its key binding.
- itʼs undocumented except in NEWS.21
- the workflow itʼs intended for requires you to use the
(undocumented) prefix arg to 'vc-next-action'
- and that workflow is something that I very much doubt anybody still
uses (temporarily using RCS for CVS controlled files? Just use git,
or hg or anything from the last 20 years)
Eli> But deprecation will take time, and I was under the impression that
Eli> Juri wanted the VC branch commands to have the binding NOW.
I can see that we want to be careful about deprecation, but this
command is *really* niche. How about we move it to C-x v B, and let
Juri have C-x v b ?
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 07 Oct 2021 13:12:02 GMT)
Full text and
rfc822 format available.
Message #187 received at 50344 <at> debbugs.gnu.org (full text, mbox):
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Thu, 7 Oct 2021 14:35:06 +0300
> Cc: 50344 <at> debbugs.gnu.org, larsi <at> gnus.org, Juri Linkov <juri <at> linkov.net>
>
> It doesn't really make sense to move the branch commands to 'C-x v <'
> while vc-dir-mode-map has branch commands on 'C-x v B'. We should make
> the UI more uniform, not create more exceptions.
I agree, but then why not use "C-x v B", as was discussed originally?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 07 Oct 2021 13:23:02 GMT)
Full text and
rfc822 format available.
Message #190 received at 50344 <at> debbugs.gnu.org (full text, mbox):
> Cc: juri <at> linkov.net, 50344 <at> debbugs.gnu.org, larsi <at> gnus.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Thu, 7 Oct 2021 16:06:05 +0300
>
> Let's deprecate the binding in Emacs 28, so it can be used for branch
> commands in Emacs 29.
As I already said, I don't want to deprecate the binding if we are not
deprecating the command which uses it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 07 Oct 2021 13:27:01 GMT)
Full text and
rfc822 format available.
Message #193 received at 50344 <at> debbugs.gnu.org (full text, mbox):
On 07.10.2021 16:21, Eli Zaretskii wrote:
>> Cc:juri <at> linkov.net,50344 <at> debbugs.gnu.org,larsi <at> gnus.org
>> From: Dmitry Gutov<dgutov <at> yandex.ru>
>> Date: Thu, 7 Oct 2021 16:06:05 +0300
>>
>> Let's deprecate the binding in Emacs 28, so it can be used for branch
>> commands in Emacs 29.
> As I already said, I don't want to deprecate the binding if we are not
> deprecating the command which uses it.
Why?
We have commands without bindings.
We didn't deprecate 'xref-quit-and-goto-xref' either.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 07 Oct 2021 13:51:02 GMT)
Full text and
rfc822 format available.
Message #196 received at 50344 <at> debbugs.gnu.org (full text, mbox):
> Cc: juri <at> linkov.net, 50344 <at> debbugs.gnu.org, larsi <at> gnus.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Thu, 7 Oct 2021 16:26:06 +0300
>
> On 07.10.2021 16:21, Eli Zaretskii wrote:
> >> Cc:juri <at> linkov.net,50344 <at> debbugs.gnu.org,larsi <at> gnus.org
> >> From: Dmitry Gutov<dgutov <at> yandex.ru>
> >> Date: Thu, 7 Oct 2021 16:06:05 +0300
> >>
> >> Let's deprecate the binding in Emacs 28, so it can be used for branch
> >> commands in Emacs 29.
> > As I already said, I don't want to deprecate the binding if we are not
> > deprecating the command which uses it.
>
> Why?
>
> We have commands without bindings.
Because this command _has_ a binding, and had it since Emacs 21.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 07 Oct 2021 13:53:01 GMT)
Full text and
rfc822 format available.
Message #199 received at 50344 <at> debbugs.gnu.org (full text, mbox):
On 07/10/2021 15:11 +0200, Robert Pluim wrote:
> I can see that we want to be careful about deprecation, but this
> command is *really* niche. How about we move it to C-x v B, and let
> Juri have C-x v b ?
+1
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 07 Oct 2021 17:33:01 GMT)
Full text and
rfc822 format available.
Message #202 received at 50344 <at> debbugs.gnu.org (full text, mbox):
> Thanks, two very minor doc comments:
>
>> +;;;###autoload
>> +(defun vc-retrieve-tag (dir name &optional branchp)
>> "For each file in or below DIR, retrieve their tagged version NAME.
>> NAME can name a branch, in which case this command will switch to the
>> named branch in the directory DIR.
>> @@ -2375,15 +2413,21 @@ vc-retrieve-tag
>> (read-directory-name "Directory: " default-directory nil t))))
>> (list
>> dir
>> - (vc-read-revision (format-prompt "Tag name to retrieve" "latest revisions")
>> + (vc-read-revision (format-prompt
>> + (if current-prefix-arg
>> + "Branch name to retrieve"
>> + "Tag name to retrieve")
>> + "latest revisions")
>
> Mention prefix arg in the docstring?
Thanks for noticing, will be added in the next version of the patch.
>> +(defun vc-switch-branch (dir name)
>> + "Switch to the branch NAME in the directory DIR.
>> +If NAME is empty, it refers to the latest revisions of the current branch.
>> +Uses `vc-retrieve-tag' with the non-nil arg `branchp'."
>
> "latest revision" instead of plural?
This text was copied from vc-retrieve-tag, and Robert explained why
it's plural. But since this phrase is too confusing, maybe it would be
possible to rephrase it with a better text?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 07 Oct 2021 17:34:02 GMT)
Full text and
rfc822 format available.
Message #205 received at 50344 <at> debbugs.gnu.org (full text, mbox):
> Frankly, I don't understand why "C-x v B" suddenly stopped being a
> good candidate. It was discussed at the beginning, but then was
> suddenly dropped. I think it will make a better choice than what you
> propose above, because it's somewhat easier to type, especially on
> non-US keyboards (I think).
Because for a few days I already tried to use 'C-x v B l' since
I need to check the logs of other branches many times per day,
and it was absolutely horrible experience — Shift+B is very
hard to type because "B" is in the middle of the keyboard,
and after I almost got RSI, I had to rebind it to `C-x v b l'
for the relief.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 07 Oct 2021 17:38:01 GMT)
Full text and
rfc822 format available.
Message #208 received at 50344 <at> debbugs.gnu.org (full text, mbox):
>> Let's deprecate the binding in Emacs 28, so it can be used for branch
>> commands in Emacs 29.
>
> As I already said, I don't want to deprecate the binding if we are not
> deprecating the command which uses it.
I don't understand how this is different from removing other keybindings
such as recently removing the global binding 'M-o' ('facemenu-keymap'),
etc.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 07 Oct 2021 18:23:02 GMT)
Full text and
rfc822 format available.
Message #211 received at 50344 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: Dmitry Gutov <dgutov <at> yandex.ru>, 50344 <at> debbugs.gnu.org, larsi <at> gnus.org
> Date: Thu, 07 Oct 2021 20:36:13 +0300
>
> >> Let's deprecate the binding in Emacs 28, so it can be used for branch
> >> commands in Emacs 29.
> >
> > As I already said, I don't want to deprecate the binding if we are not
> > deprecating the command which uses it.
>
> I don't understand how this is different from removing other keybindings
> such as recently removing the global binding 'M-o' ('facemenu-keymap'),
> etc.
It isn't. But that even was enough pain for a single release, so I'd
like to avoid repeating it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 07 Oct 2021 18:26:02 GMT)
Full text and
rfc822 format available.
Message #214 received at 50344 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: Gregory Heytings <gregory <at> heytings.org>, 50344 <at> debbugs.gnu.org,
> larsi <at> gnus.org, dgutov <at> yandex.ru
> Date: Thu, 07 Oct 2021 20:30:10 +0300
>
> > Frankly, I don't understand why "C-x v B" suddenly stopped being a
> > good candidate. It was discussed at the beginning, but then was
> > suddenly dropped. I think it will make a better choice than what you
> > propose above, because it's somewhat easier to type, especially on
> > non-US keyboards (I think).
>
> Because for a few days I already tried to use 'C-x v B l' since
> I need to check the logs of other branches many times per day,
> and it was absolutely horrible experience — Shift+B is very
> hard to type because "B" is in the middle of the keyboard,
> and after I almost got RSI, I had to rebind it to `C-x v b l'
> for the relief.
I don't get any trouble pressing this sequence: since Ctrl is already
released, I have that finger to press Shift, which is near Ctrl.
But if most people have the same problematic experience as you did, I
guess we should try looking for another lower-case letter. Only 13 of
the 26 possible are taken now.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Thu, 07 Oct 2021 21:50:02 GMT)
Full text and
rfc822 format available.
Message #217 received at 50344 <at> debbugs.gnu.org (full text, mbox):
On 07.10.2021 16:21, Eli Zaretskii wrote:
> As I already said, I don't want to deprecate the binding if we are not
> deprecating the command which uses it.
You know what, let's deprecate the command.
This will give us a way to notify its users more prominently, and maybe
hear back about their patterns.
In Emacs 29, we might as well un-deprecate the command itself but reuse
its binding for the branch prefix. The deprecation will already have
done its job. Or, alternatively, nobody will complain, and we could make
a more informed decision about removing it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Tue, 12 Oct 2021 12:50:01 GMT)
Full text and
rfc822 format available.
Message #220 received at 50344 <at> debbugs.gnu.org (full text, mbox):
On 08/10/2021 00:49 +0300, Dmitry Gutov wrote:
> On 07.10.2021 16:21, Eli Zaretskii wrote:
>> As I already said, I don't want to deprecate the binding if we are not
>> deprecating the command which uses it.
>
> You know what, let's deprecate the command.
>
> This will give us a way to notify its users more prominently, and maybe
> hear back about their patterns.
>
> In Emacs 29, we might as well un-deprecate the command itself but reuse
> its binding for the branch prefix. The deprecation will already have
> done its job. Or, alternatively, nobody will complain, and we could make
> a more informed decision about removing it.
It'd be great to go this way. C-x v B is perhaps acceptable, but
lowcase b is much, much better. Enough to sacrifice switching backends
for it IMO.
Filipp
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Wed, 13 Oct 2021 01:46:02 GMT)
Full text and
rfc822 format available.
Message #223 received at 50344 <at> debbugs.gnu.org (full text, mbox):
On 12.10.2021 15:48, Filipp Gunbin wrote:
> It'd be great to go this way. C-x v B is perhaps acceptable, but
> lowcase b is much, much better. Enough to sacrifice switching backends
> for it IMO.
OK, then I guess the follow-up question is, do we obsolete
'vc-transfer-file' as well? It's the only caller of 'vc-switch-backend'
outside of interactive invocations.
'vc-transfer-file' can also be used by 'C-u M-x vc-next-action', but it
seems like a very rare workflow as well. Though more plausible than the
use of 'vc-switch-backend' by itself.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Wed, 13 Oct 2021 10:14:02 GMT)
Full text and
rfc822 format available.
Message #226 received at 50344 <at> debbugs.gnu.org (full text, mbox):
On 13/10/2021 04:45 +0300, Dmitry Gutov wrote:
> On 12.10.2021 15:48, Filipp Gunbin wrote:
>> It'd be great to go this way. C-x v B is perhaps acceptable, but
>> lowcase b is much, much better. Enough to sacrifice switching backends
>> for it IMO.
>
> OK, then I guess the follow-up question is, do we obsolete
> 'vc-transfer-file' as well? It's the only caller of 'vc-switch-backend'
> outside of interactive invocations.
>
> 'vc-transfer-file' can also be used by 'C-u M-x vc-next-action', but it
> seems like a very rare workflow as well. Though more plausible than the
> use of 'vc-switch-backend' by itself.
Personally I don't use either of these commands, so this is a question
to others..
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Wed, 13 Oct 2021 23:38:02 GMT)
Full text and
rfc822 format available.
Message #229 received at 50344 <at> debbugs.gnu.org (full text, mbox):
On 13.10.2021 13:12, Filipp Gunbin wrote:
>> OK, then I guess the follow-up question is, do we obsolete
>> 'vc-transfer-file' as well? It's the only caller of 'vc-switch-backend'
>> outside of interactive invocations.
>>
>> 'vc-transfer-file' can also be used by 'C-u M-x vc-next-action', but it
>> seems like a very rare workflow as well. Though more plausible than the
>> use of 'vc-switch-backend' by itself.
> Personally I don't use either of these commands, so this is a question
> to others..
I guess there's little point to be too ambitious here, given that
vc-transfer-file is not interactive, and changing vc-next-action's
signature is not in the cards now anyway.
And we don't have an actual mechanism for obsoleting only a part of
command's calling convention.
I have pushed the change which obsoletes vc-switch-backend now.
Which should remove the main obstacle to adding the branches map with
good binding in Emacs 29.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Fri, 24 Dec 2021 11:58:02 GMT)
Full text and
rfc822 format available.
Message #232 received at 50344 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> I have pushed the change which obsoletes vc-switch-backend now.
So what is the preferred way for switching to another vc backend from
28.1 onward?
--
Philip Kaludercic
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Fri, 24 Dec 2021 12:05:01 GMT)
Full text and
rfc822 format available.
Message #235 received at 50344 <at> debbugs.gnu.org (full text, mbox):
On 24.12.2021 14:56, Philip Kaludercic wrote:
> Dmitry Gutov<dgutov <at> yandex.ru> writes:
>
>> I have pushed the change which obsoletes vc-switch-backend now.
> So what is the preferred way for switching to another vc backend from
> 28.1 onward?
I suppose it depends on your scenario.
Do you routinely use two different backends in certain projects/directories?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Fri, 24 Dec 2021 13:58:02 GMT)
Full text and
rfc822 format available.
Message #238 received at 50344 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> On 24.12.2021 14:56, Philip Kaludercic wrote:
>> Dmitry Gutov<dgutov <at> yandex.ru> writes:
>>
>>> I have pushed the change which obsoletes vc-switch-backend now.
>> So what is the preferred way for switching to another vc backend from
>> 28.1 onward?
>
> I suppose it depends on your scenario.
>
> Do you routinely use two different backends in certain
> projects/directories?
Yes, when switching between some default vc backend such as git and
vc-backup (from ELPA) to work with backup files.
--
Philip Kaludercic
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Fri, 24 Dec 2021 23:47:01 GMT)
Full text and
rfc822 format available.
Message #241 received at 50344 <at> debbugs.gnu.org (full text, mbox):
On 24.12.2021 16:57, Philip Kaludercic wrote:
> Dmitry Gutov<dgutov <at> yandex.ru> writes:
>
>> On 24.12.2021 14:56, Philip Kaludercic wrote:
>>> Dmitry Gutov<dgutov <at> yandex.ru> writes:
>>>
>>>> I have pushed the change which obsoletes vc-switch-backend now.
>>> So what is the preferred way for switching to another vc backend from
>>> 28.1 onward?
>> I suppose it depends on your scenario.
>>
>> Do you routinely use two different backends in certain
>> projects/directories?
> Yes, when switching between some default vc backend such as git and
> vc-backup (from ELPA) to work with backup files.
I haven't tried that package, but it's a little surprising that
vc-backup needs such a feature to be fully usable. I guess one option
would be for it to provide user commands, one of which which would move
it at the front of vc-handled-backends? An the other would undo that
action. Or just bundle a copy of vc-switch-backend under a different name.
But if you don't like both of those suggestions, my preferred plan would
be for you to continue using vc-switch-backend in Emacs 28. In Emacs 29,
we could un-obsolete it but put it on a different key binding (such as
'C-x v B'), freeing 'C-x v b' for the prefix map for branch operations.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Sat, 25 Dec 2021 11:38:02 GMT)
Full text and
rfc822 format available.
Message #244 received at 50344 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> On 24.12.2021 16:57, Philip Kaludercic wrote:
>> Dmitry Gutov<dgutov <at> yandex.ru> writes:
>>
>>> On 24.12.2021 14:56, Philip Kaludercic wrote:
>>>> Dmitry Gutov<dgutov <at> yandex.ru> writes:
>>>>
>>>>> I have pushed the change which obsoletes vc-switch-backend now.
>>>> So what is the preferred way for switching to another vc backend from
>>>> 28.1 onward?
>>> I suppose it depends on your scenario.
>>>
>>> Do you routinely use two different backends in certain
>>> projects/directories?
>> Yes, when switching between some default vc backend such as git and
>> vc-backup (from ELPA) to work with backup files.
>
> I haven't tried that package, but it's a little surprising that
> vc-backup needs such a feature to be fully usable. I guess one option
> would be for it to provide user commands, one of which which would
> move it at the front of vc-handled-backends? An the other would undo
> that action. Or just bundle a copy of vc-switch-backend under a
> different name.
The package is still usable, you just don't get to work on backups when
your file is managed by some other version control system (unless you
want prioritise it over any other backend). If it is the case, that
vc-switch-backend is rarely used, it seems like adding a custom
vc-backup-toggle-backend command to vc-backup would make the most sense.
> But if you don't like both of those suggestions, my preferred plan
> would be for you to continue using vc-switch-backend in Emacs 28. In
> Emacs 29, we could un-obsolete it but put it on a different key
> binding (such as 'C-x v B'), freeing 'C-x v b' for the prefix map for
> branch operations.
Maybe I missed something, but would the issue be to just unbind the key,
without obsoleting it? FWIW I would also appreciate having C-x v b
bound to branch commands.
--
Philip Kaludercic
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Sat, 25 Dec 2021 12:10:02 GMT)
Full text and
rfc822 format available.
Message #247 received at 50344 <at> debbugs.gnu.org (full text, mbox):
On 25.12.2021 14:37, Philip Kaludercic wrote:
> Dmitry Gutov <dgutov <at> yandex.ru> writes:
>
>> On 24.12.2021 16:57, Philip Kaludercic wrote:
>>> Dmitry Gutov<dgutov <at> yandex.ru> writes:
>>>
>>>> On 24.12.2021 14:56, Philip Kaludercic wrote:
>>>>> Dmitry Gutov<dgutov <at> yandex.ru> writes:
>>>>>
>>>>>> I have pushed the change which obsoletes vc-switch-backend now.
>>>>> So what is the preferred way for switching to another vc backend from
>>>>> 28.1 onward?
>>>> I suppose it depends on your scenario.
>>>>
>>>> Do you routinely use two different backends in certain
>>>> projects/directories?
>>> Yes, when switching between some default vc backend such as git and
>>> vc-backup (from ELPA) to work with backup files.
>>
>> I haven't tried that package, but it's a little surprising that
>> vc-backup needs such a feature to be fully usable. I guess one option
>> would be for it to provide user commands, one of which which would
>> move it at the front of vc-handled-backends? An the other would undo
>> that action. Or just bundle a copy of vc-switch-backend under a
>> different name.
>
> The package is still usable, you just don't get to work on backups when
> your file is managed by some other version control system (unless you
> want prioritise it over any other backend). If it is the case, that
> vc-switch-backend is rarely used, it seems like adding a custom
> vc-backup-toggle-backend command to vc-backup would make the most sense.
Yes, we all thought it is rarely used.
>> But if you don't like both of those suggestions, my preferred plan
>> would be for you to continue using vc-switch-backend in Emacs 28. In
>> Emacs 29, we could un-obsolete it but put it on a different key
>> binding (such as 'C-x v B'), freeing 'C-x v b' for the prefix map for
>> branch operations.
>
> Maybe I missed something, but would the issue be to just unbind the key,
> without obsoleting it? FWIW I would also appreciate having C-x v b
> bound to branch commands.
You missed a bunch of comments in this bug discussion.
Unbinding without obsoleting makes sense to me, but not to Eli.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Fri, 09 Sep 2022 05:47:02 GMT)
Full text and
rfc822 format available.
Message #250 received at 50344 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Thu 14 Oct 2021 at 02:37AM +03, Dmitry Gutov wrote:
> I have pushed the change which obsoletes vc-switch-backend now.
>
> Which should remove the main obstacle to adding the branches map with good
> binding in Emacs 29.
Would now perhaps be an appropriate time to go ahead and add the
branches map?
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Fri, 09 Sep 2022 06:34:01 GMT)
Full text and
rfc822 format available.
Message #253 received at 50344 <at> debbugs.gnu.org (full text, mbox):
>> I have pushed the change which obsoletes vc-switch-backend now.
>>
>> Which should remove the main obstacle to adding the branches map with good
>> binding in Emacs 29.
>
> Would now perhaps be an appropriate time to go ahead and add the
> branches map?
Agreed. I could try to prepare a complete patch tomorrow.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Fri, 09 Sep 2022 17:10:02 GMT)
Full text and
rfc822 format available.
Message #256 received at 50344 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
> Agreed. I could try to prepare a complete patch tomorrow.
Sounds good.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Sun, 11 Sep 2022 15:12:01 GMT)
Full text and
rfc822 format available.
Message #259 received at 50344 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> I have pushed the change which obsoletes vc-switch-backend now.
>>
>> Which should remove the main obstacle to adding the branches map with good
>> binding in Emacs 29.
>
> Would now perhaps be an appropriate time to go ahead and add the
> branches map?
Here is the complete patch that addresses all concerns
raised during this long discussion:
[vc-create-branch.patch (text/x-diff, inline)]
diff --git a/lisp/vc/vc.el b/lisp/vc/vc.el
index c4f0671d64..a9627a2862 100644
--- a/lisp/vc/vc.el
+++ b/lisp/vc/vc.el
@@ -449,7 +449,7 @@
;;
;; Return the common ancestor between REV1 and REV2 revisions.
-;; TAG SYSTEM
+;; TAG/BRANCH SYSTEM
;;
;; - create-tag (dir name branchp)
;;
@@ -464,8 +464,9 @@
;; - retrieve-tag (dir name update)
;;
;; Retrieve the version tagged by NAME of all registered files at or below DIR.
+;; If NAME is a branch name, switch to that branch.
;; If UPDATE is non-nil, then update buffers of any files in the
-;; tag that are currently visited. The default implementation
+;; tag/branch that are currently visited. The default implementation
;; does a sanity check whether there aren't any uncommitted changes at
;; or below DIR, and then performs a tree walk, using the `checkout'
;; function to retrieve the corresponding revisions.
@@ -664,8 +665,6 @@
;; display the branch name in the mode-line. Replace
;; vc-cvs-sticky-tag with that.
;;
-;; - Add a primitives for switching to a branch (creating it if required.
-;;
;; - Add the ability to list tags and branches.
;;
;;;; Unify two different versions of the amend capability
@@ -2432,7 +2431,23 @@ vc-create-tag
(message "Making %s... done" (if branchp "branch" "tag")))
;;;###autoload
-(defun vc-retrieve-tag (dir name)
+(defun vc-create-branch (dir name)
+ "Descending recursively from DIR, make a branch called NAME.
+After a new branch is made, the files are checked out in that new branch.
+Uses `vc-create-tag' with the non-nil arg `branchp'."
+ (interactive
+ (let ((granularity
+ (vc-call-backend (vc-responsible-backend default-directory)
+ 'revision-granularity)))
+ (list
+ (if (eq granularity 'repository)
+ default-directory
+ (read-directory-name "Directory: " default-directory default-directory t))
+ (read-string "New branch name: " nil 'vc-revision-history))))
+ (vc-create-tag dir name t))
+
+;;;###autoload
+(defun vc-retrieve-tag (dir name &optional branchp)
"For each file in or below DIR, retrieve their tagged version NAME.
NAME can name a branch, in which case this command will switch to the
named branch in the directory DIR.
@@ -2442,6 +2457,8 @@ vc-retrieve-tag
If locking is used for the files in DIR, then there must not be any
locked files at or below DIR (but if NAME is empty, locked files are
allowed and simply skipped).
+If the prefix argument BRANCHP is given, switch the branch
+and check out the files in that branch.
This function runs the hook `vc-retrieve-tag-hook' when finished."
(interactive
(let* ((granularity
@@ -2457,15 +2474,21 @@ vc-retrieve-tag
(read-directory-name "Directory: " default-directory nil t))))
(list
dir
- (vc-read-revision (format-prompt "Tag name to retrieve" "latest revisions")
+ (vc-read-revision (format-prompt
+ (if current-prefix-arg
+ "Switch to branch"
+ "Tag name to retrieve")
+ "latest revisions")
(list dir)
- (vc-responsible-backend dir)))))
+ (vc-responsible-backend dir))
+ current-prefix-arg)))
(let* ((backend (vc-responsible-backend dir))
(update (when (vc-call-backend backend 'update-on-retrieve-tag)
(yes-or-no-p "Update any affected buffers? ")))
(msg (if (or (not name) (string= name ""))
(format "Updating %s... " (abbreviate-file-name dir))
- (format "Retrieving tag %s into %s... "
+ (format "Retrieving %s %s into %s... "
+ (if branchp "branch" "tag")
name (abbreviate-file-name dir)))))
(message "%s" msg)
(vc-call-backend backend 'retrieve-tag dir name update)
@@ -2473,6 +2496,25 @@ vc-retrieve-tag
(run-hooks 'vc-retrieve-tag-hook)
(message "%s" (concat msg "done"))))
+;;;###autoload
+(defun vc-switch-branch (dir name)
+ "Switch to the branch NAME in the directory DIR.
+If NAME is empty, it refers to the latest revisions of the current branch.
+Uses `vc-retrieve-tag' with the non-nil arg `branchp'."
+ (interactive
+ (let* ((granularity
+ (vc-call-backend (vc-responsible-backend default-directory)
+ 'revision-granularity))
+ (dir
+ (if (eq granularity 'repository)
+ (expand-file-name (vc-root-dir))
+ (read-directory-name "Directory: " default-directory nil t))))
+ (list
+ dir
+ (vc-read-revision (format-prompt "Switch to branch" "latest revisions")
+ (list dir)
+ (vc-responsible-backend dir)))))
+ (vc-retrieve-tag dir name t))
;; Miscellaneous other entry points
diff --git a/lisp/vc/vc-git.el b/lisp/vc/vc-git.el
index 2941cc75be..792981b142 100644
--- a/lisp/vc/vc-git.el
+++ b/lisp/vc/vc-git.el
@@ -82,7 +82,7 @@
;; - annotate-time () OK
;; - annotate-current-time () NOT NEEDED
;; - annotate-extract-revision-at-line () OK
-;; TAG SYSTEM
+;; TAG/BRANCH SYSTEM
;; - create-tag (dir name branchp) OK
;; - retrieve-tag (dir name update) OK
;; MISCELLANEOUS
@@ -1572,13 +1590,25 @@ vc-git-annotate-extract-revision-at-line
(expand-file-name fname (vc-git-root default-directory))))
revision)))))
-;;; TAG SYSTEM
+;;; TAG/BRANCH SYSTEM
+
+(declare-function vc-read-revision "vc"
+ (prompt &optional files backend default initial-input))
(defun vc-git-create-tag (dir name branchp)
- (let ((default-directory dir))
- (and (vc-git-command nil 0 nil "update-index" "--refresh")
+ (let ((default-directory dir)
+ (start-point (when branchp (vc-read-revision
+ (format-prompt "Start point"
+ (car (vc-git-branches)))
+ (list dir) 'Git))))
+ (and (or (zerop (vc-git-command nil t nil "update-index" "--refresh"))
+ (y-or-n-p "Modified files exist. Proceed? ")
+ (user-error (format "Can't create %s with modified files"
+ (if branchp "branch" "tag"))))
(if branchp
- (vc-git-command nil 0 nil "checkout" "-b" name)
+ (vc-git-command nil 0 nil "checkout" "-b" name
+ (when (and start-point (not (eq start-point "")))
+ start-point))
(vc-git-command nil 0 nil "tag" name)))))
(defun vc-git-retrieve-tag (dir name _update)
diff --git a/lisp/vc/vc-hooks.el b/lisp/vc/vc-hooks.el
index 1f0eeb7e18..8f9e6010ee 100644
--- a/lisp/vc/vc-hooks.el
+++ b/lisp/vc/vc-hooks.el
@@ -857,6 +857,9 @@ vc-kill-buffer-hook
;; (autoload 'vc-prefix-map "vc" nil nil 'keymap)
(defvar-keymap vc-prefix-map
"a" #'vc-update-change-log
+ "b c" #'vc-create-branch
+ "b l" #'vc-print-branch-log
+ "b s" #'vc-switch-branch
"d" #'vc-dir
"g" #'vc-annotate
"G" #'vc-ignore
@@ -883,9 +887,6 @@ vc-prefix-map
(fset 'vc-prefix-map vc-prefix-map)
(define-key ctl-x-map "v" 'vc-prefix-map)
-(with-suppressed-warnings ((obsolete vc-switch-backend))
- (keymap-set vc-prefix-map "b" #'vc-switch-backend))
-
(defvar vc-menu-map
(let ((map (make-sparse-keymap "Version Control")))
;;(define-key map [show-files]
diff --git a/lisp/vc/vc-dir.el b/lisp/vc/vc-dir.el
index 068a66b25b..aa8bad7961 100644
--- a/lisp/vc/vc-dir.el
+++ b/lisp/vc/vc-dir.el
@@ -356,7 +356,7 @@ vc-dir-mode-map
(define-key map "G" #'vc-dir-ignore)
(let ((branch-map (make-sparse-keymap)))
- (define-key map "B" branch-map)
+ (define-key map "b" branch-map)
(define-key branch-map "c" #'vc-create-tag)
(define-key branch-map "l" #'vc-print-branch-log)
(define-key branch-map "s" #'vc-retrieve-tag))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Sun, 11 Sep 2022 15:26:02 GMT)
Full text and
rfc822 format available.
Message #262 received at 50344 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
> Here is the complete patch that addresses all concerns
> raised during this long discussion:
I have not tested the patch, but it makes sense to me, so feel free to
go ahead and push it (with a NEWS entry).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Mon, 12 Sep 2022 18:09:01 GMT)
Full text and
rfc822 format available.
Message #265 received at 50344 <at> debbugs.gnu.org (full text, mbox):
close 50344 29.0.50
thanks
>> Here is the complete patch that addresses all concerns
>> raised during this long discussion:
>
> I have not tested the patch, but it makes sense to me, so feel free to
> go ahead and push it (with a NEWS entry).
So now pushed with a NEWS entry, and closed.
bug marked as fixed in version 29.0.50, send any further explanations to
50344 <at> debbugs.gnu.org and Juri Linkov <juri <at> linkov.net>
Request was from
Juri Linkov <juri <at> linkov.net>
to
control <at> debbugs.gnu.org.
(Mon, 12 Sep 2022 18:09:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Mon, 12 Sep 2022 18:22:01 GMT)
Full text and
rfc822 format available.
Message #270 received at 50344 <at> debbugs.gnu.org (full text, mbox):
> Cc: 50344 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>,
> Filipp Gunbin <fgunbin <at> fastmail.fm>, Sean Whitton <spwhitton <at> spwhitton.name>
> From: Juri Linkov <juri <at> linkov.net>
> Date: Mon, 12 Sep 2022 21:07:50 +0300
>
> >> Here is the complete patch that addresses all concerns
> >> raised during this long discussion:
> >
> > I have not tested the patch, but it makes sense to me, so feel free to
> > go ahead and push it (with a NEWS entry).
>
> So now pushed with a NEWS entry, and closed.
Thanks, but what about updating the manual? Failing to update the
manuals when code changes are installed results in huge backlog of
documentation changes that at best delays release of the future
version, and at worst leaves important features undocumented.
We once had a de-facto rule that manuals should be updated together
with the code. What happened?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Mon, 12 Sep 2022 18:58:01 GMT)
Full text and
rfc822 format available.
Message #273 received at 50344 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Mon 12 Sep 2022 at 09:07PM +03, Juri Linkov wrote:
> close 50344 29.0.50
> thanks
>
>>> Here is the complete patch that addresses all concerns
>>> raised during this long discussion:
>>
>> I have not tested the patch, but it makes sense to me, so feel free to
>> go ahead and push it (with a NEWS entry).
>
> So now pushed with a NEWS entry, and closed.
Thank you!
--
Sean Whitton
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Mon, 12 Sep 2022 19:14:01 GMT)
Full text and
rfc822 format available.
Message #276 received at 50344 <at> debbugs.gnu.org (full text, mbox):
>> > I have not tested the patch, but it makes sense to me, so feel free to
>> > go ahead and push it (with a NEWS entry).
>>
>> So now pushed with a NEWS entry, and closed.
>
> Thanks, but what about updating the manual? Failing to update the
> manuals when code changes are installed results in huge backlog of
> documentation changes that at best delays release of the future
> version, and at worst leaves important features undocumented.
>
> We once had a de-facto rule that manuals should be updated together
> with the code. What happened?
Sorry, I thought that a missing sign "+++" or "---" indicates that
the decision whether and where to document this could be postponed
to a later time. But now the manual is updated.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#50344; Package
emacs.
(Tue, 13 Sep 2022 12:26:02 GMT)
Full text and
rfc822 format available.
Message #279 received at 50344 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: larsi <at> gnus.org, 50344 <at> debbugs.gnu.org, dgutov <at> yandex.ru,
> fgunbin <at> fastmail.fm, spwhitton <at> spwhitton.name
> Date: Mon, 12 Sep 2022 22:13:20 +0300
>
> > Thanks, but what about updating the manual? Failing to update the
> > manuals when code changes are installed results in huge backlog of
> > documentation changes that at best delays release of the future
> > version, and at worst leaves important features undocumented.
> >
> > We once had a de-facto rule that manuals should be updated together
> > with the code. What happened?
>
> Sorry, I thought that a missing sign "+++" or "---" indicates that
> the decision whether and where to document this could be postponed
> to a later time. But now the manual is updated.
Thanks!
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Wed, 12 Oct 2022 11:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 196 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.