Change:
Type: <bBug</bThere is an accessibility regression from 1.82 1.83 with the integrated terminal. In 1.83, with JAWS a command in integrated terminal Shift+Tab Actual: JAWS is silent. Experience is clunky, up/down seems to write commands in the terminal input. Much worse experience versus 1.82 Expected: Focus moves to the readonly edit where I can review output. Note: Yes, Alt+F2 is a nice buffer, but Shift+Tab should take you to an accessible readonly edit like it did in 1.82 In 1.82, that would be: ac ommand in integrated terminal Shift+Tab Actual: JAWS reads readonly edit and you can navigate up and down the terminal output. It's super nice, because you can use the shortcut Ctrl+and focus moves back to where I was in the terminal output and I can just read down, then back to code with Ctrl+. Please fix that regression. I tried other flows, like that focus virtual buffer whenever a command is run, which is good, and let's keep that option, but not as good as it was in 1.82 and I find no equivalent in 1.83 VS Code version: Code - Insiders 1.83.0-insider (, 2023-09-29T20:42:50.630Z) OS version: WindowsNT x64 10.0. Modes: &lt;details&lt;summarySystem Info&lt;/summary &lt;/details&lt;details&lt;summaryExtensions (15)&lt;/summaryExtensionVersion ------ csdevkit0.5.127 csharp2.4.4 vscode-dotnet-runtime1.8.0 vscodeintellicode-csharp0.1.26 python2023.17. vscode-pylance2023.9.31 vsliveshare1.0.5883 java1.23.0 intellicode-api-usage-examples0.2.8 vscodeintellicode1.2.30 vscode-java-debug0.54.0 vscode-java-dependency0.23.1 vscode-java-pack0.25.14 vscode-java-test0.40.0 vscode-maven0.42.0 &lt;/details&lt;details&lt;summaryA/B Experiments&lt;/summary&lt;/details&lt;!-- generated by issue reporter --
Hi, you can also use to enter the accessible terminal view. We moved from to or to better align with other features around the workbench and so as to not interfere with autocompletion. You can still assign that keybinding to the command if you prefer it though.
There is a change versus 1.82 around focus management. Let me give you a scenario and what it would look like in 1.82 and 1.83. Note: I will use Ctrl+Up for 1.83 and Shift+Tab for 1.82. Scenario 1: 1.82 any file, let's say you are writing some code on line 50 of a file. Ctrl+, focus moves to integrated terminal Shift+Tab, focus moves to accessible buffer up/down to read the content, let's say you stop on line 20 of the output. Ctrl+, focus moves back to line 50 in the code editor. Ctrl+, focus moves to line 20 of the output. Scenario 1: 1.83 any file, let's say you are writing some code on line 50 of a file. Ctrl+, focus moves to integrated terminal Ctrl+Up, focus moves to accessible buffer up/down to read the content, let's say you stop on line 20 of the output. Ctrl+, focus moves to the input of integrated terminal. Ctrl+again, focus moves to line 50 in code editor. Ctrl+ a third time, focus moves to input of integrated terminal. This is annoying, there is no way anymore to easily go back and forth between code and output.
Thanks for the steps. Now I understand. I just discussed this with and he prefers the approach as it currently works, so we should make this configurable.
Thanks for putting this in the backlog. Can you elaborate on the solution you have in mind to solve for this scenario? I think there are different ways to design a solution to this problem and was curious to understand more what you were thinking. Maybe we could have a focus: terminal buffer action? I could map Ctrl+Shift+to it and it could move my focus to the terminal buffer wherever my focus was. So the scenario could be like: any file, let's say you are writing some code on line 50 of a file. Ctrl+, focus moves to integrated terminal Alt+F2, , focus moves to accessible buffer up/down to read the content, let's say you stop on line 20 of the output. Ctrl+1, focus moves back to line 50 in the code editor. Ctrl+Shift+(action focus: terminal buffer), focus moves to line 20 of the output. That way Ctrl+ brings you to the terminal output instead - and this is the important part - wherever your focus lastw as in the output. Plus, Ctrl+Shift+ would work from anywhere, including from the code editor, which would ease frequent back and forth between code and terminal output, such as in Python flows.
I'm imagining we have a setting "preserve line" vs "last line" that determines what is focused when the accessible terminal view is opened. Pressing arrow will always move you to the last line in the buffer if you're not already there, so that case is covered. Pressing arrow on the last line refocuses the terminal buffer. The / arrow flow is how many other workbench components (extensions view input to results, debug input box to results, and more) work atm, which is why this makes sense. Would that work for you?
maybe I misunderstood, but I believe your solution would always require at least two navigation actions to go from the code to the terminal output: Ctrl+, then Ctrl+Up. I'd like to avoid having to do two navigation actions every time to do back and forth. Would there be a way to get to terminal output from anywhere?
You can add a keybinding to focus the terminal's accessible buffer like this, one step required: The other thing you might find useful is the setting. If you set that to then run something in the terminal, the accessible terminal view is focused, displaying the output.
Wow, that shortcut works like a charm! Could we maybe add a default shortcut? Maybe Ctrl+Shift+ for that action ""? With that shortcut, the only thing missing would indeed be that preserve line setting. One thing I might add on the behavior of preserve line setting: If your focus is at the end of the buffer (Ctrl+End), and then you run a command, if preserve line setting is enabled, then focus does not move, and when you get back to the buffer, pressing Down arrow will be the command you just ran. This would solve the annoying issue that whenever you read terminal output, you always need to first scroll back up to read down the content. For instance, if a command outputs 20 lines of text, then you need to scroll back up 20 lines to read down 20 lines. With a preserve line setting, then you can just read down, run something else, get back to buffer and read down from where you were.
` is currently assigned to creating a new terminal, so we don't want to conflict with that and break muscle memory. It's hard to find a keybinding that's not already in use, which is why it might be best if you assign this yourself.
thanks for the new setting, I think there is an issue with the implementation. The focus stays where it is in the buffer, but text scrolls underneath it. The cursor should move up with the text. For instance, if terminal output has 10 lines of text and cursor is on line 9. Then you issue a command that outputs two more lines of text. Cursor should stay on line 9, but with this setting it will be on line 11. It's as if the two new lines of text pushed up the text by two lines, but cursor did not move up and stayed there. To repro command "echo test1" accessible buffer, put cursor on line where it says "test1". command "echo test2" back accessible buffer, notice that cursor is now on line that says "test2", no longer on line that said "test1"
that is by design. I figured when a user runs another command, they'll be more interested in that output than wherever they might have been before. This works just like a terminal does, which is what we want to model here.
but what if I run a few commands back to back? Isn't the setting supposed to preserve cursor position rather than moving it to the last command's output? What I was hoping with this setting is runs a command reviews the output runs multiple commands can pick up where they left off and review the new output. This setting's current implementation is skipping outputs, it's moving the cursor when it's supposed to preserve it. If I wanted the cursor to move, I would not set the preserve position setting on. Note that preserving cursor position is a very desirable behavior in a lot of apps. For instance, if I read a Word doc, alt+tab away and come back later, I expect my cursor to stay put so I can resume reading. Same thing for web pages, emails, etc. This is what I wanted. Imagine an app that logs things, I want to go to the output and resume reading logs. Or if I work on a Python script, run a few commands and then go review the output of those few commands.
Ok, I misunderstood your request. Thanks for the explanation.
To verify: Set to . Open a terminal, enter a command, open the accessible view. The cursor should be on the last line Move the cursor up Run another command in the terminal Open the accessible view The cursor position should be preserved Set to . Open a terminal, enter a command, open the accessible view. The cursor should be on the last line Move the cursor up Run another command in the terminal Open the accessible view The cursor should be on the last line Also, try running a script with dynamic output: for either setting value, the current cursor position should be preserved. Note that if your cursor position is at the first column and line, then it will get reset to the bottom. This is because when the editor's contents change, the cursor by default gets set to be at column & line 1. Thus, we use this condition to determine when it should be set to the bottom IE initially.
Your initial description of the setting on and off seems correct to me. Let me add though that if the content of terminal gets cleared, then cursor position resets to the bottom. I suspect that would already be the case without any code change, but just wanted to spec out this desired behavior. To validate the setting behavior when you have the new implementation, test this: "echo test1" in terminal accessible buffer, move cursor right before the 1 in "test1" terminal input, run "echo test2", then "echo test3" accessible buffer, cursor is still before the 1 of "test1" For the dynamic output script that you talk about, why would the behavior of that setting off change to be preserved? Why would cursor no longer be sent to the bottom? About the edge case of if cursor is at (1,1), then sending the cursor to the bottom is acceptable and thanks for the call out.
Thanks for the testing steps, those work based on my testing of the PR. One other thing to note - this accessible view is meant to be shared across components and several terminals share the same one. So, we will not preserve position when one switches between terminals, as we currently don't have a mechanism to do so. In this case, it will default to the bottom. I hope that's not a big issue for you. I've noticed that generallly, JooYoung is only working in one terminal at a time.
And yeah I agree with you, we can let the setting decide in the case of dynamic output what happens. The reason I suggested otherwise was it used to work like I described.
Works like a charm. I typically work on one terminal at a time, will open a new issue if I encounter workflows that require a lot of switching between terminals.

Discussion:
SmoothScrolling = 'terminal.integrated.smoothScrolling', IgnoreBracketedPasteMode = 'terminal.integrated.ignoreBracketedPasteMode', FocusAfterRun = 'terminal.integrated.focusAfterRun', <ins> AccessibleViewPreserveCursorPosition = 'terminal.integrated.accessibleViewPreserveCursorPosition', </ins> // Debug settings that are hidden from user

import { IOpenerService } from 'vs/platform/opener/common/opener'; import { IPickerQuickAccessItem } from 'vs/platform/quickinput/browser/pickerQuickAccess'; import { IQuickInputService } from 'vs/platform/quickinput/common/quickInput'; <ins> import { TerminalSettingId } from 'vs/platform/terminal/common/terminal'; </ins> import { AccessibilityVerbositySettingId, AccessibleViewProviderId, accessibilityHelpIsShown, accessibleViewCurrentProviderId, accessibleViewGoToSymbolSupported, accessibleViewIsShown, accessibleViewOnLastLine, accessibleViewSupportsNavigation, accessibleViewVerbosityEnabled } from 'vs/workbench/contrib/accessibility/browser/accessibilityConfiguration'; import { AccessibilityCommandId } from 'vs/workbench/contrib/accessibility/common/accessibilityCommands'; import { getSimpleEditorOptions } from 'vs/workbench/contrib/codeEditor/browser/simpleEditorOptions';

this._editorWidget.updateOptions({ ariaLabel }); this._editorWidget.focus(); if (this._currentProvider?.options.positionBottom) { <del> const lastLine = this.editorWidget.getModel()?.getLineCount(); const position = lastLine !== undefined && lastLine > 0 ? new Position(lastLine, 1) : undefined; if (position) { this._editorWidget.setPosition(position); this._editorWidget.revealLine(position.lineNumber); </del> <ins> const currentPosition = this.editorWidget.getPosition(); const defaultPosition = currentPosition && currentPosition?.lineNumber === 1 && currentPosition?.column === 1; if (currentPosition && this._configurationService.getValue(TerminalSettingId.AccessibleViewPreserveCursorPosition) && !defaultPosition) { this._editorWidget.setPosition(currentPosition); } else { const lastLine = this.editorWidget.getModel()?.getLineCount(); const position = lastLine !== undefined && lastLine > 0 ? new Position(lastLine, 1) : undefined; if (position) { this._editorWidget.setPosition(position); this._editorWidget.revealLine(position.lineNumber); } </ins> } } });

localize('terminal.integrated.focusAfterRun.accessible-buffer', "Always focus the accessible buffer."), localize('terminal.integrated.focusAfterRun.none', "Do nothing."), ] <ins> }, [TerminalSettingId.AccessibleViewPreserveCursorPosition]: { markdownDescription: localize('terminal.integrated.accessibleViewPreserveCursorPosition', "Preserve the cursor position on reopen of the terminal's accessible view rather than setting it to the bottom of the buffer."), type: 'boolean', default: false </ins> } } };