Odd arrow keys and speak current character behavior with MinTTY under Windows Subsystem for Linux


Dan Miner
 

Just wanted to check to see if I am doing something wrong but I am having troubles editing shell commands with minty in any environment that uses it so far (Git for Windows, msys2 and WSLTTY).

 

I just installed the latest versions of Git for Windows, msys2 and WSLTTY in the last week And ran across a “consistent” problem.  I am using bash in its default configuration from these packages (Ubuntu 20.04.1 for WSL2).

 

 

The initial set up to reproduce problem (keeping it simple):

 

Type: echo hi

 

Without hitting return and intending to edit that line, changing hi (all lowercase) to Hi (with a capital H).

 

Press left arrow and “space” is spoken” and if you continue hitting the left or right arrows, you will always get “space” said.  So, it is easy to get lost as none of the under lying characters are spoken.  Thus, I hit the speak current character (Keypad 2) and I get an inconsistent spoken output of “space” or the character under the cursor.  Typical instances it will alternate between the two states and one time I got repeating twice.  To clarify, it would say “space”, “space” “h”, “h”, and cycle back to “space”.  But in this simple example and movement, it will likely just alternate back and forth between “space” and the letter (“I” in this case).

 

A partial workaround I have found is using bash’s readline advanced editing keys.  If I use control+left arrow and move by word, NVDA will speak the words as expected.  However, I still have to deal with arrow key problem and speak character issues within the word of interest.

 

Is anyone seeing this behavior?  It has been going on for many versions of NVDA (easily a year).

 

As sanity check, the standard cmd console behaves as expected with these features.

 

    Dan

Join nvda@nvda.groups.io to automatically receive all group messages.