Well, I’ll take a peek and see if I can
make any sense of it.
As for why, I find myself in WSL, mSYS2 and
Cygwin depending on the task I am trying to do or testing. It
would be helpful to have a consistent terminal for them all
and MinTTY is the closest I know of. Regarding using Cmd
console, it doesn’t work in ways needed for anything that
prompts for a password in the Cygwin-style. So, ssh, svn and
“native git” will fail horribly and hair loss is soon to
I’m actually a Linux guy trying to adapt to
developing on Windows and for Windows. Thus, I keep running
back to UNIX-like land when my blood pressure gets too high.
The WSL standard terminal (basically Cmd
but not quite) has an accessibility bug and will not respond
to ALT+spacebar to open the system menu. I couldn’t turn on
cut and paste until recently because my object navigation
skills in NVDA reached a level I could find the system menu in
the terminal UI object structure and get the mouse over there
and simulate a left lick on it.
Now if I could figure out why the terminal
audible bell doesn’t work for any minty (WSL, MSYS2 or
If you would like to debug this yourself, you can probably
start with class Terminal - defined in
But also, just curious, why can't you use normal command
prompt if things are working fine there? If I remember
correctly MSYS can run in command prompt.
On a side note, I have been suffering from poor editing
experience in command line too, mostly over ssh connections,
soI have been thinking about an add-on that would provide a
better way to edit command in command line - it will try to
identify current text in command line and open it up in a
fully accessible edit box, then after editing it will update
it back in the command line. So whenever I have some free
time, I'll work on this.
On 12/9/2020 9:59 AM, Dan Miner via
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
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).
set up to reproduce problem (keeping it simple):
hitting return and intending to edit that line, changing
hi (all lowercase) to Hi (with a capital H).
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).
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.
seeing this behavior? It has been going on for many
versions of NVDA (easily a year).
check, the standard cmd console behaves as expected with