starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

ITerm2-like terminal autocomplete #9200

New Issue
Open
opened 2026-01-31 01:48:35 +00:00 by claunia · 8 comments
claunia commented 2026-01-31 01:48:35 +00:00
Owner
Copy Link

Originally created by @isotes on GitHub (Jun 22, 2020).

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).

inShell

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.

inNano

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]

Originally created by @isotes on GitHub (Jun 22, 2020). # 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](https://www.iterm2.com/features.html#autocomplete)). ![inShell](https://user-images.githubusercontent.com/934246/85293467-a89dcb00-b49d-11ea-923f-fbc80b9461ae.png) 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. ![inNano](https://user-images.githubusercontent.com/934246/85293548-ce2ad480-b49d-11ea-9597-602144e17e4f.png) A request for this feature has been mentioned [here]( https://github.com/microsoft/terminal/issues/3121#issuecomment-581756164) 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]
claunia commented 2026-01-31 01:48:36 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jun 22, 2020):

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.

@zadjii-msft commented on GitHub (Jun 22, 2020): 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.
claunia commented 2026-01-31 01:48:36 +00:00
Author
Owner
Copy Link

@WSLUser commented on GitHub (Jun 22, 2020):

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.

@WSLUser commented on GitHub (Jun 22, 2020): 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.
claunia commented 2026-01-31 01:48:36 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jun 22, 2020):

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.

@zadjii-msft commented on GitHub (Jun 22, 2020): 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.
claunia commented 2026-01-31 01:48:36 +00:00
Author
Owner
Copy Link

@WSLUser commented on GitHub (Jun 22, 2020):

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

@WSLUser commented on GitHub (Jun 22, 2020): So we'll just need to throw this behind a setting which could be toggled on/off with a keybinding.
claunia commented 2026-01-31 01:48:37 +00:00
Author
Owner
Copy Link

@isotes commented on GitHub (Jun 22, 2020):

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.

@isotes commented on GitHub (Jun 22, 2020): 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.
claunia commented 2026-01-31 01:48:37 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jun 26, 2020):

This is pretty cool. Thanks for requesting!

@DHowett commented on GitHub (Jun 26, 2020): This is pretty cool. Thanks for requesting!
claunia commented 2026-01-31 01:48:37 +00:00
Author
Owner
Copy Link

@oising commented on GitHub (Jun 26, 2020):

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.

@oising commented on GitHub (Jun 26, 2020): 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.
claunia commented 2026-01-31 01:48:37 +00:00
Author
Owner
Copy Link

@pcgeek86 commented on GitHub (Apr 28, 2022):

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.

@pcgeek86 commented on GitHub (Apr 28, 2022): 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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Extensibility Area-TerminalControl Issue-Feature Product-Terminal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#9200
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?