3 ms·

I started down this path last year: https://github.com/oilshell/oil/wiki/Shellac-Protocol-Proposal https://github.com/oilshell/oil/wiki/Shellac-Protocol-Propos

by chubot 6y ago

I started down this path last year: https://github.com/oilshell/oil/wiki/Shellac-Protocol-Proposal 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 https://github.com/oilshell/oil/wiki/Shell-Autocompletion

GamePad64 6y ago
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?
the_duke 6y ago
There is also a Rust POC of a Shellac library/server implementation: https://gitlab.redox-os.org/AdminXVII/shellac-server https://gitlab.redox-os.org/AdminXVII/shellac-server

by chubot 6y ago

GamePad64 6y ago

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?

the_duke 6y ago

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