Accessibility: Keyboard shortcuts to set start and end selection

[zersiax]

The way selection currently works in VS Code requires you to hold down the shift key while holding down the arrow keys or using "Home", "End" and other such keys to contiguously select blocks of text/code.
While this works for most cases, this can become rather cumbersome for screen reader users when large amounts of code need to be acted on at once, e.g. copied, deleted etc.
The main cause of this is that screen readers pretty much require keyboard shortcuts to be used to get anything done. Quickly checking down a few lines (screen readers only see one line at a time), checking context, various other things are pretty much impossible while you are trying to select a large piece of code.
This is especially painful, for example, when you have a large amount of dummy HTML that needs to be replaced by a dynamic loop. Checking if you managed to get 6 levels worth of nested divs rather than that one outer div you didn't mean to highlight becomes an exercise in frustration.

A way around this problem is to, rather than depend on a held down key for contiguous selection, use a single keypress to mark the beginning and another to mark the end of the wanted selection. Once both points are set, the text in between those points is highlighted and can then be acted on.
This frees the keyboard up to , for example, move around the file, etc. without ever losing your selection
@isidorn requested to be notified of this feature request being created.

[isidorn]

I think this makes sense in general, to add a "Start selection" command and "End selection".
Assigning to me and @alexdima
I might have time in May to look into this, thus assinging to that milestone for now.
@alexdima if you have code pointers or any preferences do let me know

[webczat]

well makes sense to me, although there are features like expand selection etc. I also have problems with selecting nested blocks etc, and expand selection seems to work for this case, although I'd say you have to be a bit careful to verify what it's selecting.

[jareds]

For an example of an implementation of this look at notepad++. Begin/end selection is an option in the context menu when in a file. I find this very useful when needing to copy large blocks of text.

[jvesouza]

This feature is my consumer dream in any and every editor I use.
Selecting a very large block of text using a screen reader is not very comfortable.
If it is possible to implement a command that allows you to jump to the beginning and end of the selected block, it will also be very useful.

[webczat]

well currently I am learning to do it this way: point at the beginning of, say, an if. select the whole line and next one because of the brace (in c# brace is usually below the if) and then use the expand selection feature, your selection should expand to the closing brace of this exact block.

[akash07k]

If it gets implemented then it will be very beneficial for productivity.

[jacob-kruger-work]

The one old standard - used to use it in things like visual interdev and VS.Net 2005, etc., if remember correctly was purely F8 to mark start of selection, and then navigate around code however you like, and then hit shift + F8, and it would mark the whole block from start marker to end marker

[webczat]

yeah. unfortunately f8 is taken. :) Also I prefer shortcuts without function keys as they are quite far in the kbd.

[isidorn]

Thanks for feedback and yes it will behave just like that:
One command to start selection, another command to end selection.

I am not sure if there will be a good feault keyboard shortcut, I will try to find something with F8 in the mix.
Like Ctrl + F8 to start, Cltr + Shift + F8 to stop. This can be customisable so any user can put whatever he likes.

[MarcoZehe]

Hahah, when I was very young, in the late 1980s, there was this program under both MS-DOS and CP/M called WordStar. It had layered keyboard commands, and two of them were CTRL+K, b to mark the start, and CTRL+K, k to mark an end of a block. This was the old equivalent of text selection. Borland's Turbo Pascal 3.0, the first true IDE I used, had a similar command set, which made the learning curve very flat. :-)

I noticed immediately that CTRL+K is used for several layered commands in VS Code as well, so we could maybe leverage that.

[isidorn]

Yeah it might make sense to use the same command actually and the same shortcut so it is just a toggle, would make the whole thing more simple. Since why would you start a selection if you are already in a selection?
So ctrl+k then something is the way to go.

[jacob-kruger-work]

The one small, not too important reason why some people might like to have separate commands would be if they'd initialised selection, and, marked the starting point, but, now wanted to shift it to somewhere else.  Wouldn't really cause issues, but, they'd then need to do something like ctrl +K, move to next point, ctrl +K, and then ctrl +K to re-mark it as start?

Jacob Kruger

[MarcoZehe]

I was thinking the same thing. The separate commands for start and end selection do make sense for the case where one needs to be adjusted multiple times.

[isidorn]

Ok makes sense, two seperate commands it is. Thanks for feedback.

[alexdima]

@isidorn Implementation wise, I also think this could be implemented with two commands. The first one would be "set selection anchor" and would add an editor decoration at the current position. Using a decoration would make sure that the anchor stays with the surrounding text even if there are edits in the file.

The second one, "select from anchor to position" would read up that decoration and create a selection in between.

A third command could be added as well, "jump to anchor", which might be helpful to kind of "save a position" and then go reading around, and then jump back to it. Not sure if that would be useful, just a thought.

[MarcoZehe]

A third command could be added as well, "jump to anchor", which might be helpful to kind of "save a position" and then go reading around, and then jump back to it. Not sure if that would be useful, just a thought.

Oh I could totally see myself use this a lot of times! A big 👍 for that!

[isidorn]

@alexdima good idea to use the decoration as an implementation detail. And the "Go to anchor" command makes a lot of sense.

My idea for command naming:

• "Mark Start of Selection" "Mark End of Selection" "Go to Selection Mark"

Ideas on naming welcome.
I can look into this next week.

[jvesouza]

Oh I could totally see myself use this a lot of times! A big +1 for that!

Me too!
It seems to me that it would be very interesting if we could easily jump to the beginning or end of the selected text.

[isidorn]

@alexdima Ok, I plan to create a
src/vs/editor/contrib/anchorSelect
And will introduce following 3 editor commands as you suggested (with a slight modification):
"Set Selection Anchor", "Select From Anchor to Cursor", "Go to Selection Anchor"

The only alternative name I have is to use "Mark" instead of "Anchor". Though Anchor works fine for me, I like it for its uniqueness.

Feedback on naming very welcome

[isidorn]

We have introduced three commands:

• "Set Selection Anchor" Ctrl+k, Ctrl+b
• "Select From Anchor to Cursor" Ctrl+k, Ctrl+k
• "Cancel Selection Anchor" escape
• "Go to Selection Anchor" no default keybinding

Please try it out in VS Code insiders from Tuesday and let us know how it behaves for you.

[isidorn]

Also please provide feedback if you would like confirmation once the anchor is set. Should we announce "Selection Anchor Set"?

[zersiax]

Probably " Anchor placed" or similar would be good to announce, just something short.
It would also be good to be notified when you encounter the anchor while arrowing through the document, but at that point we get back to announcing errors, lightbulbs and other ornaments on a per-line basis :)

[Neurrone]

Yup, agree with what @zersiax said.

[isidorn]

Thanks for feedback. We now announce "Anchor set".
As for reading it once you encounter it, yes this goes in the same bag of announcing errors, lighbulbs and other. For that we first need this #97154

[jvesouza]

@isidorn It seems that the announcement "anchor set" only happens the first time that the command "Set Selection Anchor" is used. From the second time on, nothing is announced by the orca.

[isidorn]

@jvesouza thanks for feedback. The issue here is that we update the aria-live region, from "anchor set" to again "anchor set". Orca does not see detect difference in the content and does not read anything.
@joanmarie do you have some recommendation what should we do here if we want some message to be re-read multiple times? In theory we could create a new live container, but that feels clunky.

[jvesouza]

@isidorn And if the command also announced the position?
Something like that:
anchor set at line 1 column 10.
or
anchor set at 1:10

[isidorn]

@jvesouza that would fix it. Good suggestion. Let me push that change.

[isidorn]

@jvesouza I have pushed a fix for this as you suggested, try it out from Thursdays vscode insiders and let me know what you think.

[jvesouza]

@isidorn It was great, thanks.

[Neurrone]

This works amazingly well, thank you!

I was trying to use the "Go to Selection Anchor" command without setting a keystroke by using it from the quick picker. But it doesn't show up when I search for anchor.

[Neurrone]

My bad, I just realized that the command list is smart enough to not offer that as an option if no anchor is present.

[isidorn]

@Neurrone yeah, we only show the command when it is applicable - when an anchor was set.

[tomaik]

@isidorn Can't we start selection automatically after command "Set Selection Anchor"? This way we won't need to use "Select From Anchor to Cursor" at all.

[zersiax]

@tomaik can you sketch outthe exact scenario? I fail to see what you mean exactly.
Right now you set the anchor, then scroll down to where you want your selection to end and select from anchor to cursor. So placing an anchor in a sense already starts selection. Starting to highlight from starting the anchor sort of defeats thepurpose a bit for the initial feature request, I think

[tomaik]

Current implementation:
Set Anchor -> Move cursor somewhere -> Select From Anchor To Cursor -> Copy/Cut/Delete

Proposal:
Set Anchor -> Move cursor somewhere -> Copy/Cut/Delete

But now I get your point that this won't work for screen reader so it should be separate feature.

[MarcoZehe]

Agree with @zersiax . The purpose was to reduce the verbiage screen readers issue when text is being selected. Also, not having the selection indicator on the braille display certainly helps with quickly finding the end point of the selection, before actually making it.

[isidorn]

@tomaik thanks for the suggestion, but as @MarcoZehe and @zersiax point out the current approach has more upside.