3 ms·

Glad to hear someone is thinking about this. Right, hitting tab should never generate something invalid. That's the shell being sound. Conversely, the system sh

Glad to hear someone is thinking about this. Right, hitting tab should never generate something invalid. That's the shell being sound. Conversely, the system should also be able to determine whether what's being typed could possibly become a valid command or not. That's the shell being complete.

chubot 8y ago
Yes, I think it basically reduces to the problem of using the tool's ACTUAL parser. There are enough variations in flag syntax that it's not possible to be 100% correct without running arbitrary code. And if you're going to do that, you might as well run the code that's already written (with some caveats). That could be solved by my proposal for a "Shellac protocol", akin to Microsoft's Language Server Protocol (e.g. for VSCode): http://www.oilshell.org/blog/2018/12/05.html http://www.oilshell.org/blog/2018/12/05.html Summary: 1. The protocol was mainly motivated by the problem of bootstrapping a corpus of shell completions. Every shell has to "boil the ocean" itself, i.e. provide completions for many popular commands. git's completion is thousands of lines in each of bash, zsh, and fish. Upstream only maintains bash. 2. What I noticed in implementing completion for Oil is that bash fundamentally CONFLATES two problems: a) The problem of completing the shell language itself, e.g. ${H -> ${HOSTNAME, or ~a -> ~andy b) The problem of completing command line flag syntax. This is a huge mistake from the POV of implementation complexity. And obviously if you want shell-agnostic auto-completions, (b) needs to be separate from (a), which is shell-specific. Luckily the authors of bash-completion tried to separate these two problems a bit, and I was able to salvage most code. Since I wrote that post, and implemented a compatible completion API in OSH, it's become a lot clearer to me how the protocol should work. 3) The invariant you mention would be a third benefit of having a more principled completion API that can run arbitrary code (in arbitrary languages). Now, I'm not saying that EVERY command needs to use this. There are some engineering problems with this approach too. But I think you should have the POSSIBILITY of doing something correct if you want. Heuristics may be OK in the simple cases. But overall what I discovered is that the system is a huge mess. The bash-completion project tries to parse bash in bash, and unsurprisingly does a poor job. My upcoming blog posts will explain this.

chubot 8y ago

Yes, I think it basically reduces to the problem of using the tool's ACTUAL parser. There are enough variations in flag syntax that it's not possible to be 100% correct without running arbitrary code. And if you're going to do that, you might as well run the code that's already written (with some caveats). That could be solved by my proposal for a "Shellac protocol", akin to Microsoft's Language Server Protocol (e.g. for VSCode): http://www.oilshell.org/blog/2018/12/05.html http://www.oilshell.org/blog/2018/12/05.html Summary: 1. The protocol was mainly motivated by the problem of bootstrapping a corpus of shell completions. Every shell has to "boil the ocean" itself, i.e. provide completions for many popular commands. git's completion is thousands of lines in each of bash, zsh, and fish. Upstream only maintains bash. 2. What I noticed in implementing completion for Oil is that bash fundamentally CONFLATES two problems: a) The problem of completing the shell language itself, e.g. ${H -> ${HOSTNAME, or ~a -> ~andy b) The problem of completing command line flag syntax. This is a huge mistake from the POV of implementation complexity. And obviously if you want shell-agnostic auto-completions, (b) needs to be separate from (a), which is shell-specific. Luckily the authors of bash-completion tried to separate these two problems a bit, and I was able to salvage most code. Since I wrote that post, and implemented a compatible completion API in OSH, it's become a lot clearer to me how the protocol should work. 3) The invariant you mention would be a third benefit of having a more principled completion API that can run arbitrary code (in arbitrary languages). Now, I'm not saying that EVERY command needs to use this. There are some engineering problems with this approach too. But I think you should have the POSSIBILITY of doing something correct if you want. Heuristics may be OK in the simple cases. But overall what I discovered is that the system is a huge mess. The bash-completion project tries to parse bash in bash, and unsurprisingly does a poor job. My upcoming blog posts will explain this.