Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Command Prompt] : User is not able to Select commands using 'Shift+ right/Left arrow keys' inside Command Prompt. #11985

Open
Tracked by #4993
Saiteja341 opened this issue Dec 17, 2021 · 11 comments
Labels
A11yCO Accessibility tracking A11yUsable Accessibility tracking Area-Accessibility Issues related to accessibility HCL-E+D Accessibility tracking HCL-WindowsTerminal Accessibility tracking Issue-Bug It either shouldn't be doing this or needs an investigation. Product-Terminal The new Windows Terminal.
Milestone

Comments

@Saiteja341
Copy link

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 :

User is not able to Select commands using 'Shift+ right or Left arrow keys' inside Command Prompt..zip

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.

@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Dec 17, 2021
@elsaco

This comment has been minimized.

@KalleOlaviNiemitalo

This comment has been minimized.

@elsaco

This comment has been minimized.

@ghost ghost added A11yCO Accessibility tracking A11yUsable Accessibility tracking Area-Accessibility Issues related to accessibility HCL-E+D Accessibility tracking HCL-WindowsTerminal Accessibility tracking Issue-Bug It either shouldn't be doing this or needs an investigation. labels Dec 20, 2021
@zadjii-msft zadjii-msft added the Product-Terminal The new Windows Terminal. label Jan 3, 2022
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Jan 3, 2022
@zadjii-msft zadjii-msft added this to the Terminal v2.0 milestone Jan 3, 2022
@zadjii-msft
Copy link
Member

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.

@zadjii-msft zadjii-msft removed the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label Jan 3, 2022
@zadjii-msft zadjii-msft modified the milestones: Terminal v2.0, Backlog Jan 3, 2022
@carlos-zamora carlos-zamora mentioned this issue May 16, 2022
10 tasks
@ghost ghost added In-PR This issue has a related PR and removed In-PR This issue has a related PR labels May 16, 2022
ghost pushed a commit that referenced this issue May 20, 2022
## Summary of the Pull Request
Introduces a non-configurable version of mark mode to Windows Terminal. It has the following interactions defined:
- <kbd>ctrl+shift+m</kbd> --> Enter Mark Mode
- when in Mark Mode...
	- <kbd>ESC</kbd> --> Exit Mark Mode
	- arrow keys --> move "start"
	- <kbd>shift</kbd> + arrow keys --> anchor "start", move "end"
	- <kbd>ctrl+a</kbd> --> select all
- when a selection is active...

When in mark mode, the cursor does not blink.

## References
#4993 - [Epic] Keyboard Selection

## PR Checklist
* [X] Closes #715
* [X] Provides a resolution for #11985

## Detailed Description of the Pull Request / Additional comments
- `TermControl`:
	- `TermControl.cpp` just adds logic to prevent the cursor from blinking when in mark mode
- `ControlCore`
	- in the same place we handle quick edit, we add an entry point to mark mode
- `TerminalCore`
	- this leverages `UpdateSelection()` and other quick edit functions to make mark mode happen

## Validation Steps Performed
- [x] Make selection, split pane, close pane
	- NOTE: A similar scenario caused a crash at one point. Really weird. Keep an eye on it.
- [x] Cursor is off when in mark mode
- [x] general movement/selection
- [x] general movement/selection that forces the viewport to move
- [x] In mark mode, selectAll...
	- [x] arrow keys --> move start
	- [x] shift + arrow keys --> move end
- [x] (regardless of mark mode) if selection active, enter --> copy to clipboard
@zadjii-msft
Copy link
Member

zadjii-msft commented Aug 2, 2022

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 #13369 (comment):

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

@ofek
Copy link
Contributor

ofek commented Aug 2, 2022

Just fyi specifically for shift+left, you'd have to go one character back before highlighting

@lesleyrs
Copy link

lesleyrs commented Feb 3, 2023

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?

@KalleOlaviNiemitalo
Copy link

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

@zadjii-msft
Copy link
Member

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.

@youk
Copy link

youk commented Feb 3, 2023

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

@zadjii-msft
Copy link
Member

It seems there is no way to define actions per profile

That's correct, that's tracked in #5790

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A11yCO Accessibility tracking A11yUsable Accessibility tracking Area-Accessibility Issues related to accessibility HCL-E+D Accessibility tracking HCL-WindowsTerminal Accessibility tracking Issue-Bug It either shouldn't be doing this or needs an investigation. Product-Terminal The new Windows Terminal.
Projects
None yet
Development

No branches or pull requests

7 participants