Coincidentally just this week I've working to resolve point 1 in my own shell (https://github.com/lmorg/murex). The compromise I came up with was:

- The shell would attempt to return all suggestions immediately

- However a subset of functions which are known to be slower queries (like recursive directory look ups on larger file system hierarchies) are given a "soft timeout" -- where after that timeout is reached, the slower faster subset of functions are returned as the suggestions while the slower subset continues to run in the background

- The slower subset are also given a "hard timeout" where when that point is reached, if the function still hasn't completed then it is just killed. Any results is has produced (if any) by that point are appended to the auto-completion suggestions.

- If the slower subset finished before the hard timeout then it is appended to the suggestions. If it finishes before the soft timeout then it's just part of the suggestions.

At the moment it's only been implemented for file and directory suggestions. The fast function is just any files and directories in the current directory level; where as the slow function will return a larger directory hierarchy (for quick navigating akin to fzf). But the plan is to extend it further to support other dynamic completers as well.

This wouldn't completely solve your point though. If the "fast" query actually runs slow (eg you're trying to complete when inside a network mounted filesystem when the network is dropping) then the shell would still hang. At some point I'll add timeouts on them as well. But I am inching towards that goal.

Be warned though, because this feature is less than a week old, it's still only in a feature branch. :)

Your point on 3 is apt too. One of the things I built early on was man page parsing for auto-completion suggestions. I've since learned that I'm not alone in that regard either (Fish does it as well -- and from some of the demo's I've watched it looks like they've done a nicer job there too).

More recently I've also been writing tools that parse binaries for flags as well (in instances where you download a statically compiled binary - eg terraform - and thus don't have any corresponding man pages). That work is very much in it's infancy though.

Some of this could be down to the completions that are provided. A package such as bash-completions comes with completions for a lot of common software. One specific solution to your problem, well a suggestion is to use oksh (https://github.com/ibara/oksh) a portable version of pdksh (public domain Korn shell) that comes from OpenBSD. The reason why I recommend this shell is that it has programmable completion, although it is much simpler than what's provided by bash and that aside from the built in file name completion it won't come with anything else and you won't find (aside from people's dotfiles on Github) any packages that provide you with anything. Basically you have to customise it to your needs, but because the completion is so simple, whenever you find yourself in a situation where you'd want completion, spend a few minutes adding it to your .kshrc and move on.

I've run into all of these, but, FWIW, I still prefer smart autocompletion in bash by a large margin. Somehow I learned to avoid the bad areas I guess.

Yeah homebrew does that remote lookup thing when I try to complete `brew install xx<TAB>`. Because of the delay, it's not a good way to discover packages at all especially if the package name has an unexpected prefix that causes bash completion to fail. Much better to just `brew search xx` then browse the entire list of possible candidates than to rely on tab completion.

> Yeah homebrew does that remote lookup thing when I try to complete `brew install xx<TAB>`.

AFAIK Homebrew doesn't do remote lookup, you can try it out by turning off your Wi-Fi & autocompleting formula names still work.

> Because of the delay, it's not a good way to discover packages at all

The delay is due to ruby's slow speed, it looks like home-brew just searches the whole formula directory with ruby.

I use Fish for that kind of thing. I dont write shell scripts for Fish thats what I use Bash for (portability) but Fish has intelligent auto complete hints.

> 1. Completion that blocks the shell, by doing a lookup across a network (e.g. to complete a remote path). Can hang for several seconds.

I've had this happen to me. Would be nice if it could be interrupted with Ctrl-C. My workaround has been to wrap the argument that's triggering that in quotes (when redoing the command in another terminal).

> 2. Completion that gives me a misleading/incorrect view of the filesystem, by "intelligently" filtering which files/filetypes it will let me complete. For example, if I have foo.mp3 and foo.txt, and a media-player command tab-completes and only "sees" the mp3, but I actually wanted to know that the .txt was there as well (and in some cases, open it with the media player!)

Maybe a keybinding can be added to enable/disable "smart" completion (leaving only simple filepath completion). Seems like it should be a relatively quick configuration fix.

My workaround for this, for when I want simple filepath completion, has been to prefix the command with `echo`. With vi keybindings it's just `<Esc>Iecho <Esc>A` (it's faster if you make your CapsLock an Esc); with emacs keybindings it's `<Ctrl-A>echo <Ctrl-E>`. Afterwards, to delete the `echo`, it's `<Esc>^dwA` with vi keybindings and `<Ctrl-A><Alt-D><Ctrl-D><Ctrl-E>` with emacs keybindings.

> 3. When the completion has a wrong view of the options provided by a program (e.g. completion is not aware of some useful options). Instead of looking at the man-page, I've been tricked by a bad completion-set.

Maybe the list of options could be parsed out of manpages and --help output. Then, it would coincide.

> Maybe a keybinding can be added to enable/disable "smart" completion (leaving only simple filepath completion). Seems like it should be a relatively quick configuration fix.

There is a keybinding to do simple filename completion: Alt-/ (https://www.gnu.org/software/bash/manual/bash.html#index-com...).

At least in zsh, you can interrupt slow autocompletes with ^C.

Zsh also lets you configure, via the `remote-access` style whether you want to allow it to make remote connections for completion to begin with.

My experience actually is with zsh, it is about remote-access, and I cannot interrupt it with Ctrl-C.

The particular case is normal filepath completion on an NFS mount where the NFS server is a very old Unix OS using a very old version of the NFS protocol. The thing is that while the server hangs under particular circumstances, and zsh is trying to read the directory to autocomplete paths, the kernel cannot return from the normal FS system calls that are invoked, and the process gets stuck in uninterruptible IO. Not even SIGKILL works then.

There's a good chance that setting the path-completion style to false will help in this case. That does disable a useful feature - though it is only a useful feature if you know it is there and use it. If not even SIGKILL works, it is stuck in kernel code. That doesn't surprise me much with NFS. That's not easy to workaround in the zsh code - other than by disabling functionality as with my path-completion suggestion.

Regarding (2), I hate the completion for fdisk [1]. It filters device filenames starting with /dev/disk/{by-id,by-path} even if those names make it easy to select a particular disk.

[1]: https://github.com/karelzak/util-linux/blob/master/bash-comp...

Regarding 3: I wish that all completions were provided by the programs (ideally by invoking the program) rather than by a hard-coded list in a bash-completion file.

In haskell the parser library for your cli auto-generated a completion file which is very convenient.

Fish shell?