ITerm2-like terminal autocomplete

[isotes]

Description of the new feature/enhancement

Provide autocomplete by the terminal (not the shell) based on previous output (comparable to the iTerm2 'Autocomplete' feature described here).

This feature does not require any knowledge about the current command but works just by inspecting the existing output as shown by the terminal. It uses the word currently being typed (based on the output and the cursor position) to provide autocompletion proposals. Therefore, it is independent of the shell and works also for other console applications that allow input, e.g., editors.

A request for this feature has been mentioned here but I don't think it has been recognised as a different feature from the issue it was mentioned in.

Proposed technical implementation details

A possible approach could be based on a set of characters that separate words. First, identify the currently typed word by going backward from the cursor to the first non-word character. Second, perform a backwards search for words with the same prefix (and stop after a certain number of proposals or amount of text searched to ensure quick and helpful feedback).

Note that in the iTerm2 implementation 'word' encompasses a whole path, i.e., both / and \ are treated as a word character, which I found very helpful.

[edited to highlight treatment of paths]

[zadjii-msft]

Alright yea I'll acknowledge that this is a independent request from #3121. The concept that this is implemented independently from the shell excites me - that'll make this infinitely easier to support.

This might fit in well as a possible extension, so I'll tag it into that thread.

[WSLUser]

We'll need to be sure it doesn't cause issues with bash completion, PSReadline, oh-my-zsh/fish, etc. I'm used to just normal bash completion and PSReadline so not sure how Iterm2 does it exactly if it sees that a shell auto-complete extension is being used.

[zadjii-msft]

I mean, it seems like the Terminal's auto-complete that's provided by scanning the buffer like this would be totally different than the shell's autocomplete. If the Terminal's auto complete is bound to the same keystroke as the shell's autocomplete, the the Terminal binding would take precedence (as it does with every other keybinding currently). I certainly wouldn't want this as an "always on" functionality, because yea, that would confuse things.

As far as implementation details goes, it doesn't seem to hard to just send the suggestion as a string of input to the shell, just the same as if the user had typed it. I don't think the shell would need to know at all that the Terminal would support such a feature.

[WSLUser]

So we'll just need to throw this behind a setting which could be toggled on/off with a keybinding.

[isotes]

Everything that @zadjii-msft said.

iTerm2 uses CMD-; as the (default) keybinding. This functionality is mostly orthogonal to shell completion - both with respect to the keybinding and the kind of completions it can provide.

[DHowett]

This is pretty cool. Thanks for requesting!

[oising]

Windows kinda does this to an extent with the old conhost's F9 history -- this list comes from conhost, not the shell. So it's not without some kind of precedent already, right? One question though: How will the terminal differentiate command input from password/sensitive input? Do you really want that stuff in history? (again, F9 did it, but that doesn't mean it's right...)

Edit: never mind, I should think more before typing. I guess iterm2 only captures output/echo, not input. As long as you use interactive input for passwords, and its masked, it's safe.

[pcgeek86]

Still hoping to see this added to Windows terminal. It's annoying to have to copy-paste stuff with the mouse, which could easily be completed by the Terminal.