jiebi/CodeConvo huggingface dataset:
Code change:
private _bufferTracker: BufferContentTracker | undefined; private _bufferProvider: TerminalAccessibleBufferProvider | undefined; private _xterm: Pick<IXtermTerminal, 'shellIntegration' | 'getFont'> & { raw: Terminal } | undefined; <ins> private _onCommandExecutedShowListener: MutableDisposable<IDisposable> = new MutableDisposable(); </ins> constructor( private readonly _instance: ITerminalInstance, processManager: ITerminalProcessManager,

Related discussion:
text: Type: <bFeature Request</bCC Please consider auto-activiating accessible view in terminal when user hit enter key. In most cases, screen reader users want to open accessible view after executing command in terminal. Thus, pressing Enter key can do: the current command to terminal. Accessible View immediately. Rather than having this as the default mode, we could consider adding this as a custom user setting. VS Code version: Code - Insiders 1.85.0-insider (, 2023-11-02T09:02:24.464Z) OS version: Windows_NT x64 10.0. Modes: <!-- generated by issue reporter --
This makes sense. let us know if you have any thoughts.
I imagine this mode can boost user productivity because VSCode now sends user typing in Accessible View directly to the active terminal. If this mode is , users will experience more seamless round trip between terminal input and accessible view without having to press Alt+F2 and ESC.
To verify, enable . Run a command in the terminal. The accessible view should open.
Code change:
showCommonFindToggles?: boolean; checkImeCompletionState?: boolean; showResultCount?: boolean; <del> appendCaseSensitiveLabel?: string; appendRegexLabel?: string; appendWholeWordsLabel?: string; </del> <ins> appendCaseSensitiveActionId?: string; appendRegexActionId?: string; appendWholeWordsActionId?: string; previousMatchActionId?: string; nextMatchActionId?: string; closeWidgetActionId?: string; </ins> matchesLimit?: number; type?: 'Terminal' | 'Webview'; }

Related discussion:
text: Terminal: <img width="328" alt="image" src=""Editor: <img width="436" alt="image" src=""
Code change:
} : undefined, getRole: options.ariaProvider && options.ariaProvider.getRole ? (node) => { return options.ariaProvider!.getRole!(node.element); <del> } : undefined </del> <ins> } : () => 'treeitem' </ins> } }; }

Related discussion:
text: Currently the list sets the role of each item to be This should only be done for the Tree, not for the list. List should use . More details Tree that actually uses the list should probably pass the role as the getRole to the list it extends from. if you are busy let me know and I can look into this.
We should also verify this nicely works with NVDA, since it is part of aria 1.1 spec.
Sure, PR would be great.
Sure. Assigning to this milestone and if I do not find time might get pushed out.
To verify , turn on NVDA suggest box -make sure that the suggestions do not have "Level 1" read ath the end explorer -make sure the items have appropriate Level read at the end
Code change:
builtin unset VSCODE_INJECTION fi <del> # Disable shell integration if PROMPT_COMMAND is 2+ function calls since that is not handled. if [[ "$PROMPT_COMMAND" =~ .*(' '.*;)|(;.*' ').* ]]; then builtin unset VSCODE_SHELL_INTEGRATION builtin return fi </del> if [ -z "$VSCODE_SHELL_INTEGRATION" ]; then builtin return fi

Related discussion:
text: Issue Type: <bBug</bSet the variable to something like this: You should see something similar to the following: I'm assuming it's associated with . If I'm reading correctly, it checks for semicolons but not things like , , , etc. I understand this is probably an edge case. I was able to workaround by: creating a new function to wrap the others set to the new function VS Code version: Code 1.69.0 (, 2022-07-07T05:28:46.408Z) OS version: Darwin arm64 21.5.0 Restricted Mode: No <!-- generated by issue reporter --
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.69.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
I can confirm this bug still exists in 1.69.1, and is probably less of an edge case than you might think , as I found this issue when the terminal wouldn't start because I had powerline installed.
O
My bash (GNU bash, version 5.1.16(1)-release (x86_64-apple-darwin21.1.0)) didn't want to work with empty functions, this reproduces the problem though:
Code change:
builtin unset VSCODE_INJECTION fi <del> # Disable shell integration if PROMPT_COMMAND is 2+ function calls since that is not handled. if [[ "$PROMPT_COMMAND" =~ .*(' '.*;)|(;.*' ').* ]]; then builtin unset VSCODE_SHELL_INTEGRATION builtin return fi </del> if [ -z "$VSCODE_SHELL_INTEGRATION" ]; then builtin return fi

Related discussion:
text: Issue Type: <bBug</bwhen i enable shell integration, i get an error: my contains: VS Code version: Code - Insiders 1.66.0-insider (, 2022-03-28T07:49:37.594Z) OS version: WindowsNT x64 10.0. Restricted Mode: No Remote OS version: Linux x64 5.10.60.1-microsoft-standard-WSL2 <details<summarySystem Info</summary </details<details<summaryExtensions (11)</summaryExtensionVersion ------ better-cpp-syntax1.15.13 remote-containers0.230.0 remote-ssh0.77. remote-ssh-edit0.77. remote-wsl0.66.0 doxdocgen1.4.0 better-cpp-syntax1.15.13 cmake-tools1.10.5 cpptools1.9.7 cpptools-extension-pack1.1.0 cmake0.0.17 (2 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
looks like you set somewhere which re-writes your . Right now if we detect possible problems with unsupported formats we bail out and disable shell integration by design. To workaround this you could point your at a function and run inside the function instead, for example
Assigning to April to see if we can improve our handling here.
no. i'm not setting . ugh. testing this is a nightmare. vscode seems to keep some persistent state on the server affecting shell startup. anyway, i'd recommend testing with my exact client/server OS combo. is set by the OS to the value above, but weirdly that's not actually what's used to echo my prompt. my prompt, as set in my file is .
It might be set in your or ? VS Code sources a shell environment on startup and that gets used as the base environment for terminals. For WSL you'd need the vscode server to shutdown fully.
no, this also happens when connecting (via ssh) to a fresh CentOS7 install.
Code change:
builtin unset VSCODE_INJECTION fi <del> # Disable shell integration if PROMPT_COMMAND is 2+ function calls since that is not handled. if [[ "$PROMPT_COMMAND" =~ .*(' '.*;)|(;.*' ').* ]]; then builtin unset VSCODE_SHELL_INTEGRATION builtin return fi </del> if [ -z "$VSCODE_SHELL_INTEGRATION" ]; then builtin return fi

Related discussion:
text: <img width="965" alt="image" src="https://user-"
<img width="888" alt="Screen Shot 2022-03-31 at 17 04 04" src="https://user-"
It seems that works right on Manjaro X86_64 <img width="822" alt="image" src="https://user-"
Same here, with Arch and default As workaround I blanked the $PROMPT_COMMAND on my
Thanks for finding the , should make it easy to test against
the shell integration feature also breaks long line-wrapping in bash (happens on Ubuntu, too). the terminal wraps the line before reaching the right edge of the terminal window, and it wraps to the same line overwriting the existing ontents of that line. scrolling through line commands in the bash command history is completely broken.
Tentatively assigning to July as this gets hit with Arch's default
Code change:
} break; case 'on': <del> text += 'nn - ' + nls.localize('configuredOn', "The editor is configured to be permanently optimized for usage with a Screen Reader - you can change this by editing the setting `editor.accessibilitySupport`."); </del> <ins> text += 'nn - ' + nls.localize('configuredOn', "The editor is configured to be permanently optimized for usage with a Screen Reader - you can change this via the command `Toggle Screen Reader Accessibility Mode` or by editing the setting `editor.accessibilitySupport`"); </ins> break; case 'off': text += 'nn - ' + nls.localize('configuredOff', "The editor is configured to never be optimized for usage with a Screen Reader.");

Related discussion:
text: I got into screen reader optimized mode on Windows by using NVDA, but after closing NVDA, I don't know how to leave that mode. I tried clicking on the indicator in the taskbar, and also tried searching "accessibility" in the command palette for a command that would toggle it off. !
clicking on the indicator in the taskbar should work we should also have a toggle command in the command palette so that clicking isn't required and can reference that command in this help menu !
fyi for any input
Agree with the above. Also on vscode restart you should no longer be in screen reader mode if that is happening, it is a bug. take into account that the accessibility help dialog shown in the screenshot has not been polished since we introduced it. We could make sure the text is more concise and user friendly. Visually it should not be polished since this is targeted for screen reader users.
Try to set a custom keybinding for this command - I find it very handy
How do I get that status bar entry to show? I tried the following: Turn on NVDA when Manually set `"editor.accessibilitySupport": "on"
This command should work !
That still doesn't cause the status bar entry to show for me. I've checked the status bar show/hide menu and it's not in there either.
any interesting settings? https://user-
I was about to say I have the same issue, but then noticed that I had to go to a text editor to test out the feature. I was running the toggle command in the Settings editor.
Not being in a text editor was the problem! I was either in the settings editor or the endgame notebook.
Code change:
this.historyMainService.updateWindowsJumpList(); this.historyMainService.onRecentlyOpenedChange(() => this.historyMainService.updateWindowsJumpList()); <del> // Start shared process here this.sharedProcess.spawn(); </del> <ins> // Start shared process after a while TPromise.timeout(3000).then(() => this.sharedProcess.spawn()); </ins> } private dispose(): void {

Related discussion:
text: See I have had to revert our commit via
Issue could reoccur if shared process start up is delayed.
What was the problem with ? As far as I can see from the code, every client to the shared process should wait for it to be running. . If this assumption holds, change was correct. Do you have any suggestion as to until when to delay the spawn?
Yeah it would be great if the workbench could signal back some event when editors are restoring, but we currently do not have that. Who is waiting for the shared process to be ready, is it just telemetry and extensions management? We have to be careful to not introduce another deadlock area...
Hmm it ain't the services themselves who wait but the container of them. AFAIK, both the and the wait for the shared process to start.
the workbench does not really wait right, it just runs that code in parallel to the rest of the workbench loading.
The workbench will show. But every call to a shared process service will wait until the shared process has started serving the socket. For example, extensions won't show up in the viewlet until the shared process appears.
It was a guess from analysis and also from testing/verification that removing the delay fixed the dialog issue. I do not think we have a concrete reason why is it depending on the delay.
OK. So it seems we can easily delay it. Can you find a signal in the main process at which point we should spawn it?
somewhere in  possibly with some delay? Alternatively the call to opening a window () returns the opened windows and there is a  promise you could join on. That one is literally resolved when all editors have restored in VS Code.
But the shared process already starts only . Should we just put a timeout then? That would make this change exactly what did last month. I'm not saying it's wrong, just stating the fact. Edit: Actually... his change looks very weird to me now. It seems to delay the connection to the process, not the actual spawning.
yes I think what should get delayed is the creation and opening of the shared process window.
Just note that I have removed the uninstall dialog last milestone. So this might not be an issue any more.
Code change:
} .settings-editor > .settings-header > .settings-header-controls .settings-tabs-widget .action-label.checked { <del> font-weight: 500; </del> opacity: 1; }

Related discussion:
text: Issue Type: <bBug</bWith at least one folder loaded in Code: to Code Preferences Settings on either "User Settings" or "Workspace Settings" Notice tab spacing is jumpy when changing active selection. It should NOT be as jumpy. I believe it's caused by the text being bolded on active selection. <iDesired</i! <iActual</i! VS Code version: Code 1.28.2 (, 2018-10-17T00:18:43.347Z) OS version: Darwin x64 18.0.0 <details<summarySystem Info</summary </details<!-- generated by issue reporter --
Here's the
I'm not sure about this change, I think the bold is necessary to make the selected tab noticeable. Some themes hide the underline on the selected item, and in some themes, the color difference is not really noticeable. So I would worry that this would make it impossible to tell which tab is selected. I also don't really have an issue with the slight shifting, I've never noticed it before now.
We should try to remove this shift as it's not really smooth. In our other tabs (panels, settings json) we don't use alternate font-weights for active/inactive, so I think we should keep them consistent and the same. Alternatively, if we really want to make the states look different we could adjust the opacity (just like the other tabs) as long as they pass the color contrast ratio: !
I agree that it's not smooth. It's also not consistent with the other tabs in the product. There is a hack that can remove the shifting (discussed with this ), however I think that might be overdoing it to achieve this effect. I would add the opacity change as well to help reinforce the two states.
Should I just borrow the inactive color from the panel tabs, at least for the builtin themes? Or if I should use opacity, can you tell me what color/opacity to use? Looking through some popular ones, I don't think this change would be a problem for that many other themes really... Also for folder settings, the folder name and string "Folder Settings" are currently distinguished by size and color, so we might still need 3 colors.
Actually the current panel tab colors in Monokai don't meet the contrast requirement: ! !
Code change:
} .settings-editor > .settings-header > .settings-header-controls .settings-tabs-widget .action-label.checked { <del> font-weight: 500; </del> opacity: 1; }

Related discussion:
text: We only need to meet the color contrast on the themes we own, which is light/dark/hc. Here's the contrast on the inactive text: Here's the colors and opacity for the active/inactive panels: For the folder settings, you can change the opacity to (which passes) and will end up looking like this: !
Not using the panel foreground color because the background is not always the same, but I think it looks good as is after the PR.
Code change:
#	fi #fi <ins> # Update mimetype database to pickup workspace mimetype update-mime-database /usr/share/mime &> /dev/null || : </ins> %postun if [ $1 = 0 ]; then rm -f /usr/bin/@@NAME@@ fi <ins> # Update mimetype database for removed workspace mimetype update-mime-database /usr/share/mime &> /dev/null || : </ins> %files %defattr(-,root,root) /usr/share/@@NAME@@/ /usr/share/applications/@@NAME@@.desktop /usr/share/applications/@@NAME@@-url-handler.desktop <ins> /usr/share/mime/packages/@@NAME-workspace.xml </ins> /usr/share/pixmaps/@@ICON@@.png /usr/share/bash-completion/completions/@@NAME@@ /usr/share/zsh/site-functions/_@@NAME@@

Related discussion:
text: A Visual Studio Code workspace file is currently recognised in Linux as a normal plain text file. This is because there isn't a MIME type for this file. Applications can provide additional MIME types as described here: Not having a MIME type has a couple of issues, for example the files are shown as plain text files in the GUI, which makes it hard to distinguish source code files from the workspace file. This slows down navigating to a workspace and opening it. Find the workspace in the following screenshot ! It's currently impossible to theme such a file because it's not seen as a different MIME type:
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.461 --<!-- potentialduplicatescomment --
This also means that you can't make double clicking the workspace from a file browser open it in vscode, unless you're OK with all text files opening in vscode, which is probably not what most folks want.
This bug has been fixed in to the latest release of ! you can help us out by confirming things are working as expected in the latest Insiders release. If things look good, please leave a comment with the text to let us know. If not, please ensure you're on version of Insiders (today's or later - you can use in the command pallete to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Hi can you verify this issue? Check out the previous comment.
I tried to verify this but am not sure how to do this myself. I've not used desktop linux extensively; I tried reinstalling Insiders from the on Lubuntu to see if it associated files with VS Code, but that didn't happen.
Verified by installing insiders from on Ubuntu and was able to see mimetype and set a custom icon ! upon uninstalling it was removed.
Code change:
return; } <ins> // Hide sticky scroll if the prompt has been trimmed from the buffer if (command.promptStartMarker?.line === -1) { this._setVisible(false); return; } </ins> // Determine sticky scroll line count const buffer = xterm.buffer.active; const promptRowCount = command.getPromptRowCount();

Related discussion:
text: Repro: terminal with sticky scroll enabled command that "overflows screen" (ie, it scroll terminal beyond what's visible) it once again to again overflow screen (not sure if it needs to be run again, but that's how I repro'ed) screen (ctrl+l) once again & see sticky scroll shown even though not required (also reported with vid and logs in DM to ) Version: 1.85.0-insider Commit: Date: 2023-11-29T02:45:05.413Z Electron: 25.9.6 ElectronBuildId: Chromium: 114.0.5735.289 18.15.0 V8: 11.4.183.29-electron.0 OS: Darwin arm64 23.1.0
Code change:
.quick-input-list .monaco-list { overflow: hidden; max-height: calc(20 * 22px); <ins> padding-bottom: 5px; </ins> } .quick-input-list .monaco-scrollable-element {

Related discussion:
text: ! !
I think this was the result of moving the progress bar below the input. Since the progress bar use to provide the padding.
let's just call it an exploration of compact mode :) /s
This is partially as designed, but it still needs improvement. The latest changes make it so we have a nice cutoff when the quick pick list is scrolling: <img width="653" alt="CleanShot 2022-12-16 at 09 23 10 src="https://user-"However it should probably still use padding at the bottom of the list, rather than the container, to ensure this doesn't happen when the entire list is visible/not scrollable.
I dont want to be the annoying guy at the party here, but an empty quick pick now looks like this: <img width="647" alt="image" src="https://user-"vs before <img width="633" alt="image" src="https://user-"
Haha, whoops. I'll have another go at this then.
verified the original issue here, but we'll continue the next issue in:
Code change:
{ "name": "code-oss-dev", "version": "1.84.0", <del> "distro": "ace645d011b7e53ba51e8d5ff153c47e3773b3d8", </del> <ins> "distro": "0f218422a902175f8b82cbf0f13fa4feb278f22a", </ins> "author": { "name": "Microsoft Corporation" },

Related discussion:
text: Type: <bBug</bThis issue is related to the Julia extension. I filed an issue , but I also filing it here (as suggested by As per the initial post of the above link, all extension work perfectly fine when the Julia extension is disabled. here are dmp files as per VS Code version: Code 1.79.2 (, 2023-06-14T08:57:04.379Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (50)</summaryExtensionVersion ------ rainbow-brackets0.0.6 vscode-django1.10.0 python-environment-manager1.0.4 python-extension-pack1.7.0 code-runner0.12.0 copilot1.94.220 vscode-github-actions0.25.8 vscode-pull-request-github0.66.2 nbpreviewer1.2.2 language-julia1.47.2 vsc-python-indent1.18.0 vscode-github0.30.7 vscode-opn1.1.2 MagicPython1.1.0 vscode-azureappservice0.24.9 vscode-azureresourcegroups0.7.5 vscode-docker1.25.2 csharp1.26.0 isort2022.8.0 python2023.10.1 vscode-pylance2023.6.40 jupyter2023.5.
Code change:
{ "name": "code-oss-dev", "version": "1.84.0", <del> "distro": "ace645d011b7e53ba51e8d5ff153c47e3773b3d8", </del> <ins> "distro": "0f218422a902175f8b82cbf0f13fa4feb278f22a", </ins> "author": { "name": "Microsoft Corporation" },

Related discussion:
text: jupyter-keymap1.1.2 jupyter-renderers1.0.15 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.295.0 remote-ssh0.102.0 remote-ssh-edit0.86.0 remote-wsl0.79.5 vscode-remote-extensionpack0.24.0 azure-account0.11.5 cmake-tools1.14.34 cpptools1.16.3 cpptools-extension-pack1.3.0 powershell2023.6.0 remote-explorer0.4.0 remote-server1.2.1 autodocstring0.6.1 r-debugger0.5.4 r2.8.1 vscode-open0.1.0 spellchecker1.4.0 python0.2.3 rmarkdown0.0.14 cmake0.0.17 vscode-counter3.2.1 intellicode-api-usage-examples0.2.7 vscodeintellicode1.2.30 jinja0.0.8 (2 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
As mentioned in the linked issue, it happens for me as well. I can reproduce it with Insiders version too and the same happens with a few older julia-vscode extensions I tested. <details<summaryVS Code version</summary</details
There seems to be an issue with spawning a process. The symbolicated logs seem to have the same form.
I'd expect that this happens when we try to spawn the Julia process that powers the LS. Any chance we can debug this further? I assume we can't handle libuv failing to spawn a process anywhere in the extension code, right?
As asked in the I want to add that I can reproduce this as well. From the linked thread:
Sorry for the delayed response, can you please provide the output of the following steps to understand the error 1) In a terminal set the following env variable 2) Launch VSCode from the same terminal session with arguments that redirect stdout and stderr to a file as seen below, replace the file paths where appropriate Additionally, once the extension host crashes open command palette in VSCode and run and attach the output from the tab of the developer tools that got opened.