Dear Julian,
>>> $ svn pe --revprop -r10 svn:l_
>>> <TAB>
>>> $ svn pe --revprop -r10 svn:svn:log
>
> I guess this is something to do with the way Bash uses the COMP_WORDBREAKS
> variable. Maybe it reads the variable as soon as the user requests
> completion, not after the completion function returns. Therefore, maybe,
> when completing something that already begins with "svn:", instead of
> returning "svn:..." with ":" removed from the word breaks list, we need to
> put ":" back in the list (as usual) and return just the "..." part.
Maybe maybe maybe.
As I feel it is more a bash issue related to when COMP_WORDBREAKS is
handled, and that I need to tweak it a little bit for prop names...
I'm not inclined to find a fix in the short term. I'm rather planing to
caracterize the bug on a small example et send a bug report to bash
people, and see what happens there. If it is proven to be a bash
feature rather than a bug, then I may look for a fix in the script.
> ...
> As I said, it's not just the first argument that has this quirk,
> it also happens after a subcommand. You have fixed that first-argument
> case, but not the general case:
>
> $ svn log --quiet_
> <TAB>
> <BEEP>
Ok, I get it.
As the --quiet option is in the line, it is removed from the list of
available options, so the completion does not work as it is not
suggested in the choices list, because it is already there;-)
I can fix this one.
> Here are some bugs that I didn't notice before:
Sigh;-)
> (4)
> $ svn pget prop file --revision 1 -
> <TAB>
> --config-dir --non-interactive --revision -R
> --help --password --strict -h
> --no-auth-cache --recursive --username -r
>
> It lists options including "--revision" and "-r" which should be excluded
> because they have already been specified,
Humm.
I don't like having options after "free" arguments are supplied.
Otherwise, it leads to some ambiguities.
In your example, as a target file is given, it assumes that others are
arguments, so '--revison' and '1' are file names. Ok, I admit that it
is not what svn does. But I think that it is what it should do;-)
> 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.
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;-)
> (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.
>> + # 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).
> I hope you enjoy fixing bugs! (I do.)
Moderatly, esp if I disagree that something is actually a bug
and I'm not getting paid for it;-)
I'll send a 4th version that should hopefully fix what I accept as bugs of
the script. For the features, they will stay there as far as my submission
is concerned, but you'll be free to add your feature to it if you want;-)
--
Fabien.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 17 15:55:42 2005