[michael_fine]

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

[Siira]

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]

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!

[chubot]

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

[hnlmorg]

> You need to press tab to get any completion to display

You only need to do that if you want to bring focus to the completion selection. A lot of interfaces will display completions without the need to press tab. And to be honest, while I'm all for making things simpler, I don't think pressing tab is a hard barrier to expect people to overcome.

> You don't know what completion will appear when you press tab, or at most one completion displays

This doesn't make a whole lot of sense. If you know what completion is going to appear then you're hitting tab to save keystrokes. If you don't know the command then of course you're not going to know what completions will display since the whole point of hitting tab is to explore the valid options.

> The completions are not at all aware of context...

That's not even remotely true of Bash, let alone any modern shells like murex and fish.

Murex even goes one step further and doesn't just display the parameters in context of the command that's being run (eg suggesting names of available branches when running `git checkout <tab>`) but it runs the entire command line that precedes it to understand the data being passed into the STDIN of the current command. This is useful when using tools that inspect JSON properties for example:

    murex-dev»  open https://api.github.com/repos/lmorg/murex/issues | [[  ]]                 
    (builtin) Outputs an element from a nested structure                                                                                      
     /0                                /0/active_lock_reason             /0/assignee                       /0/assignees                     
     /0/author_association             /0/body                           /0/closed_at                      /0/comments                      
     /0/comments_url                   /0/created_at                     /0/events_url                     /0/html_url                      
     /0/id                             /0/labels                         /0/labels/0                       /0/labels/0/color                
     /0/labels/0/default               /0/labels/0/description           /0/labels/0/id                    /0/labels/0/name                 
     /0/labels/0/node_id               /0/labels/0/url                   /0/labels_url                     /0/locked  

> They only provide completion, not inline documentation, which is one of the big points of the article

Nope. In murex if you type `kill <tab>` you'll get a list of process names instead of PIDs and when you select one it is still the PID that is placed.

    murex-dev» kill
    (/bin/kill) kill - terminate or signal a process
     543     /Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper (Renderer).app/Contents/MacOS/Code...
     738     /usr/libexec/promotedcontentd
     1645    /System/Library/PrivateFrameworks/DifferentialPrivacy.framework/XPCServices/DPSubmissionService.xpc/Con...
     17903   /Applications/Slack.app/Contents/Frameworks/Electron Framework.framework/Helpers/chrome_crashpad_handle...
     47968   /System/Library/Frameworks/Metal.framework/Versions/A/XPCServices/MTLCompilerService.xpc/Contents/MacOS...
     496     /Applications/iTerm.app/Contents/XPCServices/pidinfo.xpc/Contents/MacOS/pidinfo

Likewise if you type `git <tab>` you will get a list of all the next commands that follow and what they do:

    murex-dev» git
    (/usr/bin/git) git - the stupid content tracker
     init           Create an empty Git repository or reinitialize an existing one
     restore        Restore working tree files
     revert         Revert some existing commits
     submodule      Initialize, update or inspect submodules
     push           Update remote refs along with associated objects

The output is colourised and highlighted so it makes more sense in a terminal than it might appear in here. But you get the idea. And all of the suggestions are scrollable with the cursor keys, you can quickly jump by typing more characters, or search for specific completions using regex if you press ctrl+f (this last feature also makes it very quick to traverse large directory structures in `cd`)