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

Vim.exe can disable ctrl+v to paste in conhost, but not in Windows Terminal #15256

New Issue
Open
opened 2026-01-31 04:33:03 +00:00 by claunia · 5 comments
claunia commented 2026-01-31 04:33:03 +00:00
Owner
Copy Link

Originally created by @kasajian on GitHub (Sep 17, 2021).

I map the Ctrl+V to Paste in Windows Terminal:
{
"command": "paste",
"keys": "ctrl+v"
},
to simulate what I can do in cmd.exe.

However, when I use the command-line version of vim, from cmd.exe, in Normal mode, if I hit "Ctrl+V", it correctly puts it into "Visual mode".
When I'm in cmd.exe outside of vim, just typing at the console, Ctrl+V will paste to the console as it's supposed to.

In Windows Terminal, with the above setting, Ctrl+V works from the console window, but in vim doesn't see the key-combination.

It would be good for Windows Terminal key bindings to only be in effect when it's typed at the console.

Originally created by @kasajian on GitHub (Sep 17, 2021). I map the Ctrl+V to Paste in Windows Terminal: { "command": "paste", "keys": "ctrl+v" }, to simulate what I can do in cmd.exe. However, when I use the command-line version of vim, from cmd.exe, in Normal mode, if I hit "Ctrl+V", it correctly puts it into "Visual mode". When I'm in cmd.exe outside of vim, just typing at the console, Ctrl+V will paste to the console as it's supposed to. In Windows Terminal, with the above setting, Ctrl+V works from the console window, but in vim doesn't see the key-combination. It would be good for Windows Terminal key bindings to only be in effect when it's typed at the console.
claunia added the Issue-FeatureArea-InputProduct-TerminalProduct-Conpty labels 2026-01-31 04:33:03 +00:00
claunia commented 2026-01-31 04:33:05 +00:00
Author
Owner
Copy Link

@elsaco commented on GitHub (Sep 17, 2021):

@kasajian please use "crtl+alt+v" to enter visual mode when using vim and wt.

@elsaco commented on GitHub (Sep 17, 2021): @kasajian please use "crtl+alt+v" to enter visual mode when using vim and wt.
claunia commented 2026-01-31 04:33:05 +00:00
Author
Owner
Copy Link

@WSLUser commented on GitHub (Sep 17, 2021):

WT has a keybindings for both ctrl+shift+v and ctrl+v to paste. The latter is in the user settings so it can be removed easily by anybody having issues with something like using vim. I typically use ctrl+shift+v for muscle memory now to prevent issues with linux apps and works just fine with vim, just be sure you enter edit mode first as it can act alittle weird otherwise.

Agree with elsaco for entering vim visual mode.

@WSLUser commented on GitHub (Sep 17, 2021): WT has a keybindings for both `ctrl+shift+v` and `ctrl+v` to paste. The latter is in the user settings so it can be removed easily by anybody having issues with something like using vim. I typically use `ctrl+shift+v` for muscle memory now to prevent issues with linux apps and works just fine with vim, just be sure you enter edit mode first as it can act alittle weird otherwise. Agree with elsaco for entering vim visual mode.
claunia commented 2026-01-31 04:33:06 +00:00
Author
Owner
Copy Link

@kasajian commented on GitHub (Sep 18, 2021):

I appreciate the workarounds. But I think this is something that should be address in Windows Terminal. It can work since it does work in cmd.exe. One possible feature that can be a workaround is to allow mappings to be app specific, or console specific. In this case, the "ctr+v" i could to the console window only. Or alternatively, I could say that for ctrl+v, "exclude it for vim". That way, the user is free to create exclusions as the please.

@kasajian commented on GitHub (Sep 18, 2021): I appreciate the workarounds. But I think this is something that should be address in Windows Terminal. It can work since it does work in cmd.exe. One possible feature that can be a workaround is to allow mappings to be app specific, or console specific. In this case, the "ctr+v" i could to the console window only. Or alternatively, I could say that for ctrl+v, "exclude it for vim". That way, the user is free to create exclusions as the please.
claunia commented 2026-01-31 04:33:06 +00:00
Author
Owner
Copy Link

@kasajian commented on GitHub (Nov 7, 2021):

Does anyone have any thoughts on if this can ever be fixed? It's possible someone may be willing to work on it (maybe me), if there's agreement that this is worth fixing.

The issue to me is that I don't really feel like I, or others, should have to compromise when something very basic works under cmd.exe, but will not work in Windows Terminal. Maybe the solution is within vim. I don't know. But the current response is only talking about what can be done now -- there's no acknowledgment that this is in fact a problem.

Under cmd.exe, Ctrl+V works in the console window to paste text from the clipboard. I don't want to give that up.
But if I were to enable that in Windows Terminal, it takes that over for all apps, including vim. So then in vim, if I type Ctrl+V, Windows Terminal won't actually send that command to vim to do what vim is supposed to do. So effectively, if you map a key in Windows Terminal, no other console app running in Windows Terminal can ever use it.

If cmd.exe can do it -- so should Windows Terminal. One simpler feature is to allow the user map key bindings in Windows Terminal that are "app specific". So I can map Ctrl+V to copy globally, but locally for VIM, I can say "don't use the setting, but use 'default'" which causes Windows Terminal to ignore the default mapping in VIM's case.

@kasajian commented on GitHub (Nov 7, 2021): Does anyone have any thoughts on if this can ever be fixed? It's possible someone may be willing to work on it (maybe me), if there's agreement that this is worth fixing. The issue to me is that I don't really feel like I, or others, should have to compromise when something very basic works under cmd.exe, but will not work in Windows Terminal. Maybe the solution is within vim. I don't know. But the current response is only talking about what can be done now -- there's no acknowledgment that this is in fact a problem. Under cmd.exe, Ctrl+V works in the console window to paste text from the clipboard. I don't want to give that up. But if I were to enable that in Windows Terminal, it takes that over *for all apps*, including vim. So then in vim, if I type Ctrl+V, Windows Terminal won't actually send that command to vim to do what vim is supposed to do. So effectively, if you map a key in Windows Terminal, no other console app running in Windows Terminal can ever use it. If cmd.exe can do it -- so should Windows Terminal. One simpler feature is to allow the user map key bindings in Windows Terminal that are "app specific". So I can map Ctrl+V to copy globally, but locally for VIM, I can say "don't use the setting, but use 'default'" which causes Windows Terminal to ignore the default mapping in VIM's case.
claunia commented 2026-01-31 04:33:07 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 16, 2022):

I suppose in the fullness of time, this is maybe something that could get implemented. If we were being incredibly bold:

  • We could have ConPTY tell the Terminal when QuickEdit was enabled/disabled by a client application
  • We could have context-sensitive keybindings, that only apply in certain scenarios. I'm thinking different that profile-specific keybindings, more like "this is only active in the alt buffer"
  • One of those pieces of context could be "This is only active when in QuickEdit mode".

It would be a lot of work. It's probably not impossible, but I'd reckon it's pretty far down the backlog.

The workarounds today would be limited to:

  • Don't use Ctrl+v as a keybinding, only Ctrl+shift+v. Your muscle memory will have to change a little, but the actions would be consistent.
  • Disable Ctrl+v as a keybinding, and use PowerShell as the shell. PowerShell itself actually listens for ^V itself, and manually pastes when it sees that. The muscle memory would obviously need to change a lot more, for using an entirely new shell.
@zadjii-msft commented on GitHub (May 16, 2022): I suppose in the fullness of time, this is maybe something that could get implemented. If we were being incredibly bold: * We could have ConPTY tell the Terminal when QuickEdit was enabled/disabled by a client application * We could have context-sensitive keybindings, that only apply in certain scenarios. I'm thinking different that profile-specific keybindings, more like "this is only active in the alt buffer" * One of those pieces of context could be "This is only active when in QuickEdit mode". It would be a lot of work. It's probably not impossible, but I'd reckon it's pretty far down the backlog. The workarounds today would be limited to: * Don't use <kbd>Ctrl+v</kbd> as a keybinding, only <kbd>Ctrl+shift+v</kbd>. Your muscle memory will have to change a little, but the actions would be consistent. * Disable <kbd>Ctrl+v</kbd> as a keybinding, and use PowerShell as the shell. PowerShell itself actually listens for `^V` itself, and manually pastes when it sees that. The muscle memory would obviously need to change a lot more, for using an entirely new shell.
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-Input Issue-Feature Product-Conpty 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#15256
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?