nvaccess / nvda

NVDA, the free and open source Screen Reader for Microsoft Windows
https://www.nvaccess.org/
Other
2.12k stars 637 forks source link

Efficiently reviewing the output buffer in terminals #11172

Closed Neurrone closed 2 years ago

Neurrone commented 4 years ago

CC: @codeofdusk

Is your feature request related to a problem? Please describe.

I couldn't figure out how to do the following:

  1. Efficiently review text that has scrolled offscreen.
  2. Efficiently copy parts of the buffer to the clipboard that have scrolled offscreen
  3. Find occurances of a search term of interest, which is really useful in many situations. Both the legacy terminal and the new Windows Terminal have a find function which visually highlights matches, but there's no way to move to it with NVDA.
  4. Probably slightly out of scope: dealing with text-based tables. For example, a command line disassembler usually has the memory address in the first column, which you are subjected to hearing on every line when using NVDA even though you're actually interested in the actual CPU instructions. Many useful commands also output statistics in tables which is hard to read.

Describe the solution you'd like

These are just some ideas for now, I'd love to hear how others have solved these issues.

  1. Logging all output to a virtual document: using a key to switch to it, maybe nvda + space, you would then be able to review past output up to e.g, the past 1000 lines. I'm not sure what the performance implications of this are, but it might allow for some possibilities in the future such as turning text-based tables into a table that NVDA recognizes, or turning each prompt line into a heading for faster navigation.
  2. Make use of the hotkeys in the terminal: conhost has the mark mode for this but there are some oddities when trying to use it in practice. This also does not work with the legacy terminal in WSL and is also not supported in Windows Terminal, see microsoft/terminal#5948.
  3. Use a paging utility

Describe alternatives you've considered

I have therefore been forced to copy all text and paste it into a blank notepad document just to do some of these basic tasks.

codeofdusk commented 4 years ago

For offscreen text there was #9735, but this was rejected in favour of using the native scrolling commands.

Neurrone commented 4 years ago

Can we revisit #9735? Are there performance concerns if offscreen text can be reviewed? This would be really useful given how poorly the text selection keys are supported.

codeofdusk commented 4 years ago

Cc @feerrenrut.

Neurrone commented 4 years ago

What are your thoughts on having a virtual document mode that we could fall back on using? Is that technically feasible? E.g, to solve the find problem and maybe tables.

JulienCochuyt commented 4 years ago

@codeofdusk, if #9735 is ever revived:

Additionally, a generalized "Find" mechanism is often asked for in situations other than browseable documents. While it can meet caveats in random windows, it could at least search through the same text NVDA+b reads, and would be fairly safe in consoles.

Tables are a much more tricky matter to handle properly...

Neurrone commented 4 years ago

@JulienCochuyt agreed about tables being much trickier. I only mentioned it because it can only be solved if the output buffer can be rendered in a virtual document, which could affect how this problem is solved. Having a virtual buffer would also make review and find much more pleasant.

Neurrone commented 4 years ago

Related: navigation of output by command is tracked in microsoft/terminal#6232

codeofdusk commented 4 years ago

It was mentioned in https://github.com/microsoft/terminal/issues/6453#issuecomment-674361602 that some new console text can actually appear below the visible range, making it completely inaccessible to NVDA.

Additionally, there are plans to automatically detect (and make clickable) links in Conhost and Terminal (see microsoft/terminal#7691).

I think it makes sense to do the following:

As an initial implementation, I tried setting winConsoleUIA.treeInterceptorClass to UIABrowseMode.UIABrowseModeDocument and shouldCreateTreeInterceptor to False, but the virtual buffer was confined to one line of text. Am I missing something?

Cc @carlos-zamora, @leonardder, @michaelDCurran.

zersiax commented 3 years ago

Bump. Is this still on the backlog? TO what degree does the new diffing algorithm in alpha builds contribute to this?

codeofdusk commented 3 years ago

I'll re-evaluate after microsoft/terminal#6986.

codeofdusk commented 2 years ago

OK, looks like all but 4 are fixed with #10964.

seanbudd commented 2 years ago

Is 4 fixed with #12928?

codeofdusk commented 2 years ago

It is not, and was listed as out of scope for this issue.

Neurrone commented 2 years ago

Some of the scenarios in the issue hasn't been addressed. For example, the ability to efficiently find and navigate to matches of search terms.

codeofdusk commented 2 years ago

Ctrl+f now works (it didn't in legacy), at least to find an initial match. F3 to move to the next match doesn't seem to work for me, but that's a Microsoft issue (i.e. out of scope for NVDA).