[Bash-completion-devel] RFC: Better long option with argument completion

[Ville Skyttä]

Hello,

Currently completion of long options that take arguments is pretty bad.  For 
an example, many completions list things like "--foo=" in their compgen -W 
strings which end up completed as "--foo\= " which is annoying, especially the 
trailing space.  Some completions use "internal" workarounds for this which is 
suboptimal from maintenance point of view.

With bash 4.x I suppose we could use compopt -o nospace but I suggest doing 
something about this already now.

So I came up with the attached patch.  The idea is that for all long options 
that take an argument and can take it in both "--foo=bar" and "--foo bar" 
forms, we only list "--foo" (not "--foo=") in completions, run it through 
_split_longopt, and code the completion logic as if "--foo bar" had been 
passed and it'll work for both "--foo=bar" and "--foo bar".

Additionally, using the return value of _split_longopt we can "return 0" early 
to avoid doing potentially weird/slow things with last resort default 
completions later when a --foo=bar thing is being completed and we don't have 
specific completions for the required argument for --foo (the assumption being 
that if --foo= is specified, --foo requires an argument).

The attached patch contains _split_longopt and a few modifications to existing 
completions to illustrate its usage and how it helps and what kind of cleanups 
and improved features it allows.

Comments?  I would like to commit _split_longopt soon and start changing 
existing completions to use it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: split_longopt.patch
Type: text/x-patch
Size: 7166 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/bash-completion-devel/attachments/20090413/82e3cc74/attachment-0001.bin>