Efficiently reviewing the output buffer in terminals

[Neurrone]

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 Implement scrolling and selection of output text via the keyboard 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]

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

[Neurrone]

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]

Cc @feerrenrut.

[Neurrone]

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]

@codeofdusk, if #9735 is ever revived:

• NVDA+F9 / NVDA+shift+F9 could be used to mark and jump for easier review of the last command executed. Currently, it works only when no scrolling occurred.
• An approach similar to PR Python Console: Jump to previous/next result (#9784) #9785 could be tested on terminal consoles: jumping to next/previous position where enter was pressed - less efficient than on the Python console, but still a big improvement.

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]

@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]

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

[codeofdusk]

It was mentioned in microsoft/terminal#6453 (comment) 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:

• Keep terminal review bounded to visible ranges, as done currently (i.e. scrap UI Automation in Windows Console: Disable visible range bounding on 21H1 and later #11495).
• Allow for browse mode in UIA terminals, to allow links to be easily clicked and for review beyond the bounds. Properly handle and test "end of buffer" in UiaTextRange microsoft/terminal#6986 would improve the practical usability of this feature (we wouldn't have thousands of empty lines).

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]

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

[codeofdusk]

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

[codeofdusk]

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

[seanbudd]

Is 4 fixed with #12928?

[codeofdusk]

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

[Neurrone]

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]

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).