--- Begin Message ---
Hi, first of all thank you for your enduring maintenance of Bash.
Unfortunately I am writing to whine a bit about how the completion is working
but it will, hopefuly, lead to something good.
I wrote a little perl module to generate bash completion scripts and perl
scripts that can also generate completion. My goal was to ge more people,
mainly in the perl community but not limited to it, write completion scripts.
I must admit that I dislike programming in bash but it's nothing more than a
matter of taste. Whatever language is used I believe that a few things could
be better and that the over all usability of the command line interface and
the completion mechanism can be improved.
1/ Why aren't all the arguments to the command passed to the completion
script? This is purely and simply a lobotomization of the completion
mechanism.
2/ when show-all-if-ambiguous is set to 'off', [tab] has to be hit twice to
show all possible completions. Bash will call the completion script twice
instead for caching the result
I try to not think of the 'command line interface' as the mechanism that
allows me to write a command line but more as the interface to the command I
want to run. So, in my opinion, the completion is an intinsic part of the
command not the shell, albeit a part that is run by the shell.
What can be done in Bash to help completion scripts improve usability?
Fix #1 above and let the completion scripts use the information they can
extract from the whole line. Even if this is possible by writing bash
functions, it should be possible to do it easily in the language and command
to be run. Mechanism to handle the command line arguments most certainly
exist in the command. What is needed is just a way to apply them before the
application is really run (which I believe is as soon as you start writing
its name on the command line but this is a philosophical point of vue)
Allow for a more interactive completion. I think of a very specific point in
particular, displaying help. This would be of great help for applications
with many options and complicated interfaces, vlc, memcoder, ...
I have an application with 200+ options and I hate having to dig into the
documentation or looking in the reference manual for every second option. A
more interactive command line would have been welcome. Of course I could
provide a shell or a wizard and that's what I will do if the completion
mechanism can't be more interactive. It also has the side effect of being
portable which the completion mechanism is not.
I wrote a little prototype completion script, in perl but that's not
important, to check how the help could be provided. I liked the result and I
showed it to a few collegues who also liked it. whenever a '?' is to be
completed, the completion script provides contextual help information. I
output the help on stderr since there is no other mean to separate it from
what bash consideres to be the result. Maybe not getting results from
something stdout is a good idea.
Here are a few test case, some are implemented in the script:
$> command ?[return]
command help here or typical examples or user defined examples
$> command ?
# note allowing the users simply complement their favorit command completion
is a cool idea but one could also extract that from the command history or
save it when the command is run. This is like the call list in a phone.
#--------------------------------------------------
$> command -c?[return]
-c1 : blah blah
-c2 : blah blah
-c3 : blah blah
something the user should know about any -c option
$> command -c?
#--------------------------------------------------
$> command -c1?[return]
-c1 :
a long explaination
a long explaination
a long explaination
$> command -c1?
#--------------------------------------------------
$> command -c1 -d1 -e3?[return]
-c1 -d1 -e3 :
an explaination about the effect of the three options together
what could or should complete them
...
$> command -c1 -d1 -e3?
#--------------------------------------------------
Having the possibility to get user input could potentially make the usability
better, you get very simple wizard to complete the command line. Maybe it is
too advance for a command line completion but, as I wrote above, to me the
applicatin starts when writing its command line. I havent thought much about
the use cases yet.
Another mechanism that would be interresting is the possibility to let the
completion script check for the completness of the command line, which would
be possible if #1 is fixed. something like:
$> command -a -b [tab]
missing -c or -e !
$> command -a -b -c
$> command -a -b -c [tab]
ok, command complete
$> command -a -b -c
of course all this should be backward compatible with what exists but I
believe that is the easies part.
It's time to show everybody that the command line is not only more effective
but also more usable than GUIs.
I hope I provided enough explaination and examples to make my ideas clear. I
talked about this sortly on #bash-completion and the one person that
responded liked the idea.
Cheers, Nadim
PS: while I'm at it, there could also be a mechanism where the completion for
a certain command could register allowed options and the options that are not
allowed could be displayed in different color (user settable of course)
add_completion.sh
Description: application/shellscript
perl_completion.pl
Description: Perl program
test_command
Description: Perl program
--- End Message ---
_______________________________________________
Bash-completion-devel mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
