You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Clint Adams <cl...@zsh.org> on 2003/07/20 16:27:23 UTC
subversion and programmable completion
The zsh completion function for subversion currently parses the output
of svn help <subcommand>, attempting to complete based on the contents
of the usage: and Valid options: sections.
How does the subversion team feel about providing this and additional
information in a more-machine-parseable format? I imagine that that
would lead to the bash completion becoming more intelligent as well.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] bash_completion: improvement, fixes and tests [was: Re: subversion and programmable completion]
Posted by Colin Watson <cj...@flatline.org.uk>.
On Wed, Aug 27, 2003 at 04:31:09AM +0100, Julian Foad wrote:
> Roman Neuhauser wrote:
> ># julianfoad@btopenworld.com / 2003-07-24 02:29:41 +0100:
> >>Philip Martin wrote:
> >>>Julian Foad <ju...@btopenworld.com> writes:
> >>>> sed -n -e '1,/^Available subcommands:$/d;/^$/q' \
> >>>> -e 's/[ )]//g;s/[(,]/\n/g;p' |
> >>>
> >>>$ echo 'x(y' | sed 's/[(,]/\n/g'
> >>>xny
> >>
> >>Oh dear. I don't know why you get that.
> >
> > because that's what it's supposed to do. read the sed description in
> > SUSv3. (I'd quote the two paragraphs here but I fear breaking the
>
> What and where is the "SUSv3"?
Single Unix Specification version 3, a.k.a. the new POSIX.1 standard.
See http://www.opengroup.org/onlinepubs/007904975/nfindex.html.
Cheers,
--
Colin Watson [cjwatson@flatline.org.uk]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] bash_completion: improvement, fixes and tests [was: Re:
subversion and programmable completion]
Posted by Julian Foad <ju...@btopenworld.com>.
Roman Neuhauser wrote:
> # julianfoad@btopenworld.com / 2003-07-24 02:29:41 +0100:
>
>>Philip Martin wrote:
>>
>>>Julian Foad <ju...@btopenworld.com> writes:
>>>> sed -n -e '1,/^Available subcommands:$/d;/^$/q' \
>>>> -e 's/[ )]//g;s/[(,]/\n/g;p' |
>>>
>>>$ echo 'x(y' | sed 's/[(,]/\n/g'
>>>xny
>>
>>Oh dear. I don't know why you get that.
>
> because that's what it's supposed to do. read the sed description in
> SUSv3. (I'd quote the two paragraphs here but I fear breaking the
What and where is the "SUSv3"?
> ToS...) basically:
>
> * \n is not a valid replacement metacharacter
> * behavior of \X where X is not one of &, <digit>, <delimiter> or
> <newline> is undefined
> * if you want to embed a newline in the replacement, do it this way:
>
> sed 's/BRE/first part\
> second part/'
>
> Julian, looks like your sed is broken.
> I know I'm coming awfully late, but wanted to make this clear.
Thank you for this explanation.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] bash_completion: improvement, fixes and tests [was: Re: subversion and programmable completion]
Posted by Roman Neuhauser <de...@bellavista.cz>.
# julianfoad@btopenworld.com / 2003-07-24 02:29:41 +0100:
> Philip Martin wrote:
> >Julian Foad <ju...@btopenworld.com> writes:
> >
> >> # Find the relevant lines;
> >> # remove brackets and commas; put each word on its own line.
> >> sed -n -e '1,/^Available subcommands:$/d;/^$/q' \
> >> -e 's/[ )]//g;s/[(,]/\n/g;p' |
> >
> >$ sed -V | head -1
> >GNU sed version 3.02
> >$ echo 'x(y' | sed 's/[(,]/\n/g'
> >xny
>
> Oh dear. I don't know why you get that.
because that's what it's supposed to do. read the sed description in
SUSv3. (I'd quote the two paragraphs here but I fear breaking the
ToS...) basically:
* \n is not a valid replacement metacharacter
* behavior of \X where X is not one of &, <digit>, <delimiter> or
<newline> is undefined
* if you want to embed a newline in the replacement, do it this way:
sed 's/BRE/first part\
second part/'
Julian, looks like your sed is broken.
I know I'm coming awfully late, but wanted to make this clear.
--
The From: header's been munged to get rid of unwanted cc's.
My real address: neuhauser@bellavista.cz.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] bash_completion: improvement, fixes and tests [was: Re: subversion and programmable completion]
Posted by Sebastien Cevey <se...@cine7.net>.
On Sat, Jul 26, 2003 at 01:30:19PM +0100, Julian Foad wrote:
> 1. An enhancement. On completing "st", it is annoying to stop at
> "st", "stat" and "status"; I think it should expand to "status"
> immediately.
+1
Since completion is here to complete commands, I think it makes sense
to have them, well, complete the commands rather than complete the
short forms of those commands. It is already short enough so that you
don't need completion if you want to use them, IMHO.
> This applies to most subcommands, but there are one or two
> exceptions: "co" should not expand immediately to "commit" as it
> means something else.
Well if you <TAB> after "co", you don't really expect it to complete
to "checkout", do you ? I mean why press <TAB> if you want to checkout
and you have already the command for it ?
I think that if the bash_completion is changed to complete only "long"
commands, it should complete intuitively to the command that matches
the user-input.
Oh did you mean that, eg "svn ps" <TAB> should be completed to "svn
propset" ? I'm no sure this is really useful, as I said in my first
paragraph.
--
Sebastien Cevey <se...@cine7.net>
Cine7.Net - Milcis.Net - ProgramPlay.Org
Jabber: theefer@albus.homelinux.net - ICQ: 48895760
" I saw my whole life flash before my eyes! ...It was boring! "
(Babs) [ Chicken Run ]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] bash_completion: improvement, fixes and tests [was: Re:
subversion and programmable completion]
Posted by Julian Foad <ju...@btopenworld.com>.
Philip Martin wrote:
>
>>At 2:55 AM +0100 7/26/03, Philip Martin wrote:
>>
>>>My argument is that "svn --help " breaks further completion so I don't
>>>want to completion to suggest it. ...
That's a reasonable argument. I hadn't thought of it that way around because I don't use "--help" followed by a subcommand. I think of the valid syntaxes for help as being:
svn --help|-h|-?
svn help|h|? [SUBCOMMAND...]
svn SUBCOMMAND --help|-h|-?
But "svn" accepts more than those.
I'm happy now that I understand your reasoning.
> --help option to be suggested as a completion for "svn". What do we
> gain by encouraging "svn --help" over "svn help"?
<pedantic>
You mean 'by offering "--help" as well as "help"'. We gain completion of "svn --h" to "svn --help " which tends to be what I want. (If I want help on a subcommand I use "svn help SUBCOMMAND" or "svn SUBCOMMAND --help" instead.) But as you point out, if the user asks for completion of "svn " then "--help" is listed as well as "help" and the user might choose "--help" and then try to get completion of subcommands, which doesn't work. If "--help" had not been listed, he would have been more likely to have used "help" after which subcommand completion does work. Pros and cons. I don't mind either way now.
</pedantic>
Two more-significant issues:
1. An enhancement. On completing "st", it is annoying to stop at "st", "stat" and "status"; I think it should expand to "status" immediately. This applies to most subcommands, but there are one or two exceptions: "co" should not expand immediately to "commit" as it means something else.
2. It is difficult and unhelpful to make the completion match exactly the syntax that "svn" accepts because the syntax of "svn" itself is still, in my opinion, broken (including being too loose and not clearly defined). Can we work on that instead?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] bash_completion: improvement, fixes and tests [was: Re:
subversion and programmable completion]
Posted by Philip Martin <ph...@codematters.co.uk>.
Jack Repenning <jr...@collab.net> writes:
> At 2:55 AM +0100 7/26/03, Philip Martin wrote:
>>My argument is that "svn --help " breaks further completion so I don't
>>want to completion to suggest it. The "--help" option is not special
>>here, all options break completion if they occur first, so "svn -v "
>>breaks further completion even though "svn -v st" is a valid command.
>
> Once you get to the --stuff, your completion is broken anyway, isn't
> it? But there are potentially completable things out there. Unless
> you wanted to universally encourage the neologism
>
> svn commit filename --flag
I'm not sure I understand what you mean, options can go in any order
after the sub-command. Completion for
svn commit -
svn commit SomeFile -
svn commit -m foo SomeFile AnotherFile -
all suggest a bunch of commit options.
Do you mean that completion for --username does file completion? Yes,
it could do something more sophisticated than file completion (suggest
$USER perhaps), but that doesn't appear to me to be a reason for the
--help option to be suggested as a completion for "svn". What do we
gain by encouraging "svn --help" over "svn help"?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] bash_completion: improvement, fixes and tests [was:
Re: subversion and programmable completion]
Posted by Jack Repenning <jr...@collab.net>.
At 2:55 AM +0100 7/26/03, Philip Martin wrote:
>My argument is that "svn --help " breaks further completion so I don't
>want to completion to suggest it. The "--help" option is not special
>here, all options break completion if they occur first, so "svn -v "
>breaks further completion even though "svn -v st" is a valid command.
Once you get to the --stuff, your completion is broken anyway, isn't
it? But there are potentially completable things out there. Unless
you wanted to universally encourage the neologism
svn commit filename --flag
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] bash_completion: improvement, fixes and tests [was: Re:
subversion and programmable completion]
Posted by Philip Martin <ph...@codematters.co.uk>.
Julian Foad <ju...@btopenworld.com> writes:
> I can understand you wanting completion after "svn --help " but that
> wasn't what those tests were looking at. They were looking at
> completing the first argument. My one-line patch allows "svn
> --"<TAB> to produce "--help" and "--version" as completions, rather
> than just filling in "--version" immediately. It completes "svn
> --he"<TAB> to "svn --help" immediately. It does not list svn
> subcommands after "svn --help "<TAB>; it offers "--help" and "-h"
> which is completely wrong and useless, but exactly the same as your
> version in that situation.
My argument is that "svn --help " breaks further completion so I don't
want to completion to suggest it. The "--help" option is not special
here, all options break completion if they occur first, so "svn -v "
breaks further completion even though "svn -v st" is a valid command.
At present completion on "svn " suggests commands that don't break
further completion. It seems sensible to me that completion should
encourage the use of sequences that allow further completion. For
completion to suggest a commmand that breaks further completion is not
very user-friendly.
Completion suggests "svn help", "svn h" and "svn ?", all of which
allow further completion, why should it suggest "svn --help" which
breaks further completion?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] bash_completion: improvement, fixes and tests [was: Re:
subversion and programmable completion]
Posted by Julian Foad <ju...@btopenworld.com>.
Philip Martin wrote:
> Julian Foad <ju...@btopenworld.com> writes:
>
>>>>I liked that particular completion, and it was valid.
>>>
>>>If you can make it work I will reinstate it.
>>
>>- COMPREPLY=( $( compgen -W "$cmds" -- $cur ) )
>>+ COMPREPLY=( $( compgen -W "$cmds --help -h" -- $cur ) )
>
> Does this work?
Yes :-) (see below)
> The reason I removed it originally is that if I type
> "svn --help " and then try completion I get filename completion rather
> than a list of svn commands. I tried a few things at the time but
> nothing really worked properly.
I can understand you wanting completion after "svn --help " but that wasn't what those tests were looking at. They were looking at completing the first argument. My one-line patch allows "svn --"<TAB> to produce "--help" and "--version" as completions, rather than just filling in "--version" immediately. It completes "svn --he"<TAB> to "svn --help" immediately. It does not list svn subcommands after "svn --help "<TAB>; it offers "--help" and "-h" which is completely wrong and useless, but exactly the same as your version in that situation.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] bash_completion: improvement, fixes and tests [was: Re:
subversion and programmable completion]
Posted by Philip Martin <ph...@codematters.co.uk>.
Julian Foad <ju...@btopenworld.com> writes:
>>>I liked that particular completion, and it was valid.
>> If you can make it work I will reinstate it.
[...]
> Index: tools/client-side/bash_completion
> ===================================================================
> --- tools/client-side/bash_completion (revision 6580)
> +++ tools/client-side/bash_completion (working copy)
> @@ -22,7 +22,7 @@
> stat st switch sw update up --version'
>
> if [[ $COMP_CWORD -eq 1 ]] ; then
> - COMPREPLY=( $( compgen -W "$cmds" -- $cur ) )
> + COMPREPLY=( $( compgen -W "$cmds --help -h" -- $cur ) )
> return 0
> fi
Does this work? The reason I removed it originally is that if I type
"svn --help " and then try completion I get filename completion rather
than a list of svn commands. I tried a few things at the time but
nothing really worked properly.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] bash_completion: improvement, fixes and tests [was: Re:
subversion and programmable completion]
Posted by Julian Foad <ju...@btopenworld.com>.
Philip Martin wrote:
> Julian Foad <ju...@btopenworld.com> writes:
>
>>I see that you followed up in revision 6562 with some changes so
>>that no tests would fail. In doing that, did you intentionally
>>remove the tests for completing "svn --he" etc.?
>
> It was intentional. There are lots of valid svn commands for which
> bash_completion will not work, e.g. 'svn --verbose status'. I didn't
> see why 'svn --help' needed to be supported, particularly as the
> completion for 'svn' no longer suggests '--help'.
>
>>I liked that particular completion, and it was valid.
>
> If you can make it work I will reinstate it.
Patch attached. Log message:
[[[
Reinstate completion of "svn -h" and "svn --help".
* tools/client-side/bash_completion
(_svn) Return "-h" and "--help" as extra completions for first argument.
* tools/client-side/bash_completion_test
Reinstate the corresponding tests.
]]]
> At the moment
> bash_completion doesn't suggest every possible command, but I think
> all the suggestions it offers are valid. I'd like to keep it that way.
I agree with you there.
- Julian
Re: [PATCH] bash_completion: improvement, fixes and tests [was: Re:
subversion and programmable completion]
Posted by Philip Martin <ph...@codematters.co.uk>.
Julian Foad <ju...@btopenworld.com> writes:
> I see that you followed up in revision 6562 with some changes so
> that no tests would fail. In doing that, did you intentionally
> remove the tests for completing "svn --he" etc.?
It was intentional. There are lots of valid svn commands for which
bash_completion will not work, e.g. 'svn --verbose status'. I didn't
see why 'svn --help' needed to be supported, particularly as the
completion for 'svn' no longer suggests '--help'.
> I liked that particular completion, and it was valid.
If you can make it work I will reinstate it. At the moment
bash_completion doesn't suggest every possible command, but I think
all the suggestions it offers are valid. I'd like to keep it that way.
> I spent some of today looking at fixing the handling of help options
> in "svn" itself. For instance, "svn add --version" gives the help
> for "svn add" which I do not think was intended.
That's probably an error, although not a very serious one. Ideally it
should complain that '--version' is not a valid option for 'add', and
then print the help.
> But I don't know exactly what the command-line syntax should be -
> e.g. whether "svn add cat --help" should be interpreted as an "add"
> command or a "help" command.
That appears to have the same behaviour as 'svn help add cat', and
while that is possibly a little surprising, I think it's acceptable.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] bash_completion: improvement, fixes and tests [was: Re:
subversion and programmable completion]
Posted by Julian Foad <ju...@btopenworld.com>.
Philip Martin wrote:
> Julian Foad <ju...@btopenworld.com> writes:
>
>>Attached is a version of bash_completion_test using "tr", which I
>>think is the safest solution. And to keep the patch together, the
>>original bash_completion.diff is also attached and the log message
>>is repeated here:
>
> Thanks! I checked in a slightly modified version in r6557.
Thanks. I see that you followed up in revision 6562 with some changes so that no tests would fail. In doing that, did you intentionally remove the tests for completing "svn --he" etc.? I liked that particular completion, and it was valid.
I spent some of today looking at fixing the handling of help options in "svn" itself. For instance, "svn add --version" gives the help for "svn add" which I do not think was intended. But I don't know exactly what the command-line syntax should be - e.g. whether "svn add cat --help" should be interpreted as an "add" command or a "help" command.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] bash_completion: improvement, fixes and tests [was: Re:
subversion and programmable completion]
Posted by Philip Martin <ph...@codematters.co.uk>.
Julian Foad <ju...@btopenworld.com> writes:
> But just to > check, try
>
> ~> echo 's/[(,]/\n/g' | hexdump -C
> 00000000 73 2f 5b 28 2c 5d 2f 5c 6e 2f 67 0a |s/[(,]/\n/g.|
$ echo 's/[(,]/\n/g' | hexdump -C
00000000 73 2f 5b 28 2c 5d 2f 5c 6e 2f 67 0a |s/[(,]/\n/g.|
0000000c
> Work-arounds: these all work for me; I'd be interested to know which
> work for you and which don't.
Results below are for sed and tr from the stable Debian distribution.
Looking at the package documentation, the sed info pages and faq both
cover s/// but are worded slightly differently!
> 1. Use "tr" instead of "sed"; unlike sed, its escape sequences are
> explicitly listed in its man page:
> ~> tr --version | head -1
> tr (textutils) 2.1
> ~> echo 'x(y' | tr '(,' '\n'
$ echo 'x(y' | tr '(,' '\n'
x
y
> 2. insert a literal newline character after the backslash, instead
> of 'n'; this is explicitly listed in the manual page:
> ~> echo 'x(y' | sed 's/[(,]/\
> /g'
$ echo 'x(y' | sed 's/[(,]/\
/g'
x
y
> 3. Use numeric escape sequences; these are not mentioned in the
> manual but work for me:
> ~> echo 'x(y' | sed 's/[(,]/\o012/g'
$ echo 'x(y' | sed 's/[(,]/\o012/g'
xo012y
> ~> echo 'x(y' | sed 's/[(,]/\d010/g'
$ echo 'x(y' | sed 's/[(,]/\d010/g'
xd010y
> ~> echo 'x(y' | sed 's/[(,]/\x0A/g'
$ echo 'x(y' | sed 's/[(,]/\x0A/g'
xx0Ay
> Attached is a version of bash_completion_test using "tr", which I
> think is the safest solution. And to keep the patch together, the
> original bash_completion.diff is also attached and the log message
> is repeated here:
Thanks! I checked in a slightly modified version in r6557.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] bash_completion: improvement, fixes and tests [was: Re:
subversion and programmable completion]
Posted by Julian Foad <ju...@btopenworld.com>.
Philip Martin wrote:
> Julian Foad <ju...@btopenworld.com> writes:
>
>> # Find the relevant lines;
>> # remove brackets and commas; put each word on its own line.
>> sed -n -e '1,/^Available subcommands:$/d;/^$/q' \
>> -e 's/[ )]//g;s/[(,]/\n/g;p' |
>
> $ sed -V | head -1
> GNU sed version 3.02
> $ echo 'x(y' | sed 's/[(,]/\n/g'
> xny
Oh dear. I don't know why you get that.
~> bash --version
GNU bash, version 2.05b.0(1)-release (i586-suse-linux)
~> sed --version | head -1
GNU sed version 3.02.80
~> echo 'x(y' | sed 's/[(,]/\n/g'
x
y
I get the same under bash, ash-0.2, tcsh-6.12 and zsh-4.0.6 so I don't suppose it's she shell stripping the backslash. But just to check, try
~> echo 's/[(,]/\n/g' | hexdump -C
00000000 73 2f 5b 28 2c 5d 2f 5c 6e 2f 67 0a |s/[(,]/\n/g.|
Work-arounds: these all work for me; I'd be interested to know which work for you and which don't.
1. Use "tr" instead of "sed"; unlike sed, its escape sequences are explicitly listed in its man page:
~> tr --version | head -1
tr (textutils) 2.1
~> echo 'x(y' | tr '(,' '\n'
2. insert a literal newline character after the backslash, instead of 'n'; this is explicitly listed in the manual page:
~> echo 'x(y' | sed 's/[(,]/\
/g'
3. Use numeric escape sequences; these are not mentioned in the manual but work for me:
~> echo 'x(y' | sed 's/[(,]/\o012/g'
~> echo 'x(y' | sed 's/[(,]/\d010/g'
~> echo 'x(y' | sed 's/[(,]/\x0A/g'
Attached is a version of bash_completion_test using "tr", which I think is the safest solution. And to keep the patch together, the original bash_completion.diff is also attached and the log message is repeated here:
Log message:
[[[
Improve and fix bash_completion.
Add a script that tests bash_completion, including checking the completion
results against the output of "svn help [...]".
* tools/client-side/bash_completion
(_svn) Recognise "--arg=value" as an alternative to "--arg value" (when
excluding options or synonyms that are already present).
Fix the list of subcommands and options accepted as a first argument.
Fix the lists of options accepted by various subcommands.
* tools/client-side/bash_completion_test
New file: a shell script that tests bash_completion.
]]]
Let me know if there are further problems.
- Julian
Re: [PATCH] bash_completion: improvement, fixes and tests [was: Re:
subversion and programmable completion]
Posted by Philip Martin <ph...@codematters.co.uk>.
Julian Foad <ju...@btopenworld.com> writes:
> # Print the valid subcommands for "svn", one per line, sorted.
> # Usage: get_svn_subcommands
> get_svn_subcommands() {
> svn help |
> # Find the relevant lines;
> # remove brackets and commas; put each word on its own line.
> sed -n -e '1,/^Available subcommands:$/d;/^$/q' \
> -e 's/[ )]//g;s/[(,]/\n/g;p' |
> sort
> }
[...]
> echo "Checking list of subcommands"
> HELP_SUBCMDS=`get_svn_subcommands | tr "\n" " "`
At this point "echo $HELP_SUBCMDS" gives
add cat checkoutnco cleanup commitnci copyncp deletendelnremovenrm diffndi export helpn?nh import info listnls log merge mkdir movenmvnrenamenren propdelnpdel propeditnpeditnpe propgetnpgetnpg proplistnplistnpl propsetnpsetnps resolve revert statusnstatnst switchnsw updatenup
$ sed -V | head -1
GNU sed version 3.02
$ echo 'x(y' | sed 's/[(,]/\n/g'
xny
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
[PATCH] bash_completion: improvement, fixes and tests [was: Re: subversion
and programmable completion]
Posted by Julian Foad <ju...@btopenworld.com>.
Sebastien Cevey wrote:
>
> The bash completion does not use the content of 'svn help'
> AFAIK. (we're talking about the script in tools/client-side/ right?).
...
> I had not thought of using svn help output to feed the completion
> though, that sounds quite a neat idea. Are you willing to work on it
> (you seemed to use zsh rather than bash though) ? Or do you know
> existing examples of such bash scripts that could be a basis for an
> svn one ?
Here is a step towards that.
After I fixed a trivial bug in bash_completion and added recognition of "--arg=value", I wrote a test script that (among other tests) checks the completions against "svn help". That showed me lots more bugs. So here are the fixes and the test script (which is not run automatically by "make check").
Note: the test script still fails for one reason: "--version" is described by "svn help" as an option to "svn help". That is wrong: it doesn't work like that, though it is sort of internally handled that way. "--version" and "--help" and "-h" are (should be) options to "svn" (without a subcommand). I regard this as a bug in "svn", not in "bash_completion" or "bash_completion_test".
I could adjust bash_completion and/or bash_completion_test to overlook this anomoly if you really want. It should be marked "XFAIL" but that's not easy to do. This is what it says:
~/src/subversion/tools/client-side> ./bash_completion_test ./bash_completion
Checking general completion
Checking list of subcommands
Checking list of options for each subcommand
FAIL: completions for "svn ? -" != options accepted
(completions: --quiet -q )
(svn accepts: --quiet --version -q )
FAIL: completions for "svn h -" != options accepted
(completions: --quiet -q )
(svn accepts: --quiet --version -q )
FAIL: completions for "svn help -" != options accepted
(completions: --quiet -q )
(svn accepts: --quiet --version -q )
Checking rejection of synonyms
FAILURE: at least one bash_completion test failed.
Is this acceptable the way it is, given that the test script is only to be run manually by someone who is interested in bash_completion?
- Julian
Log message:
Improve and fix bash_completion.
Add a script that tests bash_completion, including checking the completion
results against the output of "svn help [...]".
* tools/client-side/bash_completion
(_svn) Recognise "--arg=value" as an alternative to "--arg value" (when
excluding options or synonyms that are already present).
Fix the list of subcommands and options accepted as a first argument.
Fix the lists of options accepted by various subcommands.
* tools/client-side/bash_completion_test
New file: a shell script that tests bash_completion.
Re: subversion and programmable completion
Posted by Sebastien Cevey <se...@cine7.net>.
On Mon, Jul 21, 2003 at 06:52:48PM -0400, Clint Adams wrote:
> > The bash completion does not use the content of 'svn help'
> > AFAIK. (we're talking about the script in tools/client-side/ right?).
>
> The only bash completion for subversion that I've seen is
> /etc/bash_completion.d/subversion in the Debian subversion package,
> which I assume is that to which you refer.
Actually no, I refer to the bash_completion file from the svn
repository here :
http://svn.collab.net/repos/svn/trunk/tools/client-side/bash_completion
It could be that Debian has taken this file as well, I don't know.
> I seem to recall Adam Heath doing some work on emulating zsh
> completion functions in bash. Perhaps he could encapsulate the zsh
> functions somehow.
What I thought of as "improved completion" was not really taking
arguments from the `svn help` output, but also to guess what files
(for instance) would fit the command.
e.g. :
$ ls -1
foo/
bar.txt
blank.txt
$ svn st
M foo/test.txt
? bar.txt
Then `svn add ` +TAB would expand to bar.txt, since there the other
files and directories do not have to be added (they are already known
to svn). The same goes for `svn revert ` +TAB that would only expand
to foo/test.txt since the other files are either up to date or not in
the repository.
It is really some kind of "completion candy", and it can take some
time if the `svn status` command is slow (many files, etc), but I
thought that it could be a nice feature anyway (maybe as an
alternative bash_completion file).
Has anybody tried this already ?
--
Sebastien Cevey <se...@cine7.net>
Cine7.Net - Milcis.Net - ProgramPlay.Org
Jabber: theefer@albus.homelinux.net - ICQ: 48895760
" Rosebud... "
Orson Welles (Charles F. Kane) [ Citizen Kane ]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: subversion and programmable completion
Posted by Sebastien Cevey <se...@cine7.net>.
On Sun, Jul 20, 2003 at 12:27:23PM -0400, Clint Adams wrote:
> I imagine that that would lead to the bash completion becoming more
> intelligent as well.
The bash completion does not use the content of 'svn help'
AFAIK. (we're talking about the script in tools/client-side/ right?).
I wanted to work on a more powerful completion, but I was spending
most of my time learning to code in bash :) I've not totally given
up, just trying to create some time to work on that ...
I had not thought of using svn help output to feed the completion
though, that sounds quite a neat idea. Are you willing to work on it
(you seemed to use zsh rather than bash though) ? Or do you know
existing examples of such bash scripts that could be a basis for an
svn one ?
--
Sebastien Cevey <se...@cine7.net>
Cine7.Net - Milcis.Net - ProgramPlay.Org
Jabber: theefer@albus.homelinux.net - ICQ: 48895760
" Rosebud... "
Orson Welles (Charles F. Kane) [ Citizen Kane ]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: subversion and programmable completion
Posted by kf...@collab.net.
Clint Adams <cl...@zsh.org> writes:
> The zsh completion function for subversion currently parses the output
> of svn help <subcommand>, attempting to complete based on the contents
> of the usage: and Valid options: sections.
>
> How does the subversion team feel about providing this and additional
> information in a more-machine-parseable format? I imagine that that
> would lead to the bash completion becoming more intelligent as well.
What's not machine parseable about the current output?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org