Use bpython-like completion

[iven]

The completion in fish-shell always get me confused.

1. I have to think if I should use Tab or right arrow for completion.

When I input cd Do and fish gives me cd Documents, I press Tab, but get two completions: Documents, Downloads, then I realised I should use right arrow. It's confusing, and it's bad to make the user think.

1. It's sometimes too smart.

Say I have .config and .config.old in my PWD, and I don't know which file to edit before I see the filenames start with .config.

I type .con, Tab, and get .config, Tab again, I expect a list of filenames, but it becomes .config.old, then I know which I really want to edit is .config...

I don't have these problems in the original Fish, and I wonder if the new fish is designed to fit intuition.

What I think is a good design is BPython's completion: http://bpython-interpreter.org/screenshots/

I don't know if it's possible to implement like that in shell, but if it could be done, it will be really great.

[ridiculousfish]

The behavior you describe with the .con -> .config -> .config.old just seems like a bug. That wasn't an intentional change.

[ridiculousfish]

The .con -> .config -> .config.old issue should be fixed with this commit:

To git@github.com:fish-shell/fish-shell.git
3606664..670e33a master -> master

[ridiculousfish]

bpython is pretty slick. The "tabbing through completions" feature (inspired by zsh) is definitely something I would like to implement. The fancy curses stuff is probably too much.

The tab/right arrow difference is confusing, but I don't know how to improve it yet. bpython's completions are much more restricted - for example, there's no chance they'll invoke git, or stat a file on a slow NFS filesystem - so they can show them all up-front. That's not an option for fish.

[iven]

I don't know much about the zsh completion. What I'd like to see is just instant completion like Google's keyword suggestion, or vim's autocompletion. For the NFS situations, I think there're still ways to solve them, for example, temporarily disable the instant completion in slow connections(the Google Instant way). The problem is if it fits fish's philosophy.

This also solves the tab/right arrow difference, because we know what we'll get by pressing each button.

BTW, the the tab/right arrow difference get a little better after I know I could use Ctrl-F. :)

[faho]

What is the remaining difference here? We've got the tab-through feature now, and everything else seems fairly similar to me.

I type .con, Tab, and get .config, Tab again, I expect a list of filenames, but it becomes .config.old, then I know which I really want to edit is .config...

In particular, this would complete .con->.config->list->tabbing through the list, which I think solves this concern.

When I input cd Do and fish gives me cd Documents, I press Tab, but get two completions: Documents, Downloads, then I realised I should use right arrow. It's confusing, and it's bad to make the user think.

Right arrow is (now, don't know how it was in 2012) for choosing the suggestion, i.e. the thing drawn on the command line, while tab is for completing unambiguous parts or, eventually, tabbing through.

[pickfire]

The completions can also be improved by something like zsh style to show uses what to put in:

[faho]

There's two issues in that example:

• complete -f doesn't seem to work #112 - inhibiting file completion doesn't always work
• The tar completion doesn't actually do the dash-less commands. Try tar -<TAB>

[pickfire]

The tar completion doesn't actually do the dash-less commands. Try tar -The tar completion doesn't actually do the dash-less commands. Try tar -

What do you mean? I still can use tar xvzf file.tar.gz to extract the files.

[faho]

Of course you can use tar like it's used. What I meant was that the fish completion doesn't offer "x", only "-x", "--extract" and so on.

So if you enter tar - and then press TAB, you'll see completions with descriptions. It's not actually that there's much difference between zsh and fish in how completions generally work, it's that this specific completion script sucks (and that there's a bug related to inhibiting file completion).

[pickfire]

@faho, still great thanks to you for making a lot of completions to work.

[faho]

The main thing left in the original request seems to be my argument hints proposal #2201.

Everything else is also either solved or tracked elsewhere. Let's close.

[floam]

Right arrow is (now, don't know how it was in 2012) for choosing the suggestion, i.e. the thing drawn on the command line, while tab is for completing unambiguous parts or, eventually, tabbing through.

Right, but it's not quite perfect, I think, even after all this time it's a bit problematic. The main hint you get is the autosuggestion and tab is the the button people are accustomed to complete/expand these kinds of things. I think people are always going to find that a little surprising.

The tab/right arrow difference is confusing, but I don't know how to improve it yet.

Could a bind be made such that pressing tab completes, and continuing to hold down the tab key for 450 ms accepts the autosuggestion instead if you didn't like what it did? "press and hold" or a "long press" as maybe some would call it?

[krader1961]

"press and hold" or a "long press" as maybe some would call it?

No, at least not in the manner you seem to be suggesting because that isn't how terminals work. When you press a key (that isn't a modifier like [ctrl]) it sends one or more characters. If you hold the key down long enough the terminals autorepeat mechanism will send additional copies of those characters at the rate configured by the terminal. Since a) there is no guarantee that autorepeat is enabled, and b) even if it is the interval before it is activated and the repeat rate are not under the control of fish nor is there any way for fish to learn what they are (except via an explicit controlled experiment). Pretty sure we don't want two or more consecutive presses of the [tab] key to be treated as equivalent to [right-arrow] or [ctrl-E].

[floam]

even if it is the interval before it is activated and the repeat rate are not under the control of fish nor is there any way for fish to learn what they are

You wouldn't need know what they are ahead of time - whatever the key repeat delay is, the user is accustomed to it. This does not look like the kind of thing difficult to detect with software. Obviously you'd not be able to use this mechanism if your key repeat were super slow.

(420.207 ms)  hex:    9  char: \cI  (or \t)
( 99.792 ms)  hex:    9  char: \cI  (or \t)
(106.720 ms)  hex:    9  char: \cI  (or \t)
(104.218 ms)  hex:    9  char: \cI  (or \t)
(101.306 ms)  hex:    9  char: \cI  (or \t)
(101.299 ms)  hex:    9  char: \cI  (or \t)
(102.741 ms)  hex:    9  char: \cI  (or \t)
(104.155 ms)  hex:    9  char: \cI  (or \t)
(104.407 ms)  hex:    9  char: \cI  (or \t)

You could have it so that hitting tab again a bit later would simple cycle through the pager like it already does, there wouldn't be much of a penalty for getting it wrong.

[floam]

Alternatively, getting an indication of what the first command completion will be at the same time as the autosuggestion with some fancy mechanism like perhaps what is in the screenshots on top would also help this.

[faho]

You wouldn't need know what they are ahead of time - whatever the key repeat delay is, the user is accustomed to it. This does not look like the kind of thing difficult to detect with software.

Yeah, but try distinguishing it from double-pressing tab. I've just tested it a bit and it seems if I double-tap the second tap comes after somewhere between 130 and 160ms, while my term repeats every 39-41ms. So given that we already have seen repeat delays of 40ms and 100ms, a terminal with one of 150ms doesn't seem impossible.

Even if this would then go on to the pager, it would still feel quite weird if it behaved differently under different terms or when you double-tap slightly quicker or slower. (Edit: Also it would mean delaying completions by waiting for the tab to repeat)

I don't think it's gonna work.

What might work is to have the first tab select the suggestion, but that would be awkward if you wanted to complete the last token. Also it would mean one more tab press to get to the pager. It's already three, then it would be four.

I'm actually happy with the current system.

[floam]

Yeah, but try distinguishing it from double-pressing tab. I've just tested it a bit and it seems if I double-tap the second tap comes after somewhere between 130 and 160ms, while my term repeats every 39-41ms. So given that we already have seen repeat delays of 40ms and 100ms, a terminal with one of 150ms doesn't seem impossible.

OK, I think you're right.