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
