4 ms·
The "declarative" part doesn't really make sense IMO, but there are a bunch of links here about having a shell-agnostic system: https://github.com/oilshell/oil
by chubot 7y ago
The "declarative" part doesn't really make sense IMO, but there are a bunch of links here about having a shell-agnostic system:
https://github.com/oilshell/oil/wiki/Shell-Autocompletion https://github.com/oilshell/oil/wiki/Shell-Autocompletion
https://github.com/oilshell/oil/wiki/Projects-Already-Doing-Something-Like-Shellac https://github.com/oilshell/oil/wiki/Projects-Already-Doing-...
https://github.com/mbrubeck/compleat https://github.com/mbrubeck/compleat (one of the only grammar-based ones, looks nice but doesn't appear to have been used very much)
There are some discussions about cross-shell autocompletion on the #shell-autocompletion channel of https://oilshell.zulipchat.com/ https://oilshell.zulipchat.com/, but it didn't go that far.
The Ion work described in the sibling blog post went the furthest in terms of implementation I think, but I haven't heard anything about it in awhile.
- akdor1154 7y agoThese are awesome, thanks. By 'declarative' I mean some way of telling the shell how my bin can provide completions itself. E.g. for the AWS util, I am envisioning something like aws ec2 describe-instances --instance-id __INSTANCEID__ __INSTANCEID__: $(aws ec2 list-instances --query Instance.ID) Syntax here is not anything like a well thought out proposal, just a demonstration of what I believe to be a shell agnostic method of describing both 'where can I complete?' and 'how can I compete it?'