toggle quoted messageShow quoted text
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…
From: firstname.lastname@example.org <email@example.com> On Behalf Of Tony Malykh
Sent: Monday, December 21, 2020 5:43 PM
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*
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....
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)…
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.
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.