Code change:
Type: <bBug</bCC: I noticed that I can't navigate the accessible buffer using ctrl left arrow or ctrl+right arrow. When using this combination orca treats the whole line as if it were a single word. Except for misunderstandings, this happens because the blank spaces present in the accessible buffer are being replaced by the character 0xa0. I ran the command echo "this is test" in the VSCode terminal and ran the same command in the gnome terminal. Browsing character by character with orca I noticed that in the gnome terminal space appears as 0x20 and in the accessible buffer it appears as 0xa0. VS Code version: Code - Insiders 1.79.0-insider (, 2023-05-04T22:12:16.054Z) OS version: Linux x64 6.2.14-300.fc38.x8664 Modes: Sandboxed: Yes Remote OS version: Linux x64 4.14.146-93.123.amzn1.x8664 <details<summarySystem Info</summary </details<details<summaryExtensions (44)</summaryExtensionVersion ------ doxdocgen1.4.0 vscode-markdownlint0.50.0 vscode-eslint2.4.0 EditorConfig0.16.4 copilot1.86.82 rest-client0.25.1 better-cpp-syntax1.17.2 docomment1.0.0 azure-pipelines1.208.0 vscode-docker1.25.0 csharp1.25.7 vscode-dotnet-runtime1.6.0 vscode-kubernetes-tools1.3.11 remote-containers0.293.0 remote-ssh0.101. remote-ssh-edit0.84.0 azure-account0.11.4 azurecli0.5.0 cmake-tools1.14.31 cpptools1.15.4 cpptools-extension-pack1.3.0 makefile-tools0.7.0 powershell2023.5.0 remote-explorer0.5. vsliveshare1.0.5864 oracledevtools21.5.0 fabric8-analytics0.3.6 java1.19. vscode-xml0.25. vscode-yaml1.12.2 sonarlint-vscode3.17.0 cmake0.0.17 intellicode-api-usage-examples0.2.7 vscodeintellicode1.2.30 vscode-boot-dev-pack0.2.1 vscode-spring-boot1.46.0 vscode-java-debug0.50. vscode-java-dependency0.22. vscode-java-pack0.25. vscode-java-test0.38. vscode-maven0.41. vscode-spring-boot-dashboard0.13.0 vscode-spring-initializr0.11.2 gitblame10.2.0 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
We replace these spaces intentionally, but I'm not sure why . thoughts?
As it is, I can't use orca to select words and I can't navigate by words either.
We replace it with a non-breaking space such that white space appears the same as it would in the terminal. I wasn't aware it has this impact on screen readers (maybe it's just orca?) but we could workaround it by replacing (2 spaces) with . That should keep tables, ls, etc. aligned while fixing the problem at hand. It seems like an Orca issue though as I'm pretty sure a non-breaking space should be getting treated as a space.
I also think this should be corrected on the Orca side because the same problem also exists when I'm editing a file. I can't navigate through words in a text when they are separated by the 0x0 character." Reported this issue on the Orca mailing list.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
This doesn't appear to be fixed: ! ! It is changing multiple lines to include a single space character as expected, but see the first line where single spaces are changed. I'm questioning the fix we came up with though, monaco replaces spaces anyway in the editor: ! I think we should revert this and have orca fix it, instead of trying to workaround their problem which could end up causing other issues for us?
I ended up reporting this problem to the orca developers because the problem also exists when I'm editing a file that has words separated by the character 0xa0. I believe the problem will be dealt with on the orca side.
If I understand what reported correctly, I don't think this is an Orca issue. When Orca is in focus mode, it does not control or consume input events. In other words, Ctrl+Right/Left arrow will do whatever they would do without Orca running. And from some testing, when the words are separated by 0xa0, VS Code (or Chromium) is treating the string as a single word. If, in those same places, I switch Orca to browse mode, Orca IS controlling/consuming the input events, and it already does treat the string as individual words. But if I'm missing something, please let me know what I should be fixing in Orca. Thanks!
Here are the steps I am using to reproduce the problem which I believe is reporting: sure Orca is NOT running. a new document. "This" Ctrl+Shift+U "00a0" followed by return to insert a non-breaking space character "is" steps 4 and 5. "a" steps 4 and 5. "test." Home to move to the beginning of the line. Ctrl+Right to move to the next word. Expected results: The caret would move just past the "s" of "This". Actual results: The caret immediately jumps to the "." at the end of the sentence.
thanks for the follow up, you're right. we should not be replacing it with non-breaking spaces as monaco handles their presentation. When you paste in the characters like describes (I did it by running 'u00a0' in console and copying that) you can see they're treated specially, we also have a lint rule to prevent this in vscode: !

Related discussion:
text: test('should cap the size of the cached lines, removing old lines in favor of new lines', async () => { const content = `${prompt}rn`.repeat(1036).trimEnd(); await writeP(xterm.raw, content); <del> await bufferTracker.update(); const expected = content.split('rn').map(s => replaceWithNonBreakingSpaces(s)); </del> <ins> bufferTracker.update(); const expected = content.split('rn'); </ins> // delete the 6 lines that should be trimmed for (let i = 0; i < 6; i++) { expected.pop(); } // insert a new character await writeP(xterm.raw, 'x1b[2Ainsertion'); <del> await bufferTracker.update(); </del> <ins> bufferTracker.update(); </ins> expected[1027] = `${prompt}insertion`; assert.strictEqual(bufferTracker.lines.length, expected.length); assert.deepStrictEqual(bufferTracker.lines, expected);