OpenAutoComplete: Shell-agnostic, cross-platform autocomplete specification
github.com
github.com
I have tried writing auto-complete scripts for various tools several times. I'm quite good with bash (if I may say so myself). I've written some fairly advanced scripts and have been doing it a long time. However, despite my existing experience, writing auto completion is still a major pain in the ass. This is an area that really needs improvement.
I don't know if this project is the correct answer. I think some good discussion should be had. But I do want to say that the problem they are solving is real.
So, I've tried to make the spec as generic as possible, so it could support current compicated cases, like git (with its infinite number of commands and options), scp (with its remote file listing), some old Windows commands (like "format" for windows95 and so on).
Also, this format could be used with a single-pass recursive generator, because each usage pattern is just a JSON array and all its properties can be defined in-place. So, it would be okay to use it with languages, like C, that have no JSON serializer built-in.
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 to merge it into Oil.
Though, reading over this, it looks pretty early, and I don't think the "spec first" approach really works. That is, the spec should be derived from working code, and I believe you have to implement it in more than one shell to tell if it's feasible.
Some other links I collected:
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.
More importantly, you should consider other metadata before you go to far; binaries could carry their own documentation, licensing, dependencies... What should be in and out of scope?
[1] https://github.com/alecthomas/kingpin#bashzsh-shell-completi...
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.
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.
It actually invokes --help dynamically you hit `<TAB>` and parses the output dynamically. Whereas other systems do it offline in a batch job, e.g. some fish completions.