Hacker News Reader

Comment by chubot | Hacker News Reader

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 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:

https://github.com/oilshell/oil/wiki/Shell-Autocompletion

View on HN

There is also a Rust POC of a Shellac library/server implementation: https://gitlab.redox-os.org/AdminXVII/shellac-server

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.

Also, the accompanying code: https://github.com/openautocomplete/oactool It currently supports generating completion code for fish (experimental), but zsh and bash are similar to it, but a bit complicated, so it will be implemented later.

> 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 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.

Nope, it is not purely static. It is static-first (declarative), bot running a command and parsing its output or delegating the completion to some shell code is a planned feature.

You could make it dynamic with "bin -OpenAutoComplete" to have the binary output the Json. This would allow gradual introduction and backwards compatibility. It would also keep the completions up to date with binary versions, and still allow a shell to cache the Json.

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?

Reply on news.ycombinator.com