[Bash-completion-devel] RFC: Better long option with argument completion
ville.skytta at iki.fi
Mon Apr 13 11:23:09 UTC 2009
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...
Size: 7166 bytes
Desc: not available
More information about the Bash-completion-devel