3 ms·

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

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.

GamePad64 6y ago
Also, the accompanying code: https://github.com/openautocomplete/oactool 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_duke 6y ago
> 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.
- GamePad64 6y ago
  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.
  - irq-1 6y ago
    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?

GamePad64 6y ago

Also, the accompanying code: https://github.com/openautocomplete/oactool 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_duke 6y ago

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

GamePad64 6y ago
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.
- irq-1 6y ago
  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?