Editor's Note (@DHowett-MSFT): This may be a good place to track profile-specific keybindings?
With the classic Windows terminal, Ctrl+c and Ctrl+v can be used for copy and paste when working within a Windows shell just as I would expect/prefer. However, when using WSL, this is typically not the case and those keys are available for use by Linux applications such as Vim.
How can I replicate this same behavior with the new Windows Terminal?
Background:
When working specifically within the WSL environment, Vim is my primary editor and the presence of any Ctrl+v mapping effectively blocks the use of blockwise Visual mode (http://vimdoc.sourceforge.net/htmldoc/visual.html#CTRL-V).
Removal of these mappings in a global scope is undesirable since I do not want to lose the use of Ctrl+c and Ctrl+v for copy and paste when working within a Windows shell.
I realize that similar issues have been discussed at length and that any choice here is somewhat of a compromise, but the ability to replicate the current behavior of the classic Windows terminal in this regard is a tradeoff that I find acceptable/desirable.
Editor's Note (@DHowett-MSFT): This may be a good place to track profile-specific keybindings?
With the classic Windows terminal, Ctrl+c and Ctrl+v can be used for copy and paste when working within a Windows shell just as I would expect/prefer. However, when using WSL, this is typically not the case and those keys are available for use by Linux applications such as Vim.
How can I replicate this same behavior with the new Windows Terminal?
Background:
When working specifically within the WSL environment, Vim is my primary editor and the presence of any Ctrl+v mapping effectively blocks the use of blockwise Visual mode (http://vimdoc.sourceforge.net/htmldoc/visual.html#CTRL-V).
Removal of these mappings in a global scope is undesirable since I do not want to lose the use of Ctrl+c and Ctrl+v for copy and paste when working within a Windows shell.
I realize that similar issues have been discussed at length and that any choice here is somewhat of a compromise, but the ability to replicate the current behavior of the classic Windows terminal in this regard is a tradeoff that I find acceptable/desirable.