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


Tony Malykh
 

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

Join nvda@nvda.groups.io to automatically receive all group messages.