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.
toggle quoted messageShow quoted text
On 12/31/2020 8:35 PM, Dan Miner via
groups.io wrote:
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
|
