Review position not following system cursor in terminal applications
Jason White
I’ve been trying to use NVDA 2018.2.1 in terminal applications such as the Windows Subsystem for Linux. The BrailleExtender add-on is loaded, and highly desirable. It’s configured by default to ensure that the braille display tracks the review position in terminal applications.
Unfortunately, the review position isn’t following the system cursor. Thus, for example, if I issue a command that generates several lines on the terminal, and the cursor moves to the new prompt that immediately follows this output, the review position isn’t moved forward with it.
All of the NVDA preferences related to navigation seem to be set correctly as far as I can tell (I haven’t changed them from the defaults, as it’s a new installation on an up to date Windows 10 version 1803 system).
Have I neglected to change a setting, or is there a deeper problem here? Suggestions about likely causes and solutions would be most welcome.
|
|
Walker, Michael E
Jason,
Do you absolutely need the Windows subsystem for Linux to accomplish your goals? Can you accomplish what you need through PowerShell, the Cygwin terminal, MSYS, or Git BASH?
Best regards, Mike
From: nvda@nvda.groups.io [mailto:nvda@nvda.groups.io]
On Behalf Of Jason White via Groups.Io
I’ve been trying to use NVDA 2018.2.1 in terminal applications such as the Windows Subsystem for Linux. The BrailleExtender add-on is loaded, and highly desirable. It’s configured by default to ensure that the braille display tracks the review position in terminal applications.
Unfortunately, the review position isn’t following the system cursor. Thus, for example, if I issue a command that generates several lines on the terminal, and the cursor moves to the new prompt that immediately follows this output, the review position isn’t moved forward with it.
All of the NVDA preferences related to navigation seem to be set correctly as far as I can tell (I haven’t changed them from the defaults, as it’s a new installation on an up to date Windows 10 version 1803 system).
Have I neglected to change a setting, or is there a deeper problem here? Suggestions about likely causes and solutions would be most welcome.
|
|
Jason White
The problem isn’t confined to Windows Subsystem for Linux; I noticed it under msysv2 as well.
From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Walker, Michael E
Sent: Friday, August 17, 2018 4:20 PM To: nvda@nvda.groups.io Subject: Re: [nvda] Review position not following system cursor in terminal applications
Jason,
Do you absolutely need the Windows subsystem for Linux to accomplish your goals? Can you accomplish what you need through PowerShell, the Cygwin terminal, MSYS, or Git BASH?
Best regards, Mike
From: nvda@nvda.groups.io [mailto:nvda@nvda.groups.io] On Behalf Of Jason White via Groups.Io
I’ve been trying to use NVDA 2018.2.1 in terminal applications such as the Windows Subsystem for Linux. The BrailleExtender add-on is loaded, and highly desirable. It’s configured by default to ensure that the braille display tracks the review position in terminal applications.
Unfortunately, the review position isn’t following the system cursor. Thus, for example, if I issue a command that generates several lines on the terminal, and the cursor moves to the new prompt that immediately follows this output, the review position isn’t moved forward with it.
All of the NVDA preferences related to navigation seem to be set correctly as far as I can tell (I haven’t changed them from the defaults, as it’s a new installation on an up to date Windows 10 version 1803 system).
Have I neglected to change a setting, or is there a deeper problem here? Suggestions about likely causes and solutions would be most welcome.
|
|
Tyler Spivey
Is Caret moves review cursor (NVDA+6) on?
toggle quoted message
Show quoted text
On 8/17/2018 4:23 PM, Jason White via Groups.Io wrote:
The problem isn’t confined to Windows Subsystem for Linux; I noticed it |
|
Jason White
Thanks - I wasn't aware of that option. Restarting NVDA seemed to fix it in
toggle quoted message
Show quoted text
Windows Subsystem for Linux, but not in the msysv2 console.
-----Original Message-----
From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Tyler Spivey Sent: Friday, August 17, 2018 7:30 PM To: nvda@nvda.groups.io Subject: Re: [nvda] Review position not following system cursor in terminal applications Is Caret moves review cursor (NVDA+6) on? On 8/17/2018 4:23 PM, Jason White via Groups.Io wrote: The problem isn’t confined to Windows Subsystem for Linux; I noticedwith it.
|
|
Travis Siegel
The only time my NVDA cursor doesn't follow the system cursor when using either the command line in windows, or the cygwin environment is when I'm in screen review mode. As long as I'm in object navigation mode, it always follows the system cursor.
toggle quoted message
Show quoted text
On Fri, 17 Aug 2018, Jason White via Groups.Io wrote:
The problem isn’t confined to Windows Subsystem for Linux; I noticed it |
|
Michael
Jason, Tyler Spivey would definitely know. I have known him for years. He is one of the smartest developers I know. I remember him from when I was in high school and he went by TSP on networks. I went by foxwarrior09, as my school was called Fox, and the sports team was the Warriors.
toggle quoted message
Show quoted text
Mike
-----Original Message-----
From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Jason White via Groups.Io Sent: Friday, August 17, 2018 7:38 PM To: nvda@nvda.groups.io Subject: Re: [nvda] Review position not following system cursor in terminal applications Thanks - I wasn't aware of that option. Restarting NVDA seemed to fix it in Windows Subsystem for Linux, but not in the msysv2 console. -----Original Message----- From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Tyler Spivey Sent: Friday, August 17, 2018 7:30 PM To: nvda@nvda.groups.io Subject: Re: [nvda] Review position not following system cursor in terminal applications Is Caret moves review cursor (NVDA+6) on? On 8/17/2018 4:23 PM, Jason White via Groups.Io wrote: The problem isn't confined to Windows Subsystem for Linux; I noticedwith it.
|
|