On Dec 9, 2020, at 11:08 AM, Dan Miner via groups.io <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.

 

    Dan

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

On Dec 9, 2020, at 11:08 AM, Dan Miner via groups.io <dminer84=yahoo.com@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

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

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

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

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

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.

Dan

On Dec 9, 2020, at 11:08 AM, Dan Miner via groups.io
<dminer84=yahoo.com@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

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

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

I’ll take a closer look at your add-on.

 

For my usage of “cut & paste”, I am usually only pasting into a terminal.  And I do like that review mark & copy mechanism  For the larger copy needs, I was just redirecting to a file and yanking it open in something like notepad.  But I recently ran across a Windows CLI utility  called clip.exe which can remove all of that or shorten up the steps.  Works withinMSYS2, Cygwin, and WSL (must be clip.exe or aliased somehow to drop the .exe).

 

My wish list is a bit different, I want faster navigation tools for the terminal like there was back in the late 80s and early 90s.  A DOS screen reader back then was a terminal navigation ninja.  At a minimum, I need “review: go to top of screen” and “review: Find first occurrence” plus “review: Find Next”  A real nice to have would be prompt tracking and using a key combo to go backward and forward along the “prompt blocks”.  Then there is good vim within the terminal support… *sigh*

 

                Dan

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

On 12/20/2020 10:23 PM, Dan Miner via groups.io wrote:

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

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

Yeah, clip.exe is great if you are in MSYS or WSL.
> review: go to top of screen
Try Shift+Numpad 7?
Finding things in review mode can be a nice feature.
What is prompt tracking ? NVDA seems to be pretty responsive in command prompt, and you can even navigate control+Left/right, nVDA would track all the words correctly. It probably won't work as well in bash, since the definition of the word is different. That's why I want to write command line editor add-on for NVDA....

As for VIM support or emacs support, people have been talking for a long time, but it seems to me that not enough people are actually using either vim or emacs, so nobody has actually spent time on this. Most NVDA users either use specialized IDEs for coding, or something like Notepad++. And also it is not quite clear how to improve accessibility of emacs/vim - that is there is no way for screenreader to identify what's running inside the command prompt application, especially given the fact that emacs/vim can run from within SSH session.

I’ll take a closer look at your add-on.

 

For my usage of “cut & paste”, I am usually only pasting into a terminal.  And I do like that review mark & copy mechanism  For the larger copy needs, I was just redirecting to a file and yanking it open in something like notepad.  But I recently ran across a Windows CLI utility  called clip.exe which can remove all of that or shorten up the steps.  Works withinMSYS2, Cygwin, and WSL (must be clip.exe or aliased somehow to drop the .exe).

 

My wish list is a bit different, I want faster navigation tools for the terminal like there was back in the late 80s and early 90s.  A DOS screen reader back then was a terminal navigation ninja.  At a minimum, I need “review: go to top of screen” and “review: Find first occurrence” plus “review: Find Next”  A real nice to have would be prompt tracking and using a key combo to go backward and forward along the “prompt blocks”.  Then there is good vim within the terminal support… *sigh*

 

                Dan

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

On 12/20/2020 10:23 PM, Dan Miner via groups.io wrote:

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

Ok, I downloaded it and read the README and still scratching my head about the pager extension.  I  think it is assuming less is on the system path which isn’t the case for newer installations from the installers.  And if it was doing that, I would remove  it.  I use Cygwin and MSYS2 and the last I need is them crossing over in unexpected ways.  As less isn’t native on Windows 10 (yet?), I guess I would need to adjust the pipe suffix text to point directly to a cygwin less binary.

 

But the quick try so far, I ssh’ed into my raspberry and did an apt update… A truly irritating  experience with current NVDA behaviors….  It was much better  as it is full of rapid URL fetches and percentages that is generally unhelpful to hear the whole lot.  It still got a batch of them towards the end when it paused for some reason.  I honestly would like to find a way to mediate the whole reading of URLs in all contexts. 

 

Is there a some magic key combo to say “skip currently spoken word?”  As I believe NVDA is sending it on as a “word” and the TTS blindly reads it in the most annoying manner possible.  If I could just say.. “skip that piece and continue”.

 

                Dan

 

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

 

For what it's worth, I wrote a new add-on Console Toolkit. Always wanted to write something for myself, but your message finally made me to find some time and do so. Basically you can capture output of any command with it, it works by redirectign output to "less" command and then interacting with it and reading the output page by page. Works in cmd.exe and bash, possibly over ssh, but requires some configuration.

https://github.com/mltony/nvda-console-toolkit/releases/download/v0.2dev/consoleToolkit-0.2dev.nvda-addon

HTH

--Tony

 

------ Original Message ------

From: "Dan Miner via groups.io" <dminer84@...>

To: nvda@nvda.groups.io

Sent: 12/21/2020 11:00:04 PM

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

 

The shift modifier did the trick so now I can jump to the top or bottom quickly.  Now just need “Go to line” kind of feature and targeted navigation will have decent support.   Like pressing shift+keypad 5, then it could prompt for input and I enter 6 and it moves the review cursor to line 6 of the object, and for extra credit: 6,15 to move to line 6 and position 15.  The next one of less use is “where am I?” to report the believed line and position of the cursor in the object.  And the one I am surprised to not find is text search via review cursor in a terminal like display.. even dialog boxes would benefit.

 

As for “What is prompt tracking”, I see I wasn’t clear.  It’s the little bit of text throw out by shells before waiting on user input.  Any modest command-line user is aware of them but they can be a bother to find easily.  There was a screen reader that did a surprisingly good job noting these natural “stopping points” in the user’s interactions and kind of treated them like a bookmark or annotation to be used like a latter to climb up and down the terminal session.  Great for referencing and linking ideas together.

 

As for emacs, I think much of the barebones support is there since bash is quite emacs-like.  It is the control key combos which do movement and modifications which is missing.  Most they just need to read character or word, etc the current position.  This is how I would approach vim support too initially.  It is the navigation by non-arrow key means which causes problems and it is common in vim.  Vim (and vi based editors) use a neat compositional  approach to its command structure which will help support the basics.

 

Then line numbered displays with monitored (quiet or live) regions and we have a decent text area canvas to paint our wonderous creations upon.  The gotcha is knowing the app within the terminal to use an app switching approach like regular Windows apps.

 

Ah well… I can dream…

 

    Dan

 

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

 

Yeah, clip.exe is great if you are in MSYS or WSL.
> review: go to top of screen
Try Shift+Numpad 7?
Finding things in review mode can be a nice feature.
What is prompt tracking ? NVDA seems to be pretty responsive in command prompt, and you can even navigate control+Left/right, nVDA would track all the words correctly. It probably won't work as well in bash, since the definition of the word is different. That's why I want to write command line editor add-on for NVDA....

As for VIM support or emacs support, people have been talking for a long time, but it seems to me that not enough people are actually using either vim or emacs, so nobody has actually spent time on this. Most NVDA users either use specialized IDEs for coding, or something like Notepad++. And also it is not quite clear how to improve accessibility of emacs/vim - that is there is no way for screenreader to identify what's running inside the command prompt application, especially given the fact that emacs/vim can run from within SSH session.

 

On 12/21/2020 10:30 AM, Dan Miner via groups.io wrote:

I’ll take a closer look at your add-on.

 

For my usage of “cut & paste”, I am usually only pasting into a terminal.  And I do like that review mark & copy mechanism  For the larger copy needs, I was just redirecting to a file and yanking it open in something like notepad.  But I recently ran across a Windows CLI utility  called clip.exe which can remove all of that or shorten up the steps.  Works withinMSYS2, Cygwin, and WSL (must be clip.exe or aliased somehow to drop the .exe).

 

My wish list is a bit different, I want faster navigation tools for the terminal like there was back in the late 80s and early 90s.  A DOS screen reader back then was a terminal navigation ninja.  At a minimum, I need “review: go to top of screen” and “review: Find first occurrence” plus “review: Find Next”  A real nice to have would be prompt tracking and using a key combo to go backward and forward along the “prompt blocks”.  Then there is good vim within the terminal support… *sigh*

 

                Dan

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

On 12/20/2020 10:23 PM, Dan Miner via groups.io wrote:

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