3 ms·

Yeah, we don't want this to be a '15th standard' situation [0] The biggest issue with traditional shell completions is that they are kind of tricky to build. E

Yeah, we don't want this to be a '15th standard' situation [0] The biggest issue with traditional shell completions is that they are kind of tricky to build. Everything is defined imperatively and written as a shell script. We wanted to lower the barrier to building completions and make a representation that works across different shells. [0] https://xkcd.com/927/ https://xkcd.com/927/

chubot 5y ago
How far have you gotten in making it work across different shells? I'd be interested in adding something to https://www.oilshell.org/ https://www.oilshell.org/, and have been thinking about this for awhile (see sibling comment in this thread) A big problem I came across is that any shell-agnostic solution is likely to be hard/impossible to implement in bash, which is the most popular shell :) Since Oil already emulates bash, it was easier just to implement bash APIs and get a huge corpus of completions for free, rather than try to develop a new corpus. It looks like Fig does things in the terminal emulator / OS and not the shell, which is interesting. Does an approach like that work on Linux? Another problem I ran into is that GNU readline is pretty limited as far as the UI goes. Fish and other shells have a better UIs but they are coupled pretty tightly to the shell.
- mschrage 5y ago
  First off, I've been a big fan of Oil shell for a while! Love the blog. :) Fig currently works with bash, zsh and fish. Since we are operating at the OS level rather than in the shell, we can get around the inflexibility of readline/bash. In theory, this approach would work anywhere. What we do currently on macOS is especially 'involved' since we need to provide the completions UI in a separate GUI app that we don't control. But, in general, integrating at the OS/application level should be possible on Linux and Window as well.
  - chubot 5y ago
    Great, yes doing it at the OS level is a creative approach and I can definitely see advantages to that. I would be worried about having to parse zsh and fish as well as bash, although I suppose coming up with something that works most of the time is feasible. As mentioned elsewhere I wanted to have some invariants for correctness, but maybe not all of them were necessary. I felt it was useful to separate the problem into completing the shell language vs. completing the argv. Feel free to join the Oil's Zulip channel (link on home page https://www.oilshell.org/ https://www.oilshell.org/)! There are the past discussions on #shell-autocompletion, going back a couple years. It's dormant now, but as mentioned, there were multiple people who wrote code towards this. And there were debates around the issues above. Another interesting channel that just started is #shell-gui. Short summary which I have yet to blog about: I just implemented "headless mode" for Oil (analogy to headless Chrome). So I can punt the UI for the shell to multiple other projects :) As I mentioned a few times, I realized the scope of the project is too big. I have a collaborator Subhav who has a prototype of a GUI in Go (and shell). Basically the shell a language- and text-oriented interface, but it does NOT have to be terminal-oriented interface. It took me awhile to realize that we shouldn't conflate those things! And it was pretty easy to tease them apart in Oil. The headless mode provides a simple interface and allows integration that can't be done with bash (or any other shell AFAIK). It needs feedback from people who want to build GUIs. An easy analogy is to imagine is a browser-like GUI for a shell with the URL bar as the prompt. The URL bar provides autocompletion, history, and shows state, etc. just like shell does.
    - mschrage 5y ago
      Just joined! Also love the idea of a headless shell. Excited to chat more
spockz 5y ago
Just the other day I added completion support for our cli build with cobra and it was <10m work. So I’m not convinced this is still a hard thing to do. (The ui of fig does look slick though.)
- mschrage 5y ago
  Glad you like the UI! Cobra and other CLI libraries, like oclif, can help you generate the skeleton of the CLI, stuff like subcommands, options, etc. (I'm in the process of writing the integration so you can generate a Fig completion spec the same way!) The difference is that with Fig you can add richer completions as well. For instance, Fig's completion for `npm install` allows you to search across all npm packages: https://twitter.com/fig/status/1385401292193865731 https://twitter.com/fig/status/1385401292193865731
  - spockz 5y ago
    Cobra has also support for completion. Through defining a ValidArgsFunction. This seems the same level as the completion shown for npm install.

chubot 5y ago

How far have you gotten in making it work across different shells? I'd be interested in adding something to https://www.oilshell.org/ https://www.oilshell.org/, and have been thinking about this for awhile (see sibling comment in this thread) A big problem I came across is that any shell-agnostic solution is likely to be hard/impossible to implement in bash, which is the most popular shell :) Since Oil already emulates bash, it was easier just to implement bash APIs and get a huge corpus of completions for free, rather than try to develop a new corpus. It looks like Fig does things in the terminal emulator / OS and not the shell, which is interesting. Does an approach like that work on Linux? Another problem I ran into is that GNU readline is pretty limited as far as the UI goes. Fish and other shells have a better UIs but they are coupled pretty tightly to the shell.

mschrage 5y ago
First off, I've been a big fan of Oil shell for a while! Love the blog. :) Fig currently works with bash, zsh and fish. Since we are operating at the OS level rather than in the shell, we can get around the inflexibility of readline/bash. In theory, this approach would work anywhere. What we do currently on macOS is especially 'involved' since we need to provide the completions UI in a separate GUI app that we don't control. But, in general, integrating at the OS/application level should be possible on Linux and Window as well.
- chubot 5y ago
  Great, yes doing it at the OS level is a creative approach and I can definitely see advantages to that. I would be worried about having to parse zsh and fish as well as bash, although I suppose coming up with something that works most of the time is feasible. As mentioned elsewhere I wanted to have some invariants for correctness, but maybe not all of them were necessary. I felt it was useful to separate the problem into completing the shell language vs. completing the argv. Feel free to join the Oil's Zulip channel (link on home page https://www.oilshell.org/ https://www.oilshell.org/)! There are the past discussions on #shell-autocompletion, going back a couple years. It's dormant now, but as mentioned, there were multiple people who wrote code towards this. And there were debates around the issues above. Another interesting channel that just started is #shell-gui. Short summary which I have yet to blog about: I just implemented "headless mode" for Oil (analogy to headless Chrome). So I can punt the UI for the shell to multiple other projects :) As I mentioned a few times, I realized the scope of the project is too big. I have a collaborator Subhav who has a prototype of a GUI in Go (and shell). Basically the shell a language- and text-oriented interface, but it does NOT have to be terminal-oriented interface. It took me awhile to realize that we shouldn't conflate those things! And it was pretty easy to tease them apart in Oil. The headless mode provides a simple interface and allows integration that can't be done with bash (or any other shell AFAIK). It needs feedback from people who want to build GUIs. An easy analogy is to imagine is a browser-like GUI for a shell with the URL bar as the prompt. The URL bar provides autocompletion, history, and shows state, etc. just like shell does.
  - mschrage 5y ago
    Just joined! Also love the idea of a headless shell. Excited to chat more

spockz 5y ago

Just the other day I added completion support for our cli build with cobra and it was <10m work. So I’m not convinced this is still a hard thing to do. (The ui of fig does look slick though.)

mschrage 5y ago
Glad you like the UI! Cobra and other CLI libraries, like oclif, can help you generate the skeleton of the CLI, stuff like subcommands, options, etc. (I'm in the process of writing the integration so you can generate a Fig completion spec the same way!) The difference is that with Fig you can add richer completions as well. For instance, Fig's completion for `npm install` allows you to search across all npm packages: https://twitter.com/fig/status/1385401292193865731 https://twitter.com/fig/status/1385401292193865731
- spockz 5y ago
  Cobra has also support for completion. Through defining a ValidArgsFunction. This seems the same level as the completion shown for npm install.