5 ms·

I think there is a great potential for highly interactive predictive suggestions like shown under section 2 "discoverability" in the wider Unix ecosystem, howev

by tfsh 5y ago

I think there is a great potential for highly interactive predictive suggestions like shown under section 2 "discoverability" in the wider Unix ecosystem, however discoverability is the key issue, and a massive problem space. Command line programs are black boxes (they could be pure bash, a compiled C++ binary, an npm package, etc), which means there is no programmatic standard for extracting the command set. The most backwards compatible format to achieving this would be a interface like abstraction on top of regular binaries (similar to the concept of TS interfaces adding type completion to JS) which describe a list of parameters/flags and their valid values/data types with an associated description. I think a system similar to this gives an intuitive and extensible suggestion system without requiring inconceivable redesigns to existing systems whilst maintaining the familiarity and ease of use of the regular command line.

mschrage 5y ago
The TS/JS analogy is perfect. This is exactly the approach we took with Fig. We defined a declarative standard that lets you describe the structure of any CLI tool. Fig then uses these to provide VSCode-style autocomplete in the terminal! Currently specs are manually contributed by the community, but we are planning to integrate with CLI libraries (cobra, commander, click, etc) so they can be generated automatically! You can see some examples here: https://github.com/withfig/autocomplete https://github.com/withfig/autocomplete
- michael_fine 5y ago
  Woah, that's really cool. This seems to check the first two of the article's points, approachability and discoverability. Are there any plans to implement the third point, interactivity, where you have small, dynamic guis embedded in the terminal?
  - mschrage 5y ago
    The core focus right now is autocomplete, but this is definitely an area that we want to explore more in the future!
- Siira 5y ago
  Fig seems to be reinventing the wheel. Shells already have their own completion systems to handle exactly this problem, and you can change their default frontend to something like fzf. (See, e.g., fzf-tab.)
  - michael_fine 5y ago
    While they exist, shell based autocomplete have always felt like a suboptimal solution we just accept out of historical happenstance. - You need to press tab to get any completion to display - You don't know what completion will appear when you press tab, or at most one completion displays - The completions are not at all aware of context, at best just doing some untyped fuzzy matching. Compare this to Fig, which at least seems to know what sorts of arguments each command accepts and displays a list of them - They only provide completion, not inline documentation, which is one of the big points of the article
    - chubot 5y ago
      Most of those things aren't true of fish: - It autosuggests on the command line without typing TAB - The completion is programmable, so git completion knows where a branch is expected or a path is expected, etc. - When you hit TAB, you get descriptions of each completion
    - Siira 5y ago
      None of these are true. - You can get the completions to display as you type (see zsh-autosuggestions, zsh-autocomplete). - Completions are completely aware of their context, probably more so than what fig can infer. You do need to actually load the completion functions of your binaries though, which are traditionally named ‘_command’ (so, an example would be ‘_git’). - They can provide documentation; fzf-tab does so.
    - BeetleB 5y ago
      Ouch. I suggest you learn to configure your autocomplete. Pretty much everything you say is incorrect except perhaps the last point. I've used context aware completion and with multiple options shown for over a decade!
hnlmorg 5y ago
> Command line programs are black boxes (they could be pure bash, a compiled C++ binary, an npm package, etc), which means there is no programmatic standard for extracting the command set. You say that but it's actually an easier problem to solve than it first appears. Both my shell, murex[0], and Fish[1] parse man pages to provide automatic autocompletions for flags. I also have a secondary parser for going through `--help` (et al) output for programs that don't have a man page. This isn't something that is enabled by default (because of the risk of unintended side effects) but it does work very effectively. They way I look at it though, is you want to cover as many things automatically as you can but there will always be instances where you might want to manually fine tune the completions. For that, I've also defined a vastly simplified autocompletion description format. It's basically a JSON schema that covers 99% use cases out of the box and supports shell code to be included to cover the last 1% of edge cases. This means you can write autocompletions to cover common usecases and have the shell automatically fill in any gaps you might have missed. [0] https://github.com/lmorg/murex https://github.com/lmorg/murex [1] https://fishshell.com https://fishshell.com
- chubot 5y ago
  You should publish some docs about that! Maybe other tools can pick it up. A couple years ago I wanted to tackle this problem for Oil, and there was some brainstorming here: https://github.com/oilshell/oil/wiki/Shell-Autocompletion https://github.com/oilshell/oil/wiki/Shell-Autocompletion https://github.com/oilshell/oil/wiki/Shellac-Protocol-Proposal-V2 https://github.com/oilshell/oil/wiki/Shellac-Protocol-Propos... and on the oilshell Zulip in #shell-autocompletion. The author of the Ion shell went pretty far with it, but it seems to be dormant now (or correct me if I'm wrong): https://www.redox-os.org/news/rsoc-ion-ux-2/ https://www.redox-os.org/news/rsoc-ion-ux-2/ https://www.redox-os.org/news/rsoc-ion-ux-3/ https://www.redox-os.org/news/rsoc-ion-ux-3/ https://www.redox-os.org/news/rsoc-ion-ux-4-5/ https://www.redox-os.org/news/rsoc-ion-ux-4-5/ To me a problem is that most shells like bash and even zsh are too impoverished to implement some kind of common protocol. For one, they don't work well with structured data. I just looked at Fig, and it seems interesting as well. The approach of using Mac-specific APIs and doing it outside of the shell skirts that problem. I did want to make Shellac correct and precise. Specifically it should have the invariant that if the tool suggests a completion, it should actually be a prefix to a valid command! And it was also supposed to separate the problem of completing the shell language from completing the argv language -- those are two different things. For example shells complete variables like $P -> $PATH, etc. And they complete their own builtins.

by tfsh 5y ago

mschrage 5y ago

The TS/JS analogy is perfect. This is exactly the approach we took with Fig. We defined a declarative standard that lets you describe the structure of any CLI tool. Fig then uses these to provide VSCode-style autocomplete in the terminal! Currently specs are manually contributed by the community, but we are planning to integrate with CLI libraries (cobra, commander, click, etc) so they can be generated automatically! You can see some examples here: https://github.com/withfig/autocomplete https://github.com/withfig/autocomplete

michael_fine 5y ago
Woah, that's really cool. This seems to check the first two of the article's points, approachability and discoverability. Are there any plans to implement the third point, interactivity, where you have small, dynamic guis embedded in the terminal?
- mschrage 5y ago
  The core focus right now is autocomplete, but this is definitely an area that we want to explore more in the future!
Siira 5y ago
Fig seems to be reinventing the wheel. Shells already have their own completion systems to handle exactly this problem, and you can change their default frontend to something like fzf. (See, e.g., fzf-tab.)
- michael_fine 5y ago
  While they exist, shell based autocomplete have always felt like a suboptimal solution we just accept out of historical happenstance. - You need to press tab to get any completion to display - You don't know what completion will appear when you press tab, or at most one completion displays - The completions are not at all aware of context, at best just doing some untyped fuzzy matching. Compare this to Fig, which at least seems to know what sorts of arguments each command accepts and displays a list of them - They only provide completion, not inline documentation, which is one of the big points of the article
  - chubot 5y ago
    Most of those things aren't true of fish: - It autosuggests on the command line without typing TAB - The completion is programmable, so git completion knows where a branch is expected or a path is expected, etc. - When you hit TAB, you get descriptions of each completion
  - Siira 5y ago
    None of these are true. - You can get the completions to display as you type (see zsh-autosuggestions, zsh-autocomplete). - Completions are completely aware of their context, probably more so than what fig can infer. You do need to actually load the completion functions of your binaries though, which are traditionally named ‘_command’ (so, an example would be ‘_git’). - They can provide documentation; fzf-tab does so.
  - BeetleB 5y ago
    Ouch. I suggest you learn to configure your autocomplete. Pretty much everything you say is incorrect except perhaps the last point. I've used context aware completion and with multiple options shown for over a decade!

hnlmorg 5y ago

> Command line programs are black boxes (they could be pure bash, a compiled C++ binary, an npm package, etc), which means there is no programmatic standard for extracting the command set. You say that but it's actually an easier problem to solve than it first appears. Both my shell, murex[0], and Fish[1] parse man pages to provide automatic autocompletions for flags. I also have a secondary parser for going through `--help` (et al) output for programs that don't have a man page. This isn't something that is enabled by default (because of the risk of unintended side effects) but it does work very effectively. They way I look at it though, is you want to cover as many things automatically as you can but there will always be instances where you might want to manually fine tune the completions. For that, I've also defined a vastly simplified autocompletion description format. It's basically a JSON schema that covers 99% use cases out of the box and supports shell code to be included to cover the last 1% of edge cases. This means you can write autocompletions to cover common usecases and have the shell automatically fill in any gaps you might have missed. [0] https://github.com/lmorg/murex https://github.com/lmorg/murex [1] https://fishshell.com https://fishshell.com

chubot 5y ago
You should publish some docs about that! Maybe other tools can pick it up. A couple years ago I wanted to tackle this problem for Oil, and there was some brainstorming here: https://github.com/oilshell/oil/wiki/Shell-Autocompletion https://github.com/oilshell/oil/wiki/Shell-Autocompletion https://github.com/oilshell/oil/wiki/Shellac-Protocol-Proposal-V2 https://github.com/oilshell/oil/wiki/Shellac-Protocol-Propos... and on the oilshell Zulip in #shell-autocompletion. The author of the Ion shell went pretty far with it, but it seems to be dormant now (or correct me if I'm wrong): https://www.redox-os.org/news/rsoc-ion-ux-2/ https://www.redox-os.org/news/rsoc-ion-ux-2/ https://www.redox-os.org/news/rsoc-ion-ux-3/ https://www.redox-os.org/news/rsoc-ion-ux-3/ https://www.redox-os.org/news/rsoc-ion-ux-4-5/ https://www.redox-os.org/news/rsoc-ion-ux-4-5/ To me a problem is that most shells like bash and even zsh are too impoverished to implement some kind of common protocol. For one, they don't work well with structured data. I just looked at Fig, and it seems interesting as well. The approach of using Mac-specific APIs and doing it outside of the shell skirts that problem. I did want to make Shellac correct and precise. Specifically it should have the invariant that if the tool suggests a completion, it should actually be a prefix to a valid command! And it was also supposed to separate the problem of completing the shell language from completing the argv language -- those are two different things. For example shells complete variables like $P -> $PATH, etc. And they complete their own builtins.