From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Tony Malykh
Sent: Monday, December 21, 2020 9:59 AM
To: nvda@nvda.groups.io
Subject: Re: [nvda] Odd arrow keys and speak current character behavior with MinTTY under Windows Subsystem for Linux

 

So for pasting things, I implemented a function that pastes into command prompt window even when context menu is not available. You can get it in my Tony's enhancements add-on - you'd need to enable it in the options, it is disabled by default.

For copying things out of command prompt I would still try to use review cursor. Or for copying large amounts of data, like large output of some command, I have some scripts where on Linux side I save it to a shared folder, and on Windows I periodically check that shared folder and copy things to clipboard as they appear.

But yeah, I wish there was a single good terminal solution, that works for NVDA. I think too few blind people work in terminals, so things are what they are. Sometimes I am thinking, someone should just implmement a simple terminal from within NVDA - something that would be accessible to begin with - in the end there is no rocket science in terminals....

--Tony

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

 

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

 

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 Cygwin)…

    Dan

 

From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Tony Malykh
Sent: Sunday, December 20, 2020 10:40 PM
To: nvda@nvda.groups.io
Subject: Re: [nvda] Odd arrow keys and speak current character behavior with MinTTY under Windows Subsystem for Linux

 

If you would like to debug this yourself, you can probably start with class Terminal - defined in NVDAObjects/behaviors.py.

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.

HTH

--Tony

On 12/9/2020 9:59 AM, Dan Miner via groups.io 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.

 

    Dan