Repository navigation
Closed
Labels
app/windows-terminalNew terminal app, potentially supersedes app/windows-console (repo: microsoft/terminal)New terminal app, potentially supersedes app/windows-console (repo: microsoft/terminal)
Milestone
Description
CC: @codeofdusk
Is your feature request related to a problem? Please describe.
I couldn't figure out how to do the following:
- Efficiently review text that has scrolled offscreen.
- Efficiently copy parts of the buffer to the clipboard that have scrolled offscreen
- 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.
- 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.
- 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.
- 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.
- 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.
Metadata
Metadata
Assignees
Labels
app/windows-terminalNew terminal app, potentially supersedes app/windows-console (repo: microsoft/terminal)New terminal app, potentially supersedes app/windows-console (repo: microsoft/terminal)
Activity
codeofdusk commentedon May 17, 2020
For offscreen text there was #9735, but this was rejected in favour of using the native scrolling commands.
Neurrone commentedon May 17, 2020
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 commentedon May 17, 2020
Cc @feerrenrut.
Neurrone commentedon May 17, 2020
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 commentedon May 17, 2020
@codeofdusk, if #9735 is ever revived:
NVDA+F9/NVDA+shift+F9could be used to mark and jump for easier review of the last command executed. Currently, it works only when no scrolling occurred.enterwas 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+breads, and would be fairly safe in consoles.Tables are a much more tricky matter to handle properly...
Neurrone commentedon May 18, 2020
@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 commentedon May 28, 2020
Related: navigation of output by command is tracked in microsoft/terminal#6232
codeofdusk commentedon Sep 22, 2020
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:
As an initial implementation, I tried setting
winConsoleUIA.treeInterceptorClasstoUIABrowseMode.UIABrowseModeDocumentandshouldCreateTreeInterceptortoFalse, but the virtual buffer was confined to one line of text. Am I missing something?Cc @carlos-zamora, @LeonarddeR, @michaelDCurran.
zersiax commentedon Feb 21, 2021
Bump. Is this still on the backlog? TO what degree does the new diffing algorithm in alpha builds contribute to this?
codeofdusk commentedon Feb 21, 2021
I'll re-evaluate after microsoft/terminal#6986.
codeofdusk commentedon Nov 22, 2021
OK, looks like all but 4 are fixed with #10964.
seanbudd commentedon Nov 22, 2021
Is 4 fixed with #12928?
codeofdusk commentedon Nov 22, 2021
It is not, and was listed as out of scope for this issue.
UI Automation in Windows Console: make default in FORMATTED consoles …
Neurrone commentedon Jun 22, 2022
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 commentedon Jun 22, 2022
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).