Fabien COELHO wrote:
>
>> (4)
>> $ svn pget prop file --revision 1 -
>> <TAB>
>> --config-dir --non-interactive --revision -R
>> --help --password --strict -h
>> --no-auth-cache --recursive --username -r
[...]
>> and it doesn't list "--revprop" which is required when "--revision" is
>> given.
>
> Double no on this one :
>
> --revprop is *not* required with --revision, you can ask for the value
> of simple property on a file at a given revision in the past.
Oops - my mistake. I wrote that with an example of "propset" (where
"--revprop" is required iff --revision is given) and then "simplified" the example.
> They are both mandatory for revision properties... but "prop" is not.
> You can have that by adding it to the "SVN_REV_PROP" env variable.
> The default is to assume that it is a file property so only --revision
> is allowed.
>
> Thus it is a feature, not a bug;-)
OK. (For "pset" and "pedit", then, it shouldn't suggest "--revision" when the
property name is not a revprop, but I don't think that's very important.)
>> (5)
>> $ svn cp a b --_
>> <TAB>
>> $ svn cp a b -- _
>>
>> After both arguments have been given to a command like "cp", it no
>> longer recognises options, and instead silently inserts a space.
>
> Yes, idem this is a partially a *feature*, no options after the
> arguments are supplied seems a sensible rule to me. It should have not
> proposed '--'
> as a completion. I guess bash did it.
Well, it's inconsistent with how it behaves on other commands. Only the
two-argument commands suffer from this problem. For other commands, your code
offers the correct choice of options in this position.
$ svn diff a b --_
<TAB>
--config-dir --force --no-auth-cache [...]
>>> + # some way to tell 'no completion'... is there a better one?
>>> + COMPREPLY=( '' )
>>
>> This tells Bash that the only completion for this argument is the
>> empty string. I think it is more correct, and better in practice, to
>> return an empty array; although Bash then uses filenames for
>> completion, it is more likely to result in a beep (depending on what
>> files are present) rather than a space. (As an enhancement, maybe
>> there is some way to tell Bash not to use file names for completion.)
>
> I disagree.
>
> I do want to stop the file completion, because this case is triggered
> when no more arguments are expected (e.g. you're doing a cp and you
> already gave 2 arguments, whatever you're adding is garbage and should
> trigger an error of the completion, but not a standard file completion).
That's fine if you can find a way to stop the completion, but what you're doing
doesn't stop it. It stops _file name_ completion, but it doesn't stop
_completion_. It just makes Bash think the word you have started is OK, and
considers it complete:
$ svn cp a b c_
<TAB>
$ svn cp a b c _
Here's a kind-of-ugly idea that has the sort of effect you want:
> # return some results that have no common prefix, so Bash won't
> # use them, but when displayed (in alphabetical order) they form
> # an error message
> COMPREPLY=( 'bash_completion:' 'only two arguments wanted' )
$ svn cp a b c_
<TAB>
<BEEP>
<TAB>
bash_completion: only two arguments wanted
$ svn cp a b c_
What happens is that when Bash gets a list of completions it _replaces_ the
corrent word with the common prefix of all the completions, unless there is no
common prefix in which case it complains and (on a second press of <TAB>) lists
the completions. This might help to explain the "svn:svn:log" problem.
This has the correct effect on the command line: it is unaltered and a beep is
given. You might not like the text that is printed. It might be possible to
make something almost invisible be printed, e.g. by returning two different
invisible words: say a space and a tab.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 17 17:04:45 2005