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

Tyler Spivey

No, it wasn't.
I don't use mintty at all, but I just tried it and got the same result as you.
Press alt space, Options, change the cursor type from Line to Underscore.

On 12/20/2020 7:07 PM, Dan Miner via wrote:
Was my question confusing or unclear?
I’d research deeper but I’m still pretty new to NVDA and still unsure where to look in the codebase.  The fact that backspace reads the deleted character is encouraging and suggests the support code in MinTTY or Putty for NVDA may just need a bit of adjustment.  I’d do it myself but need a helping hand getting started and pointed in the right direction.
On Dec 9, 2020, at 11:08 AM, Dan Miner via <dminer84@...> wrote:

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.


Join to automatically receive all group messages.