2006/1/25, Philip Ganchev <[EMAIL PROTECTED]>: > On 1/24/06, Axel Liljencrantz <[EMAIL PROTECTED]> wrote: > > 2006/1/24, Sean Higgins <[EMAIL PROTECTED]>: > [...] > > > I have gotten sudo to list the valid commands, but after selecting the > > > command, I would like the completion to work for the "command" and not for > > > sudo. Is there a way to do that? > > > > Hmm. Not _yet_. This is a very sane request, I'll just have to think > > about the proper way to implement it. > > Other commands that take a command as an argument are: command, > builtin, complete, exec, eval, and, or, not; and probably others.
Difference is that these commands always take a command as their first argument, unless the first argument is a switch, in which case there will be no command argument. This behaviour has been hardcoded into fish for these commands. Not an ideal solution, and once complete has been extended in the right way, this can hopefully be removed and put into the command-specific completion files. > > Perhaps `complete' could be extended to allow specifying that a > command takes a command as an argument? A more general mechanism > might allow specifying a command to run to check for valid > completions. Right now, I'm thinking that an idea proposed long ago by Netocrat might be the right thing to solve this: One could move the completion handler into shellscript. If e.g. 'complete --do-complete "ls --col"' would return all possible completions for 'ls --col' one could arbtrarily nest completions. This would open up a huge amount of possibilities. > > Perhaps a related issue is coloring <command> green if it is correct, > red if incorrect. This is somewhat semantic coloring. True. Right now, the completion code and the highlighting code are mostly separate. But it should be possible to get the command coloring information out of the completion code. I hope. -- Axel
