11–20 of 27 posts
Earlier quoted context omitted.
That’s not standardized at all, though.
I don't think that really matters though. I'd wager that you can write 5 or 6 simple parsers and get 99% coverage of commands used.
Earlier quoted context omitted.
I don't think that really matters though. I'd wager that you can write 5 or 6 simple parsers and get 99% coverage of commands used.
Fish does something like this (it scans manpages) but generated completion is mostly useless in more complex cli programs (for example: kubectl, docker). So fish is shipped with a bunch of manually written completions for many commands.
It won't have typing, but it'd work. Do the most common argument parsing libraries from the standard libraries of the most popular languages and you're mostly there.
As a maintainer, I'm sick of having to include all sorts of different stupid autocompleters and think that it should be the job of an intelligent shell.
Earlier quoted context omitted.
Fish does something like this (it scans manpages) but generated completion is mostly useless in more complex cli programs (for example: kubectl, docker). So fish is shipped with a bunch of manually written completions for many commands.
Docker looks like it would be totally doable to me. On every page, all the options are in a standardly structured "Options:" section, all commands are in a standardly structured "Commands" section, and --help and the Options: parser will also work on the subcommands. It won't have typing, but it'd work. Do the most common argument parsing libraries from the standard libraries of the most popular languages and you're…
Earlier quoted context omitted.
That’s not standardized at all, though.
I don't think that really matters though. I'd wager that you can write 5 or 6 simple parsers and get 99% coverage of commands used.
But, even with relatively simple commands, that type of completion is very limited compared to the contextual functionality that proper zsh completion functions provide. These functions know...
* Which arguments are meaningful to complete more than once — there's no reason to complete `-a` again after you've already entered `ls -a`, but an option like `-v` might be cumulative
* Which arguments are meaningful to complete in the presence of other arguments — there's no reason to complete `-A` if you've already entered `ls -a`, since those two options are exclusive
* Whether the command supports permutation — GNU tools usually do (`ls mydir/ -al`), BSD ones usually don't (`ls -al mydir/`)
* Whether options can be stacked — some commands require `-a -b -c` instead of `-abc`
* How options can be joined to their optargs — GNU supports both `--foo bar` and `--foo=bar`, curl supports only `--foo bar`, grep supports both `-m 3` and `-m3`, tree supports only `-L 3`
* How the current argument might be affected by a previous one — if you've entered `make -C mydir` it's useful to complete targets from mydir/Makefile
* How to complete multi-part arguments — if you press tab after `ssh foo@` you probably want to complete a host name or IP
* The descriptions of arguments — zsh can explain what the difference between `always` and `auto` is, and even when an argument is arbitrary, it can explain what format it takes, what the default is, what the min/max are, &c.
* Probably most importantly, the values of optargs and operands — just blindly offering file names or presenting a metavar parsed from --help (like WHEN or TYPE) is not very nice; a useful completion function will offer package names, man-page names, compression levels, PIDs, NIC addresses, or whatever else is appropriate
I know it's technically possible to do some of this with bash completion functions, but most don't, probably because the infrastructure isn't there. fish is nicer, but even it doesn't (can't?) usually go that far with it.
This level of richness (along with related UI stuff like menu selection) is why a lot of people switch to zsh even if they don't really care about its scripting features and modules and stuff. It's probably why i started using it originally.
A way to specify completion behaviour declaratively would be really cool, but if it's just going to be dumbed down to bash-like functionality, i'm not sure it's going to gain much more traction with zsh users than _gnu_generic and bashcompinit (zsh's bash-completion compatibility shim) have.
I started down this path last year: https://github.com/oilshell/oil/wiki/Shellac-Protocol-Propos... but cut it out of the Oil project (for the forseeable future). Right now Oil takes the approach of running existing bash completion scripts, which solves the problem well enough (but leaves a few things to be desired) If someone comes up with a spec that works in at least one other shell, and some code, I'll be happy t…
Thanks for the reply! I've googled hard, but couldn't find anything like that. The problem I see is that Shellac is dynamic. So, it is pretty intrusive. This is how Click autocompletion works in Python. Also, I don't think, that Shellac is mutually exclusive with OpenAutoComplete. Being a Shell-to-autocompletion server protocol, it could use openautocomplete library as a data source.
So OpenAutoComplete is purely static then?
That makes it much less useful.
Static completion is nice to have for tools you only use from time to time, or when fishing for that argument name, but if you don't know the name of an argument etc you will often have to use `man` anyway.
The real benefit of completions are the dynamic ones, at least for me.
If such a spec does not support dynamic completion, a lot of tools will need to do their own thing anyway.
I realize that this makes it much more complex though.
I started down this path last year: https://github.com/oilshell/oil/wiki/Shellac-Protocol-Propos... but cut it out of the Oil project (for the forseeable future). Right now Oil takes the approach of running existing bash completion scripts, which solves the problem well enough (but leaves a few things to be desired) If someone comes up with a spec that works in at least one other shell, and some code, I'll be happy t…
Earlier quoted context omitted.
Thanks for the reply! I've googled hard, but couldn't find anything like that. The problem I see is that Shellac is dynamic. So, it is pretty intrusive. This is how Click autocompletion works in Python. Also, I don't think, that Shellac is mutually exclusive with OpenAutoComplete. Being a Shell-to-autocompletion server protocol, it could use openautocomplete library as a data source.
> The problem I see is that Shellac is dynamic So OpenAutoComplete is purely static then? That makes it much less useful. Static completion is nice to have for tools you only use from time to time, or when fishing for that argument name, but if you don't know the name of an argument etc you will often have to use `man` anyway. The real benefit of completions are the dynamic ones, at least for me. If such a spec does…