[Bash-completion-devel] RFC: Better long option with argument completion
Ville Skyttä
ville.skytta at iki.fi
Mon Apr 13 11:23:09 UTC 2009
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>
More information about the Bash-completion-devel
mailing list