(Regarding shell completions in general)
Generally, my process for writing is google around until I have some base level of knowledge, then building one or more demo applications to ensure my understanding is correct. Then as I'm writing the blog post I'll be refining the demo applications into examples for the blog post and/or library code that I want to open source.
I need to improve them and write a bit more information, I was writing a library to generate completion scripts for both bash and zsh, so I had to know the differences quite well.
I wonder if the API for windows auto-completion is sophisticated enough that you could add cross-platform support for this.
Does your shell_completion library work with ZSH? I'm not familiar with how sh/bash differs here from ZSH but I'd image it'd be easy to make compatible.
I'm waiting patiently for Evlish to mature so I can use their Go-like (and Go-powered) scripting language and burn my old ZSH scripts in a fire. https://github.com/elves/elvish
I talked with the author of Elvish about it, and we both want it to happen, but are both working on other things now AFAIK.
If you managed to write a working bash/zsh completion script, then kudos :) It's not easy. The basic idea is that shell completions could be both (1) shared among shells and (2) moved into the same language that the binary is written in (optionally).
Among other things I found this currently open issue that has a lot of discussion and information in it:
It might be of interest to you as well, OP?
In any event, thanks for bringing this up.
This could be useful in research to make it work for clap.
I wrote two articles that kind of highlight the differences in completions between the two, but only in regards to subcommands, since that's what I was trying to cover.
1) serializes the fields the bash completion API gives you (when you hit TAB)
2) exports them to Rust, then
3) passes the Rust program's results back to bash?
I've been working on similar problems, and I understand why that's appealing. Bash is a pretty bad language to write completion scripts in! It's really bad at string and array processing .
Though on a quick glance, if you're exporting $COMP_LINE and $COMP_POINT, then it's making the job of the completion script very hard, since you're passing off the responsibility of parsing shell to it:
In other words, if you have something like:
mycommand --flag arg\ with\ spaces --flag2=<TAB>
["mycommand", "--flag", "arg with spaces", "--flag2="] # and indicate index 3 being completed
echo $(dirname <TAB> # I don't need echo $( to complete
One consequence of this is that the bash-completion project (maintained separately from bash) actually has an ad hoc bash parser in bash! This is really bad -- unsurprisingly it has obvious bugs, like not being able to complete inside command subs. An ad hoc bash parser in Rust would also be bad.
So instead Oil parses shell for you -- since it has a shell parser! -- and then it gives you the partial argv array. So then the plugin is only responsible for what it can reasonably do.
Additional, I proposed that this could be made into a protocol that other shells consume. So instead of writing bash completions in Rust, you could write zsh/fish/bash/Oil completions in Rust.
A lot of people are already "scraping" bash completions this way, i.e. to use in zsh or their own shells, so it should not be hard to come up with something "standard", given those working examples.
If you're interested in chatting about it please join https://oilshell.zulipchat.com/ .
I wouldn't say it's the #1 priority now because Oil already emulates bash quite well, but I think a bunch of people are motivated because they 1) don't want to write completions N times, for every shell and 2) Don't want to write completions in the bash language.
home page: main page: https://github.com/oilshell/oil/wiki/Shell-Autocompletion
IMO it makes sense to write completions in whatever language the command line tool / flag parser is written in.
Thank you for the detailed feedback.
One way would be to add a new section to the binary (though that would only work with binaries), that could contain standardized data, such as a json tree of the possible completions, or the proper syntax to use the executable as a "completion server" as in your proposal.
In shell scripts, it could be one of the header lines starting with a magic comment such as "#!completion: shellac_v0.1
IMO having the shell detect that the executable supports a standardized completion format gets you halfway there ;)
The Github wiki is open to edit if you want to write up a proposal (on a new page) and discuss it on https://oilshell.zulipchat.com/ . A prototype is even better.
Although I think that perhaps running the binary with `-h` or `--help` and an env variable like SHELLAC_FEATURE_DETECT=1 might be a more backward compatible detection mechanism. If the binary doesn't support shellac, then it will probably exit quickly with help, or an error message. (And shells could cache this detection info.)
If it does support Shellac, then it will print some kind of "spec" to stdout describing where the completion is. Is it in the binary itself written in Rust/Python/etc., or is it in a separate completion script ?
The conversation has been dormant lately, but like I said I think there are a few groups of people motivated to do this (e.g. alternative shell users who don't want to rewrite completions themselves).
These shouldn't be taken for granted, I think the feature should be opt-in (and quite easy to contribute).
I would have executed the binary if there is a segment saying that it supports Shellac. The binary then detects the environment variable that's in the current spec, and prints completion information to stdout.