[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] improved bash completion v2

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2005-11-17 14:24:40 CET

This is a review of v3, but based on the discussion about v2.

Fabien COELHO wrote:
>
>> (1)
>> $ svn pe --revprop -r10 svn:l_
>> <TAB>
>> $ svn pe --revprop -r10 svn:svn:log
>>
>> This doesn't happen every time, only when trying that completion for
>> the first time after trying a different one. Perhaps that indicates
>> an uninitialised variable or similar.
>
> Maybe. I'll try to spot the reason for it.

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.

>> (2)
>> $ svn bl_ subversion/clients/cmdline/main.c
>> <TAB>
>> $ svn blank-log-msg.patch subversion/clients/cmdline/main.c
>>
>> That's the name of a local file; it should complete the subcommand
>> name "blame" instead. The filename afterwards seems to confuse it.
>
> Yep. I'm not sure the script is ok when completing inside a line rather
> than at the end. I have not tested that, so it must be wrong.

OK, you seem to have fixed completion within a line.

>> (3)
>> $ svn --help_
>> <TAB>
>> <BEEP>
>>
>> Bash beeps, presumably because this script returns no results. It
>> should recognise that there is exactly one completion, and so Bash
>> should quietly append a space. The same occurs for any
>> already-complete "-" or "--" option after a subcommand.
>
> I can look into that. This case is a little particular because the first
> argument is expected to be a subcommand, not an option.

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>

Here are some bugs that I didn't notice before:

(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, and it doesn't list "--revprop" which
is required when "--revision" is given.

(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.

The space is due to this line:

> + # 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 hope you enjoy fixing bugs! (I do.)

- 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 14:26:57 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.