Skip to content

Efficiently reviewing the output buffer in terminals #11172

Closed

Description

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

Activity

  1. codeofdusk commented on May 17, 2020

    @codeofdusk
    Contributor

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

  2. Neurrone commented on May 17, 2020

    @Neurrone
    Author

    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.

  3. codeofdusk commented on May 17, 2020

    @codeofdusk
    Contributor
  4. Neurrone commented on May 17, 2020

    @Neurrone
    Author

    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.

  5. JulienCochuyt commented on May 17, 2020

    @JulienCochuyt
    Contributor

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

  6. Neurrone commented on May 18, 2020

    @Neurrone
    Author

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

  7. added
    app/windows-terminalNew terminal app, potentially supersedes app/windows-console (repo: microsoft/terminal)
    on May 18, 2020
  8. Neurrone commented on May 28, 2020

    @Neurrone
    Author

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

  9. codeofdusk commented on Sep 22, 2020

    @codeofdusk
    Contributor

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

  10. zersiax commented on Feb 21, 2021

    @zersiax

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

  11. codeofdusk commented on Feb 21, 2021

    @codeofdusk
    Contributor

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

  12. codeofdusk commented on Nov 22, 2021

    @codeofdusk
    Contributor

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

  13. seanbudd commented on Nov 22, 2021

    @seanbudd
    Member

    Is 4 fixed with #12928?

  14. codeofdusk commented on Nov 22, 2021

    @codeofdusk
    Contributor

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

  15. added a commit that references this issue on Jun 21, 2022
    b817b03
  16. modified the milestone: 2022.3 on Jun 21, 2022
  17. Neurrone commented on Jun 22, 2022

    @Neurrone
    Author

    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.

  18. codeofdusk commented on Jun 22, 2022

    @codeofdusk
    Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    app/windows-terminalNew terminal app, potentially supersedes app/windows-console (repo: microsoft/terminal)

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions