GNU bug report logs - #57807
29.0.50; Make vc-print-branch-log able to log multiple branches

Previous Next

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

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

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; Make vc-print-branch-log able to log multiple branches
Date: Wed, 14 Sep 2022 10:19:48 -0700

Hello,

vc-git-log-edit-mode is already able to properly understand git-log(1)
output which logs multiple branches.  Here's a hack to demonstrate that:

    (let ((default-directory "~/src/emacs/")
          (vc-git-log-switches
           (cons "origin/scratch/posix-spawn" vc-git-log-switches)))
      (call-process-shell-command "git branch -f tmp 4b2ca6bfc0")
      (vc-print-branch-log "tmp"))

(4b2ca6bfc0 is an old tip of master close to scratch/posix-spawn.)

An example of a case in which it is useful to produce logs like this is
when you're trying to figure out how several feature branches relate to
each other and to the trunk.

I don't think the idea of producing a log showing more than one branch
at once is fundamentally git-specific.  So I would like to extend
vc-print-branch-log to allow logging more than one branch, or
alternatively, add a vc-print-branch-logs command.  I believe that there
are two design issues, on which I'm requesting review/input:

(1) Extending the VC history functions API to permit expressing a
request for the backend to print a log of multiple branches.  We could
allow the START-REVISION argument to `print-log' to take a list of
branches, or add an additional optional argument
ADDITIONAL-START-REVISIONS.  The latter seems more robust to me.

(2) How could vc-print-branch-log prompt the user for multiple branch
names?  Magit has the user separate branch names with commas, offering
completion for each branch name.  But I suppose commas never appearing
in branch names is git-specific.  So the command could prompt the user
repeatedly for branch names, until the user hits RET to input a
zero-length branch name, indicating they've input them all.

-- 
Sean Whitton

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 57807 <at> debbugs.gnu.org
Subject: Re: bug#57807: 29.0.50;
 Make vc-print-branch-log able to log multiple branches
Date: Wed, 14 Sep 2022 20:41:35 +0300

> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Date: Wed, 14 Sep 2022 10:19:48 -0700
> 
> vc-git-log-edit-mode is already able to properly understand git-log(1)
> output which logs multiple branches.  Here's a hack to demonstrate that:
> 
>     (let ((default-directory "~/src/emacs/")
>           (vc-git-log-switches
>            (cons "origin/scratch/posix-spawn" vc-git-log-switches)))
>       (call-process-shell-command "git branch -f tmp 4b2ca6bfc0")
>       (vc-print-branch-log "tmp"))
> 
> (4b2ca6bfc0 is an old tip of master close to scratch/posix-spawn.)
> 
> An example of a case in which it is useful to produce logs like this is
> when you're trying to figure out how several feature branches relate to
> each other and to the trunk.
> 
> I don't think the idea of producing a log showing more than one branch
> at once is fundamentally git-specific.  So I would like to extend
> vc-print-branch-log to allow logging more than one branch, or
> alternatively, add a vc-print-branch-logs command.  I believe that there
> are two design issues, on which I'm requesting review/input:
> 
> (1) Extending the VC history functions API to permit expressing a
> request for the backend to print a log of multiple branches.  We could
> allow the START-REVISION argument to `print-log' to take a list of
> branches, or add an additional optional argument
> ADDITIONAL-START-REVISIONS.  The latter seems more robust to me.
> 
> (2) How could vc-print-branch-log prompt the user for multiple branch
> names?  Magit has the user separate branch names with commas, offering
> completion for each branch name.  But I suppose commas never appearing
> in branch names is git-specific.  So the command could prompt the user
> repeatedly for branch names, until the user hits RET to input a
> zero-length branch name, indicating they've input them all.

I'm not sure I understand: how is this different from what "C-x v L"
already produces?

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

From: Juri Linkov <juri <at> linkov.net>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 57807 <at> debbugs.gnu.org
Subject: Re: bug#57807: 29.0.50; Make vc-print-branch-log able to log
 multiple branches
Date: Wed, 14 Sep 2022 22:17:13 +0300

> vc-git-log-edit-mode is already able to properly understand git-log(1)

I suppose vc-git-log-view-mode, not vc-git-log-edit-mode?

> output which logs multiple branches.  Here's a hack to demonstrate that:
>
>     (let ((default-directory "~/src/emacs/")
>           (vc-git-log-switches
>            (cons "origin/scratch/posix-spawn" vc-git-log-switches)))
>       (call-process-shell-command "git branch -f tmp 4b2ca6bfc0")
>       (vc-print-branch-log "tmp"))
>
> (4b2ca6bfc0 is an old tip of master close to scratch/posix-spawn.)

Is this equivalent to `M-& git log origin/scratch/posix-spawn 4b2ca6bfc0`,
then enabling vc-git-log-view-mode in the output buffer?

> An example of a case in which it is useful to produce logs like this is
> when you're trying to figure out how several feature branches relate to
> each other and to the trunk.

I never encountered anything like this.  I wonder if this is a common need?

> I don't think the idea of producing a log showing more than one branch
> at once is fundamentally git-specific.  So I would like to extend
> vc-print-branch-log to allow logging more than one branch, or
> alternatively, add a vc-print-branch-logs command.

Maybe vc-print-branch-logs, to keep the original vc-print-branch-log
uncomplicated.

> I believe that there are two design issues, on which I'm requesting
> review/input:
>
> (1) Extending the VC history functions API to permit expressing a
> request for the backend to print a log of multiple branches.  We could
> allow the START-REVISION argument to `print-log' to take a list of
> branches, or add an additional optional argument
> ADDITIONAL-START-REVISIONS.  The latter seems more robust to me.
>
> (2) How could vc-print-branch-log prompt the user for multiple branch
> names?  Magit has the user separate branch names with commas, offering
> completion for each branch name.  But I suppose commas never appearing
> in branch names is git-specific.  So the command could prompt the user
> repeatedly for branch names, until the user hits RET to input a
> zero-length branch name, indicating they've input them all.

Maybe by using completing-read-multiple with branch names separated
by crm-separator, not necessarily comma?

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Eli Zaretskii <eliz <at> gnu.org>, 57807 <at> debbugs.gnu.org
Subject: Re: bug#57807: 29.0.50; Make vc-print-branch-log able to log
 multiple branches
Date: Wed, 14 Sep 2022 15:42:54 -0700

Hello,

On Wed 14 Sep 2022 at 08:41PM +03, Eli Zaretskii wrote:

> I'm not sure I understand: how is this different from what "C-x v L"
> already produces?

Here's an example showing logging two branches "melete" and "erebus" in
a repo of mine:

    * 8d679018 (origin/erebus) sync from melete ~/doc on erebus
    * 44398919 use light-on-dark on erebus
    * 272fc7a6 manual DPMS on erebus since it means no sound
    * 22fc8f11 erebus wallpaper
    * 512eb187 erebus terminal font size
    | * 038c0a31 (HEAD -> melete, origin/melete) sync from erebus ~/doc on melete
    | * 8197e31e modus-vivendi on melete for erebus
    |/
    * c3f9d152 (origin/master, origin/HEAD, master) attempt to ensure [...]
    * 643b20f6 spw/maybe-scale-basic-faces: simplify checking fonts were found

From this view one is able to see how erebus is 5 commits ahead of
master and melete is two (different) commits ahead of master.

-- 
Sean Whitton

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Juri Linkov <juri <at> linkov.net>, 57807 <at> debbugs.gnu.org
Subject: Re: bug#57807: 29.0.50; Make vc-print-branch-log able to log
 multiple branches
Date: Wed, 14 Sep 2022 15:44:49 -0700

Hello,

On Wed 14 Sep 2022 at 10:17PM +03, Juri Linkov wrote:

>> vc-git-log-edit-mode is already able to properly understand git-log(1)
>
> I suppose vc-git-log-view-mode, not vc-git-log-edit-mode?

Yes, sorry.

>> output which logs multiple branches.  Here's a hack to demonstrate that:
>>
>>     (let ((default-directory "~/src/emacs/")
>>           (vc-git-log-switches
>>            (cons "origin/scratch/posix-spawn" vc-git-log-switches)))
>>       (call-process-shell-command "git branch -f tmp 4b2ca6bfc0")
>>       (vc-print-branch-log "tmp"))
>>
>> (4b2ca6bfc0 is an old tip of master close to scratch/posix-spawn.)
>
> Is this equivalent to `M-& git log origin/scratch/posix-spawn 4b2ca6bfc0`,
> then enabling vc-git-log-view-mode in the output buffer?

It's not, because vc-git-log-view-mode requires you pass four or five
options to git-log to get output it can properly display.  That
knowledge is locked up in vc-git.el right now.

> Maybe vc-print-branch-logs, to keep the original vc-print-branch-log
> uncomplicated.

Perhaps a prefix argument?

>> (2) How could vc-print-branch-log prompt the user for multiple branch
>> names?  Magit has the user separate branch names with commas, offering
>> completion for each branch name.  But I suppose commas never appearing
>> in branch names is git-specific.  So the command could prompt the user
>> repeatedly for branch names, until the user hits RET to input a
>> zero-length branch name, indicating they've input them all.
>
> Maybe by using completing-read-multiple with branch names separated
> by crm-separator, not necessarily comma?

I guess it would be a strange VC system that allows spaces in branch
names, huh?

-- 
Sean Whitton

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 57807 <at> debbugs.gnu.org
Subject: Re: bug#57807: 29.0.50; Make vc-print-branch-log able to log
 multiple branches
Date: Thu, 15 Sep 2022 08:33:00 +0300

> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Date: Wed, 14 Sep 2022 15:42:54 -0700
> 
> On Wed 14 Sep 2022 at 08:41PM +03, Eli Zaretskii wrote:
> 
> > I'm not sure I understand: how is this different from what "C-x v L"
> > already produces?
> 
> Here's an example showing logging two branches "melete" and "erebus" in
> a repo of mine:
> 
>     * 8d679018 (origin/erebus) sync from melete ~/doc on erebus
>     * 44398919 use light-on-dark on erebus
>     * 272fc7a6 manual DPMS on erebus since it means no sound
>     * 22fc8f11 erebus wallpaper
>     * 512eb187 erebus terminal font size
>     | * 038c0a31 (HEAD -> melete, origin/melete) sync from erebus ~/doc on melete
>     | * 8197e31e modus-vivendi on melete for erebus
>     |/
>     * c3f9d152 (origin/master, origin/HEAD, master) attempt to ensure [...]
>     * 643b20f6 spw/maybe-scale-basic-faces: simplify checking fonts were found
> 
> >From this view one is able to see how erebus is 5 commits ahead of
> master and melete is two (different) commits ahead of master.

So the difference is that what you want to see is all the branches up
to their HEAD, and not just branches merged into the current branch,
is that right?

If so, I guess some optional feature of "C-x v L" could do that.
However, if the repository has many branches (and ours, for example,
does), wouldn't that make for a crowded and hard-t-read log buffer?
Perhaps asking the user for a name of one branch will be enough?  More
than one branch could be problematic on display, I think.

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

From: Juri Linkov <juri <at> linkov.net>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 57807 <at> debbugs.gnu.org
Subject: Re: bug#57807: 29.0.50; Make vc-print-branch-log able to log
 multiple branches
Date: Thu, 15 Sep 2022 09:59:59 +0300

>> Is this equivalent to `M-& git log origin/scratch/posix-spawn 4b2ca6bfc0`,
>> then enabling vc-git-log-view-mode in the output buffer?
>
> It's not, because vc-git-log-view-mode requires you pass four or five
> options to git-log to get output it can properly display.  That
> knowledge is locked up in vc-git.el right now.

This part is clear, but I also wanted to know what git command
corresponds to this feature.  Is it just `git log` with two
branch names on the command line?  What additional options
are required?  Maybe `--graph --oneline`?  Also I see that
git documentation mentions `--branches[=<pattern>]`.

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Juri Linkov <juri <at> linkov.net>, 57807 <at> debbugs.gnu.org
Subject: Re: bug#57807: 29.0.50; Make vc-print-branch-log able to log
 multiple branches
Date: Thu, 15 Sep 2022 09:15:56 -0700

Hello,

On Thu 15 Sep 2022 at 09:59AM +03, Juri Linkov wrote:

>>> Is this equivalent to `M-& git log origin/scratch/posix-spawn 4b2ca6bfc0`,
>>> then enabling vc-git-log-view-mode in the output buffer?
>>
>> It's not, because vc-git-log-view-mode requires you pass four or five
>> options to git-log to get output it can properly display.  That
>> knowledge is locked up in vc-git.el right now.
>
> This part is clear, but I also wanted to know what git command
> corresponds to this feature.  Is it just `git log` with two
> branch names on the command line?  What additional options
> are required?  Maybe `--graph --oneline`?  Also I see that
> git documentation mentions `--branches[=<pattern>]`.

It's something along these lines:

git log -100 --graph --decorate --date=short \
    --pretty="tformat:%d%h..: %an %ad %s" --abbrev-commit \
    BRANCH1 BRANCH2

-- 
Sean Whitton

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Eli Zaretskii <eliz <at> gnu.org>, 57807 <at> debbugs.gnu.org
Subject: Re: bug#57807: 29.0.50; Make vc-print-branch-log able to log
 multiple branches
Date: Thu, 15 Sep 2022 09:18:13 -0700

Hello,

On Thu 15 Sep 2022 at 08:33AM +03, Eli Zaretskii wrote:

> So the difference is that what you want to see is all the branches up
> to their HEAD, and not just branches merged into the current branch,
> is that right?
>
> If so, I guess some optional feature of "C-x v L" could do that.
> However, if the repository has many branches (and ours, for example,
> does), wouldn't that make for a crowded and hard-t-read log buffer?
> Perhaps asking the user for a name of one branch will be enough?  More
> than one branch could be problematic on display, I think.

Not all branches, as indeed that would quickly become unreadable.  The
user has to say exactly which branches they would like to be included.
And usually you wouldn't type more than two or three.

-- 
Sean Whitton

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 57807 <at> debbugs.gnu.org
Subject: Re: bug#57807: 29.0.50; Make vc-print-branch-log able to log
 multiple branches
Date: Thu, 15 Sep 2022 19:48:30 +0300

> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Date: Thu, 15 Sep 2022 09:18:13 -0700
> 
> Hello,
> 
> On Thu 15 Sep 2022 at 08:33AM +03, Eli Zaretskii wrote:
> 
> > So the difference is that what you want to see is all the branches up
> > to their HEAD, and not just branches merged into the current branch,
> > is that right?
> >
> > If so, I guess some optional feature of "C-x v L" could do that.
> > However, if the repository has many branches (and ours, for example,
> > does), wouldn't that make for a crowded and hard-t-read log buffer?
> > Perhaps asking the user for a name of one branch will be enough?  More
> > than one branch could be problematic on display, I think.
> 
> Not all branches, as indeed that would quickly become unreadable.  The
> user has to say exactly which branches they would like to be included.
> And usually you wouldn't type more than two or three.

I think 3 is already too much for the largely unidimensional display
we (and Git) provide.

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

From: Juri Linkov <juri <at> linkov.net>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 57807 <at> debbugs.gnu.org
Subject: Re: bug#57807: 29.0.50; Make vc-print-branch-log able to log
 multiple branches
Date: Thu, 15 Sep 2022 20:27:30 +0300

>>>> Is this equivalent to `M-& git log origin/scratch/posix-spawn 4b2ca6bfc0`,
>>>> then enabling vc-git-log-view-mode in the output buffer?
>>>
>>> It's not, because vc-git-log-view-mode requires you pass four or five
>>> options to git-log to get output it can properly display.  That
>>> knowledge is locked up in vc-git.el right now.
>>
>> This part is clear, but I also wanted to know what git command
>> corresponds to this feature.  Is it just `git log` with two
>> branch names on the command line?  What additional options
>> are required?  Maybe `--graph --oneline`?  Also I see that
>> git documentation mentions `--branches[=<pattern>]`.
>
> It's something along these lines:
>
> git log -100 --graph --decorate --date=short \
>     --pretty="tformat:%d%h..: %an %ad %s" --abbrev-commit \
>     BRANCH1 BRANCH2

This is what I proposed a long ago, maybe it makes sense here.
After invoking a vc command with a prefix argument it could pop up
the minibuffer with the command line that you can edit to add or delete
more arguments for the git command.  So e.g. after 'C-u C-x v b l BRANCH1 RET'
it will insert in the minibuffer the default command `git log ... BRANCH1`,
where you can add BRANCH2 and modify any other option.  Then it runs
this command and displays the output in the vc-git-log-view-mode buffer.

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Eli Zaretskii <eliz <at> gnu.org>, 57807 <at> debbugs.gnu.org
Subject: Re: bug#57807: 29.0.50; Make vc-print-branch-log able to log
 multiple branches
Date: Thu, 15 Sep 2022 15:29:20 -0700

Hello,

On Thu 15 Sep 2022 at 07:48PM +03, Eli Zaretskii wrote:

>> From: Sean Whitton <spwhitton <at> spwhitton.name>
>> Date: Thu, 15 Sep 2022 09:18:13 -0700
>>
>> Hello,
>>
>> On Thu 15 Sep 2022 at 08:33AM +03, Eli Zaretskii wrote:
>>
>> > So the difference is that what you want to see is all the branches up
>> > to their HEAD, and not just branches merged into the current branch,
>> > is that right?
>> >
>> > If so, I guess some optional feature of "C-x v L" could do that.
>> > However, if the repository has many branches (and ours, for example,
>> > does), wouldn't that make for a crowded and hard-t-read log buffer?
>> > Perhaps asking the user for a name of one branch will be enough?  More
>> > than one branch could be problematic on display, I think.
>> 
>> Not all branches, as indeed that would quickly become unreadable.  The
>> user has to say exactly which branches they would like to be included.
>> And usually you wouldn't type more than two or three.
>
> I think 3 is already too much for the largely unidimensional display
> we (and Git) provide.

Fair enough, but I find it useful and Magit having this feature suggests
others do too.

-- 
Sean Whitton

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Juri Linkov <juri <at> linkov.net>, 57807 <at> debbugs.gnu.org
Subject: Re: bug#57807: 29.0.50; Make vc-print-branch-log able to log
 multiple branches
Date: Thu, 15 Sep 2022 15:29:57 -0700

Hello,

On Thu 15 Sep 2022 at 08:27PM +03, Juri Linkov wrote:

>>>>> Is this equivalent to `M-& git log origin/scratch/posix-spawn 4b2ca6bfc0`,
>>>>> then enabling vc-git-log-view-mode in the output buffer?
>>>>
>>>> It's not, because vc-git-log-view-mode requires you pass four or five
>>>> options to git-log to get output it can properly display.  That
>>>> knowledge is locked up in vc-git.el right now.
>>>
>>> This part is clear, but I also wanted to know what git command
>>> corresponds to this feature.  Is it just `git log` with two
>>> branch names on the command line?  What additional options
>>> are required?  Maybe `--graph --oneline`?  Also I see that
>>> git documentation mentions `--branches[=<pattern>]`.
>>
>> It's something along these lines:
>>
>> git log -100 --graph --decorate --date=short \
>>     --pretty="tformat:%d%h..: %an %ad %s" --abbrev-commit \
>>     BRANCH1 BRANCH2
>
> This is what I proposed a long ago, maybe it makes sense here.
> After invoking a vc command with a prefix argument it could pop up
> the minibuffer with the command line that you can edit to add or delete
> more arguments for the git command.  So e.g. after 'C-u C-x v b l BRANCH1 RET'
> it will insert in the minibuffer the default command `git log ... BRANCH1`,
> where you can add BRANCH2 and modify any other option.  Then it runs
> this command and displays the output in the vc-git-log-view-mode buffer.

That would be enough for me.  vc-push already works that way.  Shall I
look into preparing a patch?

-- 
Sean Whitton

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

From: Juri Linkov <juri <at> linkov.net>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 57807 <at> debbugs.gnu.org
Subject: Re: bug#57807: 29.0.50; Make vc-print-branch-log able to log
 multiple branches
Date: Fri, 16 Sep 2022 09:59:09 +0300

>>>>>> Is this equivalent to `M-& git log origin/scratch/posix-spawn 4b2ca6bfc0`,
>>>>>> then enabling vc-git-log-view-mode in the output buffer?
>>>>>
>>>>> It's not, because vc-git-log-view-mode requires you pass four or five
>>>>> options to git-log to get output it can properly display.  That
>>>>> knowledge is locked up in vc-git.el right now.
>>>>
>>>> This part is clear, but I also wanted to know what git command
>>>> corresponds to this feature.  Is it just `git log` with two
>>>> branch names on the command line?  What additional options
>>>> are required?  Maybe `--graph --oneline`?  Also I see that
>>>> git documentation mentions `--branches[=<pattern>]`.
>>>
>>> It's something along these lines:
>>>
>>> git log -100 --graph --decorate --date=short \
>>>     --pretty="tformat:%d%h..: %an %ad %s" --abbrev-commit \
>>>     BRANCH1 BRANCH2
>>
>> This is what I proposed a long ago, maybe it makes sense here.
>> After invoking a vc command with a prefix argument it could pop up
>> the minibuffer with the command line that you can edit to add or delete
>> more arguments for the git command.  So e.g. after 'C-u C-x v b l BRANCH1 RET'
>> it will insert in the minibuffer the default command `git log ... BRANCH1`,
>> where you can add BRANCH2 and modify any other option.  Then it runs
>> this command and displays the output in the vc-git-log-view-mode buffer.
>
> That would be enough for me.  vc-push already works that way.  Shall I
> look into preparing a patch?

Yes, please try to prepare a patch, preferably without changing the
established backend API, maybe by using a global variable that later
could be reused to confirm and edit other commands.

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Juri Linkov <juri <at> linkov.net>, 57807 <at> debbugs.gnu.org
Subject: Re: bug#57807: 29.0.50; Make vc-print-branch-log able to log
 multiple branches
Date: Sun, 18 Sep 2022 14:48:11 -0700

[Message part 1 (text/plain, inline)]

Hello,

On Fri 16 Sep 2022 at 09:59AM +03, Juri Linkov wrote:

> Yes, please try to prepare a patch, preferably without changing the
> established backend API, maybe by using a global variable that later
> could be reused to confirm and edit other commands.

Here's my attempt.  Let me know what you think.

-- 
Sean Whitton

[0001-Add-support-for-user-edits-to-VC-command-arguments.patch (text/x-patch, attachment)]

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

From: Juri Linkov <juri <at> linkov.net>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 57807 <at> debbugs.gnu.org
Subject: Re: bug#57807: 29.0.50; Make vc-print-branch-log able to log
 multiple branches
Date: Mon, 19 Sep 2022 09:42:59 +0300

>> Yes, please try to prepare a patch, preferably without changing the
>> established backend API, maybe by using a global variable that later
>> could be reused to confirm and edit other commands.
>
> Here's my attempt.  Let me know what you think.

Thanks, this would be one of the most useful vc features.
I tried it out, and it works nicely.  Only minor details:

Previously 'git-pull' asked for a full command including command name "git".
I know there is no need to edit the command name "git", but splitting
the command between the prompt and the minibuffer looks a little odd.

Also the previous version of 'vc-git--pushpull' sets 'compile-command'
to the edited command.  It seems this is implemented to be able to
repeat the pull command with 'g' that is bound to 'recompile'.
I don't have a good idea how to fix this.  Maybe by setting
another global variable, e.g. 'vc-last-command' after editing
the command in 'vc-do-command'.

And also 'vc-do-async-command' reports the initial unedited command
with its "Running" message string.

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Juri Linkov <juri <at> linkov.net>, 57807 <at> debbugs.gnu.org
Subject: Re: bug#57807: 29.0.50; Make vc-print-branch-log able to log
 multiple branches
Date: Tue, 20 Sep 2022 15:54:39 -0700

[Message part 1 (text/plain, inline)]

Hello,

On Mon 19 Sep 2022 at 09:42AM +03, Juri Linkov wrote:

> Thanks, this would be one of the most useful vc features.
> I tried it out, and it works nicely.  Only minor details:
>
> Previously 'git-pull' asked for a full command including command name "git".
> I know there is no need to edit the command name "git", but splitting
> the command between the prompt and the minibuffer looks a little odd.
>
> Also the previous version of 'vc-git--pushpull' sets 'compile-command'
> to the edited command.  It seems this is implemented to be able to
> repeat the pull command with 'g' that is bound to 'recompile'.
> I don't have a good idea how to fix this.  Maybe by setting
> another global variable, e.g. 'vc-last-command' after editing
> the command in 'vc-do-command'.
>
> And also 'vc-do-async-command' reports the initial unedited command
> with its "Running" message string.

I've done something about all these in the attached.  What do you think?

-- 
Sean Whitton

[v2-0001-Add-support-for-user-edits-to-VC-command-argument.patch (text/x-patch, attachment)]

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

From: Juri Linkov <juri <at> linkov.net>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 57807 <at> debbugs.gnu.org
Subject: Re: bug#57807: 29.0.50; Make vc-print-branch-log able to log
 multiple branches
Date: Wed, 21 Sep 2022 21:52:28 +0300

> I've done something about all these in the attached.  What do you think?

Adding vc-pre-command-functions as a counterpart of the existing
vc-post-command-functions is a nice solution.  I tested everything,
and there are no more problems.  Thanks for implementing this feature.

After you will push it, it would be good also to try to generalize it
to other vc commands.  The problem is that some commands already use C-u
for other purposes, such as 'C-u C-x v L' asks for a limit.  What would be
a possible way to set vc-want-edit-command-p without using a prefix arg?
Maybe to add a new command that will only set vc-want-edit-command-p
for the next vc command, and bind it to e.g. 'C-x v c'.  Then
'C-x v c C-x v L' will allow editing the root log command.

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Juri Linkov <juri <at> linkov.net>, 57807-done <at> debbugs.gnu.org
Subject: Re: bug#57807: 29.0.50; Make vc-print-branch-log able to log
 multiple branches
Date: Wed, 21 Sep 2022 12:39:31 -0700

On Wed 21 Sep 2022 at 09:52PM +03, Juri Linkov wrote:

> Adding vc-pre-command-functions as a counterpart of the existing
> vc-post-command-functions is a nice solution.  I tested everything,
> and there are no more problems.  Thanks for implementing this feature.

Thank you for testing it.

> After you will push it, it would be good also to try to generalize it
> to other vc commands.  The problem is that some commands already use
> C-u for other purposes, such as 'C-u C-x v L' asks for a limit.  What
> would be a possible way to set vc-want-edit-command-p without using a
> prefix arg?  Maybe to add a new command that will only set
> vc-want-edit-command-p for the next vc command, and bind it to
> e.g. 'C-x v c'.  Then 'C-x v c C-x v L' will allow editing the root
> log command.

Right.  It would be good to find a way to make all this consistent.
It's unfortunate that C-x v l and C-x v P were different to begin with.

Regarding your idea, how about 'C-x V V'?  It's easier to type, won't
clash with another command we might want to put on 'c', and feels a bit
like C-x 4 4, C-x 5 5 etc.  Though, to be honest, I'd prefer it if we
could come up with something involving multiple 'C-u'.

-- 
Sean Whitton

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

From: Juri Linkov <juri <at> linkov.net>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 57807 <at> debbugs.gnu.org
Subject: Re: bug#57807: 29.0.50; Make vc-print-branch-log able to log
 multiple branches
Date: Thu, 22 Sep 2022 09:39:33 +0300

>> After you will push it, it would be good also to try to generalize it
>> to other vc commands.  The problem is that some commands already use
>> C-u for other purposes, such as 'C-u C-x v L' asks for a limit.  What
>> would be a possible way to set vc-want-edit-command-p without using a
>> prefix arg?  Maybe to add a new command that will only set
>> vc-want-edit-command-p for the next vc command, and bind it to
>> e.g. 'C-x v c'.  Then 'C-x v c C-x v L' will allow editing the root
>> log command.
>
> Right.  It would be good to find a way to make all this consistent.
> It's unfortunate that C-x v l and C-x v P were different to begin with.
>
> Regarding your idea, how about 'C-x V V'?  It's easier to type, won't
> clash with another command we might want to put on 'c', and feels a bit
> like C-x 4 4, C-x 5 5 etc.

It's easier to type the same letter again, but holding the Shift key
for V V after typing Control-X is more hard to type in a key sequence
'C-x V V C-x v L'.  It's a pity that 'C-x v v' is not available.

> Though, to be honest, I'd prefer it if we could come up with something
> involving multiple 'C-u'.

Another variant is to bind 'C-x v c' to a command that uses
'read-key-sequence' to read a key sequence from the vc keymap,
then call a command with call-interactively while let-binding
vc-want-edit-command-p, like project--switch-project-command does.
Then e.g. 'C-x v c L' will have mnemonic "vc command for root log".

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Juri Linkov <juri <at> linkov.net>
Cc: 57807 <at> debbugs.gnu.org
Subject: Re: bug#57807: 29.0.50; Make vc-print-branch-log able to log
 multiple branches
Date: Thu, 22 Sep 2022 09:10:24 -0700

Hello,

On Thu 22 Sep 2022 at 09:39AM +03, Juri Linkov wrote:

> Another variant is to bind 'C-x v c' to a command that uses
> 'read-key-sequence' to read a key sequence from the vc keymap,
> then call a command with call-interactively while let-binding
> vc-want-edit-command-p, like project--switch-project-command does.
> Then e.g. 'C-x v c L' will have mnemonic "vc command for root log".

That seems alright.  Maybe we could use some symbol, e.g. '$' or '#',
instead of a letter 'c', to distinguish its special status.

-- 
Sean Whitton

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

From: Juri Linkov <juri <at> linkov.net>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 57807 <at> debbugs.gnu.org
Subject: Re: bug#57807: 29.0.50; Make vc-print-branch-log able to log
 multiple branches
Date: Thu, 22 Sep 2022 21:44:00 +0300

>> Another variant is to bind 'C-x v c' to a command that uses
>> 'read-key-sequence' to read a key sequence from the vc keymap,
>> then call a command with call-interactively while let-binding
>> vc-want-edit-command-p, like project--switch-project-command does.
>> Then e.g. 'C-x v c L' will have mnemonic "vc command for root log".
>
> That seems alright.  Maybe we could use some symbol, e.g. '$' or '#',
> instead of a letter 'c', to distinguish its special status.

I see that 'c' might clash with a possible future command.
For example, git has a lot of commands whose names start
with the letter 'c': checkout, cherry-pick, clone, commit, ...
So the probability of the need to use 'c' is high.

OTOH, what key would keep the mnemonic of a prefix arg?
Maybe 'C-x v C-u'?

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Juri Linkov <juri <at> linkov.net>
Cc: 57807 <at> debbugs.gnu.org
Subject: Re: bug#57807: 29.0.50; Make vc-print-branch-log able to log
 multiple branches
Date: Thu, 22 Sep 2022 14:20:25 -0700

Hello,

On Thu 22 Sep 2022 at 09:44PM +03, Juri Linkov wrote:

>>> Another variant is to bind 'C-x v c' to a command that uses
>>> 'read-key-sequence' to read a key sequence from the vc keymap,
>>> then call a command with call-interactively while let-binding
>>> vc-want-edit-command-p, like project--switch-project-command does.
>>> Then e.g. 'C-x v c L' will have mnemonic "vc command for root log".
>>
>> That seems alright.  Maybe we could use some symbol, e.g. '$' or '#',
>> instead of a letter 'c', to distinguish its special status.
>
> I see that 'c' might clash with a possible future command.
> For example, git has a lot of commands whose names start
> with the letter 'c': checkout, cherry-pick, clone, commit, ...
> So the probability of the need to use 'c' is high.
>
> OTOH, what key would keep the mnemonic of a prefix arg?
> Maybe 'C-x v C-u'?

Might be confusing if you need to do C-u C-x v C-u C-x v b l ...

'$' and '!' have shell command mnemonics.

-- 
Sean Whitton

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

From: Juri Linkov <juri <at> linkov.net>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 57807 <at> debbugs.gnu.org
Subject: Re: bug#57807: 29.0.50; Make vc-print-branch-log able to log
 multiple branches
Date: Fri, 23 Sep 2022 09:42:11 +0300

>>> That seems alright.  Maybe we could use some symbol, e.g. '$' or '#',
>>> instead of a letter 'c', to distinguish its special status.
>>
>> I see that 'c' might clash with a possible future command.
>> For example, git has a lot of commands whose names start
>> with the letter 'c': checkout, cherry-pick, clone, commit, ...
>> So the probability of the need to use 'c' is high.
>>
>> OTOH, what key would keep the mnemonic of a prefix arg?
>> Maybe 'C-x v C-u'?
>
> Might be confusing if you need to do C-u C-x v C-u C-x v b l ...
>
> '$' and '!' have shell command mnemonics.

I didn't recognize '$' and '#' as shell-related symbols here
because in Emacs they have another semantics: e.g.
'C-x #' is 'server-edit', 'M-$' is ispell-checking, etc.

But 'M-!' has a clear connection with editing a shell command.  So
'C-x v !' looks like the best candidate among all considered so far.

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Juri Linkov <juri <at> linkov.net>
Cc: 57807 <at> debbugs.gnu.org
Subject: Re: bug#57807: 29.0.50; Make vc-print-branch-log able to log
 multiple branches
Date: Fri, 23 Sep 2022 09:34:02 -0700

Hello,

On Fri 23 Sep 2022 at 09:42AM +03, Juri Linkov wrote:

> I didn't recognize '$' and '#' as shell-related symbols here
> because in Emacs they have another semantics: e.g.
> 'C-x #' is 'server-edit', 'M-$' is ispell-checking, etc.
>
> But 'M-!' has a clear connection with editing a shell command.  So
> 'C-x v !' looks like the best candidate among all considered so far.

I'll look into implementing the prefix command, then, though I will need
to complete the refactoring in response to Stefan's comments first.

-- 
Sean Whitton

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Juri Linkov <juri <at> linkov.net>
Cc: 57807 <at> debbugs.gnu.org
Subject: Re: bug#57807: 29.0.50; Make vc-print-branch-log able to log
 multiple branches
Date: Sat, 24 Sep 2022 12:20:50 -0700

Hello,

On Fri 23 Sep 2022 at 09:42AM +03, Juri Linkov wrote:

>>>> That seems alright.  Maybe we could use some symbol, e.g. '$' or '#',
>>>> instead of a letter 'c', to distinguish its special status.
>>>
>>> I see that 'c' might clash with a possible future command.
>>> For example, git has a lot of commands whose names start
>>> with the letter 'c': checkout, cherry-pick, clone, commit, ...
>>> So the probability of the need to use 'c' is high.
>>>
>>> OTOH, what key would keep the mnemonic of a prefix arg?
>>> Maybe 'C-x v C-u'?
>>
>> Might be confusing if you need to do C-u C-x v C-u C-x v b l ...
>>
>> '$' and '!' have shell command mnemonics.
>
> I didn't recognize '$' and '#' as shell-related symbols here
> because in Emacs they have another semantics: e.g.
> 'C-x #' is 'server-edit', 'M-$' is ispell-checking, etc.
>
> But 'M-!' has a clear connection with editing a shell command.  So
> 'C-x v !' looks like the best candidate among all considered so far.

I'm running into the problem that you pointed out in another thread.
How do we apply vc-filter-command-function to the final VC command
that's to be run without also applying it to intermediate VC commands,
e.g. in vc-read-revision?

-- 
Sean Whitton

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

From: Juri Linkov <juri <at> linkov.net>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 57807 <at> debbugs.gnu.org
Subject: Re: bug#57807: 29.0.50; Make vc-print-branch-log able to log
 multiple branches
Date: Sat, 24 Sep 2022 22:57:16 +0300

>> But 'M-!' has a clear connection with editing a shell command.  So
>> 'C-x v !' looks like the best candidate among all considered so far.
>
> I'm running into the problem that you pointed out in another thread.
> How do we apply vc-filter-command-function to the final VC command
> that's to be run without also applying it to intermediate VC commands,
> e.g. in vc-read-revision?

Maybe there is no problem to apply the editing filter to all commands,
I don't know.  First need to try to see how it really works.

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Juri Linkov <juri <at> linkov.net>
Cc: 57807 <at> debbugs.gnu.org
Subject: Re: bug#57807: 29.0.50; Make vc-print-branch-log able to log
 multiple branches
Date: Sat, 24 Sep 2022 16:18:59 -0700

[Message part 1 (text/plain, inline)]

Hello,

On Sat 24 Sep 2022 at 10:57PM +03, Juri Linkov wrote:

>>> But 'M-!' has a clear connection with editing a shell command.  So
>>> 'C-x v !' looks like the best candidate among all considered so far.
>>
>> I'm running into the problem that you pointed out in another thread.
>> How do we apply vc-filter-command-function to the final VC command
>> that's to be run without also applying it to intermediate VC commands,
>> e.g. in vc-read-revision?
>
> Maybe there is no problem to apply the editing filter to all commands,
> I don't know.  First need to try to see how it really works.

Here's the WIP patch, hopefully it works well enough for testing.

I think it's considerably worse than C-u C-x v b l tbh.

-- 
Sean Whitton

[0001-WIP-Add-vc-edit-next-command.patch (text/x-patch, attachment)]

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

From: Juri Linkov <juri <at> linkov.net>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 57807 <at> debbugs.gnu.org
Subject: Re: bug#57807: 29.0.50; Make vc-print-branch-log able to log
 multiple branches
Date: Sun, 25 Sep 2022 10:29:39 +0300

>>> I'm running into the problem that you pointed out in another thread.
>>> How do we apply vc-filter-command-function to the final VC command
>>> that's to be run without also applying it to intermediate VC commands,
>>> e.g. in vc-read-revision?
>>
>> Maybe there is no problem to apply the editing filter to all commands,
>> I don't know.  First need to try to see how it really works.
>
> Here's the WIP patch, hopefully it works well enough for testing.

Thanks, I'm going to try it out.

> I think it's considerably worse than C-u C-x v b l tbh.

Undoubtedly, it's worse.  But it solves the problem that
all vc commands can't use C-u.

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Juri Linkov <juri <at> linkov.net>
Cc: 57807 <at> debbugs.gnu.org
Subject: Re: bug#57807: 29.0.50; Make vc-print-branch-log able to log
 multiple branches
Date: Mon, 26 Sep 2022 15:33:22 -0700

[Message part 1 (text/plain, inline)]

Hello,

On Sun 25 Sep 2022 at 10:29AM +03, Juri Linkov wrote:

>>>> I'm running into the problem that you pointed out in another thread.
>>>> How do we apply vc-filter-command-function to the final VC command
>>>> that's to be run without also applying it to intermediate VC commands,
>>>> e.g. in vc-read-revision?
>>>
>>> Maybe there is no problem to apply the editing filter to all commands,
>>> I don't know.  First need to try to see how it really works.
>>
>> Here's the WIP patch, hopefully it works well enough for testing.
>
> Thanks, I'm going to try it out.

It looks like I need to call (minibuffer-depth) like
display-buffer-override-next-command does.  Updated patch attached.

>> I think it's considerably worse than C-u C-x v b l tbh.
>
> Undoubtedly, it's worse.  But it solves the problem that
> all vc commands can't use C-u.

Just to be clear, the thing that I think is much worse is being prompted
for multiple intermediate commands, not the longer key sequence.

I realised that we could add an override inside vc-read-revision, and
potentially other places, which makes it considerably less annoying.
Done in the attached.

-- 
Sean Whitton

[v2-0001-WIP-Add-vc-edit-next-command.patch (text/x-patch, attachment)]

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

From: Juri Linkov <juri <at> linkov.net>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 57807 <at> debbugs.gnu.org
Subject: Re: bug#57807: 29.0.50; Make vc-print-branch-log able to log
 multiple branches
Date: Tue, 27 Sep 2022 21:59:04 +0300

>> Thanks, I'm going to try it out.
>
> It looks like I need to call (minibuffer-depth) like
> display-buffer-override-next-command does.  Updated patch attached.

I tested your latest patch with many vc commands, and everything
works nicely, even M-x for vc commands without a keybinding
and with a prefix arg is supported like in

  C-x v ! C-u M-x vc-log-search RET

(C-u is not needed for vc-log-search anymore,
it's just for testing a prefix arg here).

> I realised that we could add an override inside vc-read-revision, and
> potentially other places, which makes it considerably less annoying.
> Done in the attached.

Maybe it's fine to disable editing for vc-read-revision,
but I'm not sure about other commands, such as e.g.
vc-git-log-incoming that runs two git commands:

  vc-git-command fetch
  vc-git-command log

I see no problem to type an extra RET even for a secondary git command.
But it helps in case when someone really wants to edit it.

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Juri Linkov <juri <at> linkov.net>, emacs-devel <at> gnu.org
Cc: 57807 <at> debbugs.gnu.org
Subject: Re: vc-edit-next-command (was bug#57807: 29.0.50; Make
 vc-print-branch-log able to log multiple branches)
Date: Tue, 27 Sep 2022 18:15:01 -0700

[Message part 1 (text/plain, inline)]

Hello,

On Tue 27 Sep 2022 at 09:59PM +03, Juri Linkov wrote:

>>> Thanks, I'm going to try it out.
>>
>> It looks like I need to call (minibuffer-depth) like
>> display-buffer-override-next-command does.  Updated patch attached.
>
> I tested your latest patch with many vc commands, and everything
> works nicely, even M-x for vc commands without a keybinding
> and with a prefix arg is supported like in
>
>   C-x v ! C-u M-x vc-log-search RET
>
> (C-u is not needed for vc-log-search anymore,
> it's just for testing a prefix arg here).

Thank you for the through testing.

Here is a more formal patch, including manual updates.

>> I realised that we could add an override inside vc-read-revision, and
>> potentially other places, which makes it considerably less annoying.
>> Done in the attached.
>
> Maybe it's fine to disable editing for vc-read-revision,
> but I'm not sure about other commands, such as e.g.
> vc-git-log-incoming that runs two git commands:
>
>   vc-git-command fetch
>   vc-git-command log
>
> I see no problem to type an extra RET even for a secondary git command.
> But it helps in case when someone really wants to edit it.

Yeah, we should be conservative.  I've done it for only vc-read-revision
for now, and perhaps I'll raise some others later.

-- 
Sean Whitton

[v3-0001-Add-vc-edit-next-command.patch (text/x-patch, attachment)]

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

From: Juri Linkov <juri <at> linkov.net>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 57807 <at> debbugs.gnu.org, emacs-devel <at> gnu.org
Subject: Re: vc-edit-next-command (was bug#57807: 29.0.50; Make
 vc-print-branch-log able to log multiple branches)
Date: Wed, 28 Sep 2022 20:53:00 +0300

>  @menu
> +* Change Logs and VC::     Generating a change log file from log entries.
> +* VC Delete/Rename::       Deleting and renaming version-controlled files.
> +* Revision Tags::          Symbolic names for revisions.
> +* Version Headers::        Inserting version control headers into working files.
> +* Editing Shell Commands:: Editing the VC shell commands that Emacs will run.
>  @end menu

The Info node name "Editing Shell Commands" might not be obvious to
everyone when displayed in the Info completion list with 'g edit TAB'.
Maybe a better unambiguous node name while keeping it short
would be "Editing VC Commands"?

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Juri Linkov <juri <at> linkov.net>
Cc: 57807 <at> debbugs.gnu.org, emacs-devel <at> gnu.org
Subject: Re: vc-edit-next-command (was bug#57807: 29.0.50; Make
 vc-print-branch-log able to log multiple branches)
Date: Wed, 28 Sep 2022 13:41:13 -0700

Hello,

On Wed 28 Sep 2022 at 08:53PM +03, Juri Linkov wrote:

>>  @menu
>> +* Change Logs and VC::     Generating a change log file from log entries.
>> +* VC Delete/Rename::       Deleting and renaming version-controlled files.
>> +* Revision Tags::          Symbolic names for revisions.
>> +* Version Headers::        Inserting version control headers into working files.
>> +* Editing Shell Commands:: Editing the VC shell commands that Emacs will run.
>>  @end menu
>
> The Info node name "Editing Shell Commands" might not be obvious to
> everyone when displayed in the Info completion list with 'g edit TAB'.
> Maybe a better unambiguous node name while keeping it short
> would be "Editing VC Commands"?

Thanks, yes.

-- 
Sean Whitton

Previous Next

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