Change:
import { IXtermCore } from 'vs/workbench/contrib/terminal/browser/xterm-private'; import { ConfigurationTarget, IConfigurationService } from 'vs/platform/configuration/common/configuration'; import { TerminalConfigHelper } from 'vs/workbench/contrib/terminal/browser/terminalConfigHelper'; <del> import { DisposableStore } from 'vs/base/common/lifecycle'; </del> <ins> import { DisposableStore, IDisposable } from 'vs/base/common/lifecycle'; </ins> import { IEditorOptions } from 'vs/editor/common/config/editorOptions'; import { IShellIntegration, TerminalLocation, TerminalSettingId } from 'vs/platform/terminal/common/terminal'; import { ITerminalFont, TERMINAL_VIEW_ID } from 'vs/workbench/contrib/terminal/common/terminal';

Discussion:
run a command in the terminal, run , cursor is at the top of the buffer mentioned by we'd want it to initially be at the bottom
It would be great if there was the possibility of not changing the position of the cursor during the buffer update, preserving the position of the last access. I believe that this would help in identifying the beginning of the response of the last executed command.
Yes, the plan is to only set the initial position to be the bottom of the buffer if possible. Subsequently, we won't alter it
verify that: when you add content by running a command with or without shell integration enabled, the cursor is positioned at the bottom of the last command's output when you change the cursor position but do not change / add output, the cursor position is retained when you toggle in and out of the buffer
I'm about to merge a PR which fixes these issues. Can you pls test and confirm this is the behavior you'd want/ expect? I debated about landing the cursor on the prompt line (one line below), but don't think that would be useful.
I tested and confirmed that now the cursor always goes to the end of the accessibility buffer, regardless of the previous position. At the beginning of the tests I had the impression that the position of the cursor was affected by the size of the response of the executed command, but I could not confirm this.
what I experience on mac: focus the accessible buffer, the cursor is on the last line, move the cursor up, exit the accessible buffer, focus the accessible buffer, the cursor is above the last line where I had it focus the accessible buffer, the cursor is on the last line, exit the accessible buffer, run a command, focus the accessible buffer, the cursor is on the last line
It seems the behavior is the same in my linux environment. Every time I execute a command and access the accessible buffer, the cursor is always on the last line of the executed command response, even if before executing the command I move the cursor to another position.
This is working for me on Windows, macOS, and linux via WSL. I'm not sure why it's not working for you . Would it be possible to record a gif?

CC Note: the following issue is only found in terminal profile. Other shells may or may not have the same issue. NVDA. . . the following in the and hit enter: Shift+Tab to focus in the a11y terminal buffer. Ctrl+End key to go to the bottom of the buffer. After the last terminal content, redundant 4-5 blank lines are so users will have to press UpArrow keys multiple times to reach the last content. The redundant blanks need to be removed. Version: 1.76.0-insider (system setup) Commit: Date: 2023-02-17T22:22:55.538Z Electron: 19.1.9 Chromium: 102.0.5005.194 16.14.2 V8: 10.2.154.23-electron.0 OS: Windows_NT x64 10.0. Sandboxed: Yes
I have noticed that there are more blank lines produced when you use . I assume that this is because the a11y buffer size reflects Monaco editor size and pressing Ctrl+End key thus puts your cursor at the end of the editor buffer. This makes sense, but it would be nice if we could trim out the blank lines after the actual terminal content.
On macOS, end and cmd+end does nothing, while ctrl+end or alt+end both focus the vscode window rather than anything in the terminal (or, when screencast mode is on, they focus the screencast hint)
this is just an issue about not having empty lines in the accessible terminal buffer. Those terminal keybindings are not expected to work in the accessible buffer, but feel free to create an issue if you think they should and we can discuss
no empty lines to be seen