microsoft
[Command Prompt] : User is not able to Select commands using 'Shift+ right/Left arrow keys' inside Command Prompt.
Windows Terminal version
1.12.3472.0
Windows build number
22509.1011
Other Software
**Test Environment: ** OS: Windows 11 Version Dev (OS Build 22509.1011) App: Windows Terminal Preview Screen Reader: Narrator
Steps to reproduce
Repro Steps:
1.Open Windows Terminal. 2.Open 'Command prompt' using 'Ctrl + Shift + 2' keys. 3.Now type any text in text-area of 'Command prompt'. 4.Now try to select the command text using 'Shift + right/left arrow'. 5.Observe the issue.
Users Experience Users who rely on keyboard will get impacted here & fail to use the 'Command prompt' effectively, if User is not able to Select commands using 'Shift+ right/Left arrow keys' inside Command Prompt.
Attachment :
Expected Behavior
User should be able to Select commands using 'Shift+ right/Left arrow keys' inside Command Prompt, which is happening in 'Windows Power shell' tab.
Actual Behavior
User is not able to Select commands using 'Shift+ right/Left arrow keys' inside Command Prompt.
@Saiteja341 Shift+RightArrow is a function of PSReadLine. IFIK, cmd doesn't use PSReadLine.
@elsaco, in PSReadLine, the Shift+arrow combination can only select text in the command that the user is editing. In conhost, the Shift+arrow combination can select the prompt and earlier lines as well.
Similar functionality for Windows Terminal has been requested in https://github.com/microsoft/terminal/issues/715 so this one could be considered a duplicate of that.
@KalleOlaviNiemitalo you're correct! Also, if the action is started by the mouse pointer, like selecting one char only, then Shift+RightArrow or Shift+LeftArrow works for extending the selection in a cmd tab.
Our plan of record at the moment is to use mark mode (see #5804) to enable this functionality. This won't have exact parity with the vintage console's shift+arrows for selecting text in cmd.exe, but it should be close enough, with the possibility of being more powerful.
~This is fixed in Terminal Preview, >=v1.15. The user needs to enter "Mark Mode" (by pressing ctrl+shift+m), and then they can select text with shift+arrows.~
We're gonna re-purpose this thread to track "implicit mark mode", for instant shift+left selection.
From https://github.com/microsoft/terminal/issues/13369#issuecomment-1176803326:
Ok. Chatted about it at sync today. Here were some notes:
This is pretty similar to [Command Prompt] : User is not able to Select commands using 'Shift+ right/Left arrow keys' inside Command Prompt. #11985 in that a terminal-side selection is created implicitly. There, Shift+Left can immediately enter mark mode and create a selection to the left.
Here, we're talking about Shift+End entering mark mode and creating a selection to the "end". The tricky part is that "end" is first defined as the end of the input buffer, then defined as the end of the line.
We could be smarted about cooked read and the input buffer to be able to allow functionality for that first part ("end" --> end of the input buffer). In fact, we should do that, but that's feature work we're gonna have to throw onto the backlog.
There's also a concern about creating confusion between shell-side selections and terminal-side selections. PowerShell, for example, lets you do a shell-side selection, which provides a rich experience where you can also cut text. ConEmu intelligently knows when to do that while also only doing terminal-side selections. If we don't have that intelligent functionality, it's easy for the user to be confused as to why some selections allow you to "cut" the text while others don't.
Proposed solution:
- the "quick-n-easy" fix here would be that we introduce a global setting or some button in the settings UI like "experimental.implicitMarkModeActions" that would generate a number of actions that allow you to implicitly create a terminal-side selection with keybindings like Shift+Left or Shift+End.
- These actions would probably be a bit ugly, but they would be a sequence of actions like "enter mark mode" --> "expand selection to the left (or end of line)"
- This would create a terminal-side selection that allows you to select and copy text as allowed in mark mode, but not provide a rich experience like cutting text (which I personally think is fine, I'd bet 99% of the time you just want to copy).
For more discussion, refer to → #13369
Just fyi specifically for shift+left, you'd have to go one character back before highlighting
Why does nobody mention WSL? I'd like to be able to do this there too. Is there a reason for why it won't allow highlighting with keys?
@lesleyrs, I expect that the feature that starts "implicit mark mode" when the user presses Shift+Left will be implemented in the terminal only, without changing anything in the console host. If it is implemented that way and enabled by the user, then it will work with WSL as well.
Mark mode via Ctrl+Shift+M already works with WSL.
Also, adding the following to your settings will work:
{
"command":
{
"action": "markMode"
},
"keys": "shift+left"
},
Sure, it requires an extra keypress, but it'll get the job done.
@zadjii-msft It seems there is no way to define actions per profile? Defined as is it will mess with profiles like PowerShell where selection with keyboard already works.
It seems there is no way to define actions per profile
That's correct, that's tracked in #5790
@zadjii-msft Isn't using standard LUA shortcuts used to work before? I can't even find definition of LUA that doesn't refer to scripting language but I hope you guys working on this project are old enough to know what I mean. Here's a list of shortcuts I'd expect to work in terminal:
{
"\UF729" = "moveToBeginningOfLine:"; /* Home */
"@\UF729" = "moveToBeginningOfDocument:"; /* Ctrl-Home */
"$\UF729" = "moveToBeginningOfLineAndModifySelection:"; /* Shift-Home */
"@$\UF729" = "moveToBeginningOfDocumentAndModifySelection:"; /* Ctrl-Shift-Home */
"\UF72B" = "moveToEndOfLine:"; /* End */
"@\UF72B" = "moveToEndOfDocument:"; /* Ctrl-End */
"$\UF72B" = "moveToEndOfLineAndModifySelection:"; /* Shift-End */
"@$\UF72B" = "moveToEndOfDocumentAndModifySelection:"; /* Ctrl-Shift-End */
"\UF72C" = "pageUp:"; /* PageUp */
"\UF72D" = "pageDown:"; /* PageDown */
"$\UF728" = "cut:"; /* Shift-Delete */
"$\UF727" = "paste:"; /* Shift-Insert */
"@\UF727" = "copy:"; /* Ctrl-Insert */
"@\UF702" = "moveWordBackward:"; /* Ctrl-Left */
"@\UF703" = "moveWordForward:"; /* Ctrl-Right */
"@$\UF702" = "moveWordBackwardAndModifySelection:"; /* Ctrl-Shift-Left */
"@$\UF703" = "moveWordForwardAndModifySelection:"; /* Ctrl-Shift-Right */
}
This is a list I created when I first started using Mac because I couldn't stand not having those keys work like they did after so many years of using them.
For many of us text selection is core UX. No one wants to “switch modes” just to select text they just entered. Imagine if you had to do that in Notepad every time you wanted to make a selection.
Can you please find some way to allow us to use those keys as intended, at least those that make sense in the context of selecting and editing on the command line?
aaand it's been years with no change. removing fundamental text input functionality and requiring your users to enable a hack that is less efficient is unacceptable imo
i use shift+arrow (and ctrl+shift+arrow which is even less natural with this hack) constantly to highlight text and using my mouse for this absolutely destroys my workflow
