Description of the new feature/enhancement

Today regardless of any mode settings ctrl-v is always processed by terminal rather than passing it to the app. This is not convenient because:

• maybe ctrl-v means something else to the app
• asymmetry, ctrl-c is passed to the app if ENABLE_PROCESSED_INPUT is off but ctrl-v is not. If I have my own 'clipboard' then the ctrl-v will paste the wrong text
• with multi line pastes I get a popup dialog warning me (imagine if vs code did this on every paste)
• The paste comes in as separate keys strokes, not as one operation, so if I support undo then on a 50 char paste I have to press undo 50 times
• the ctrl-v paste is slow since the app sees it as multiple keystrokes rather than one large insert
• A large paste might even overflow my undo history stack so its not undoable at all

Others have reported this issue and all the suggestions and proposed solutions are not really useful

• change the keyboard settings. Problem is that I want ctrl-v to work elsewhere, on the command line say
• terminal detects the name of the executable (vim.exe), this is plainly not workable
• only needed for WSL - not enough

Proposed technical implementation details (optional)

either

• ENABLE_PROCESSED_INPUT=0 should disable ctrl-v as well as ctrl-c. This is a theoretically breaking change
• a new DONT_PASTE flag in console mode settings

Today regardless of any mode settings ctrl-v is always processed by terminal Others have reported this issue and all the suggestions and proposed solutions are not really useful

• change the keyboard settings. Problem is that I want ctrl-v to work elsewhere, on the command line say

Would you be able to elaborate on this? Deleting the Ctrl+V key binding from Windows Terminal's settings is quick and easy, and doesn't require you to change any keyboard configuration.

Thanks!

I only want it for the app I am writing (just like vim, nano,... that have also complained about the same thing) not globally. ie the app needs to turn it on and off, just like I can turn ctrl-c on and off programmatically. It should not have to be :

• a global change
• done by the end user

See also #11267

You know what? You're absolutely right. This is a /dupe of #11267. We'll consolidate tracking there, thanks!

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

This issue precisely articulates the problem I am seeing. Did this get fixed? How can an application turn off Ctrl-C and Ctrl-V being grabbed by the terminal while it is running without asking the user to change the settings in the Terminal?