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

Dan Miner

*sigh* How about that... that seems to clear it up and arrow keys are reading the characters. I would have never thought of that one.

Would anyone have a clue of an explanation for why this works?


-----Original Message-----
From: <> On Behalf Of Tyler Spivey
Sent: Sunday, December 20, 2020 8:29 PM
Subject: Re: [nvda] Odd arrow keys and speak current character behavior with MinTTY under Windows Subsystem for Linux

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