|
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
toggle quoted message
Show quoted text
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
|
|
|
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.
toggle quoted message
Show quoted text
On 12/20/2020 7:07 PM, Dan Miner via groups.io 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.
Dan
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
|
|
|
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:
toggle quoted message
Show quoted text
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
On 12/9/2020 9:59 AM, Dan Miner via
groups.io wrote:
toggle quoted message
Show quoted text
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
toggle quoted message
Show quoted text
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
|
|
|
*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?
Dan
toggle quoted message
Show quoted text
-----Original Message----- From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Tyler Spivey Sent: Sunday, December 20, 2020 8:29 PM To: nvda@nvda.groups.io 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 groups.io 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.
Dan
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
|
|
|
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:
toggle quoted message
Show quoted text
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
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
toggle quoted message
Show quoted text
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 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
|
|
|
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:
toggle quoted message
Show quoted text
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
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
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
|
|
|
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.
toggle quoted message
Show quoted text
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 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 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
|
|
|
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.
HTH --Tony
toggle quoted message
Show quoted text
------ Original Message ------
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 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 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
|
|
|
On 12/21/20 1:23 AM, Dan Miner via
groups.io wrote:
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.
Have you tried Windows Terminal? NVDA support was added in a
somewhat recent release, and further improvements are expected. It
can run PowerShell and WSL.
My personal preference is to run Linux natively of course, but
that isn't a topic for the NVDA list.
|
|
|
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
toggle quoted message
Show quoted text
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. ------ Original Message ------ 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 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 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
|
|
|
1. If you are using it on windows, you do need to specify path to
less. On most Linux installations less should be already on your
path, as well as in Cygwin. That is mentioned in my documentation.
2. I am not aware of skip word functionality in NVDA.
3.Something you might consider using to skip over URLs is my
Phonetic Punctuation add-on. You can specify a regexp for URL and
have it replaced with a short sound. But the catch is that it
doesn't differentiate between applications, so then you'll replace
URLs with sounds everywhere.
On 12/31/2020 8:35 PM, Dan Miner via
groups.io wrote:
toggle quoted message
Show quoted text
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
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.
------ Original Message ------
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
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
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
|
|
|
