Add "report formatting under cursor routing key" command

[dkager]

See #7097 (comment)

This would be the ideal action for the Alva BC6 and other displays with second cursor routing keys. On other displays it could be something like NVDA+routing.

Technical from @jcsteh:

From an implementation perspective, I think we'd need to add a method to get a TextInfo from a routing index. Duplicating formatting reporting code in both globalCommands and braille sounds ugly to me.

[jcsteh]

When you say NVDA+routing, I assume you mean the NVDA key on the keyboard? Merging a modifier on the keyboard and a braille display key into a single gesture is not something we can currently support. However, wouldn't it be better to have it assigned to keys both on the display; e.g. c1+routing on a Brailliant B display? I think most displays would have at least one command key in order to facilitate scrolling, etc.

[dkager]

When you say NVDA+routing, I assume you mean the NVDA key on the keyboard?

Yes, but your suggestion makes more sense indeed. This assumes displays and drivers can deal with combinations of keys plus routing.
CC @LeonarddeR

[jcsteh]

Yeah, some drivers certainly can't. freedomScientific can't. alvaBC6 can't either, though it's not needed there because of the second routing row. These (and perhaps others) are probably more driver implementation details than display limitations, but we can't be certain without testing.

[LeonarddeR]

Handy Tech does support this. I recall that the Baum driver doesn't, but that might be something which we can fix.

[jcsteh]

The Baum driver definitely supports this. I just tested it (and I also wrote the code).

[dkager]

I still think supporting e.g. NVDA+routing would be beastly awesome, but that's a topic for another day. Judging by this discussion it's OK to start with on-display key combinations for the issue at hand.

[jcsteh]

Wouldn't NVDA+routing be pretty awkward to press (you'd have to move one hand to your keyboard just to press the NVDA key)? I guess that's something we could special case in BrailleInputGesture, but I wouldn't want to have to support this generically; combining gestures in a generic sense sounds frought with danger.

[dkager]

This is all true. I just feel a bit bad for excluding those displays that don't support gestures with routing keys.

One use case from my earlier screen reader days was to use Shift+routing to select up to a certain point of text, e.g. in Notepad. But the only reason that required Shift was because the routing keys emulated actual mouse clicks AFAIK.

On the subject of reporting formatting, I'm still contemplating how to code this in a non-ugly way. :)

[jcsteh]

Suggested implementation: 1. Create a method in braille.TextInfoRegion to get a TextInfo for a given routing index. You can use the start of the code from the routeTo method. It'd probably make sense to have routeTo call this method. 2. create a method in BrailleHandler that calls the above method on the correct region, similar to the routeTo method there. You may also need to implement a method before this in BrailleBuffer; I'm not sure. Again, routeTo is your guide. 3. In globalCommands, create a helper method for report formatting which takes a TextInfo and a boolean indicating whether to show the info in browse mode. This will be most of the code from the current reportFormatting script. 4. Create a braille routing report formatting script which gets the TextInfo using the method outlined in point 2 and calls the helper method with that.