jiebi/CodeConvo huggingface dataset:
Code change:
original: 'Terminal', mnemonicTitle: localize({ key: 'mTerminal', comment: ['&& denotes a mnemonic'] }, "&&Terminal") }, <del> order: 7, when: ContextKeyExpr.has('terminalProcessSupported') </del> <ins> order: 7 </ins> }); MenuRegistry.appendMenuItem(MenuId.MenubarMainMenu, {

Related discussion:
text: In the recent Edit Sessions UX study we ran, we saw several participants searching in vain for the terminal item in the compact menu on , sometimes for minutes: ! Could we consider bringing it back? I'm guessing we intentionally suppressed it because terminals can't run in the web, but participants were simply confused that it wasn't there without connecting its absence to the fact that was a browser application. Additionally, RemoteHub contributes a welcome view for the terminal which is one of the primary ways we explain that users must continue working elsewhere to run or debug code, and the fact that the terminal is completely suppressed means one less opportunity for users to organically learn the limitations of through our welcome views. ! cc
Yes that is why it was removed. It doesn't do much but if it helps reduce confusion I guess it's worth it?
Not against the idea of having the terminal menu in web but in its current form it's useless and doesn't allow me to actually show a terminal pane, it just deadends all over https://user-
Reverting in
when I enable the menu again and fix up the terminal command, the run/customize task items give this on the scripts/code-web sample-folder: <img width="1229" alt="image" src="https://user-"That does actually run, not sure what it's doing exactly though. Is that a custom execution task running in the web worker ext host? If so you might need a context key on those menu items to only show them when a custom execution task is registered?
Unless I'm missing something, I believe only registered tasks will show there - if they're running when you select them, then I don't think there's an issue.
I think there's a built-in fake task when running code-web is what I mean, when run in actual then running it might do nothing. In that case it should hide similar to how we're changing the behavior of New Terminal depending on whether extension contributed profiles exist
Code change:
{ "name": "code-oss-dev", "version": "1.84.0", <del> "distro": "7df09ac7212a2c85067c0e2ef8c1ec89686483d2", </del> <ins> "distro": "7c11ebfa20a4556137f851c95af40923aae11a3d", </ins> "author": { "name": "Microsoft Corporation" },

Related discussion:
text: I wonder if this could be a 18 issue? //cc
Yes , this is addressed in Node v20 and we have also backported the fix to Electron in However, we haven't backported the fix to but we can.
Code change:
} updateCommentThread(commentThread: languages.CommentThread<T>) { <del> if (this._commentThread !== commentThread) { dispose(this._commentThreadDisposables); } </del> this._commentThread = commentThread; <ins> dispose(this._commentThreadDisposables); </ins> this._commentThreadDisposables = []; this._bindCommentThreadListeners();

Related discussion:
text: have an eager comments controller extension (see below) open a notebook create a new cell leak warnings are printed
This seems to be rooted at  It looks like a new is created without always disposing the old one. The looks highly suspicious. <img width="1586" alt="Screenshot 2022-10-26 at 14 09 41" src="https://user-"
Suggesting to tackle this for October because after a short while VS Code was crawling due to excessive listening
thanks for good reproduce. The comment thread equality check is wrong, it's an oversight during refactoring iirc. I pushed a fix for this memory leak. Though with it fixed, I found there are issues with "Editing" state of comment thread for cells (focus issue), will look into this next week.
Thanks
Code change:
"editorGutter.addedBackground": "#2ea043", "editorGutter.deletedBackground": "#f85149", "editorGutter.modifiedBackground": "#0078d4", <del> "editorInlayHint.background": "#8b949e33", "editorInlayHint.foreground": "#8b949e", "editorInlayHint.typeBackground": "#8b949e33", "editorInlayHint.typeForeground": "#8b949e", </del> <ins> "editorInlayHint.background": "#8b949e1b", "editorInlayHint.typeBackground": "#8b949e1b", </ins> "editorLineNumber.activeForeground": "#cccccc", "editorLineNumber.foreground": "#6e7681", "editorOverviewRuler.border": "#010409",

Related discussion:
text: I heavily use and love inlay hints but find their current styling too prominent for "hints" and think it harms readability and other editor features that use highlighting of words such as "highlight occurrences." Try finding highlighted occurrence of : Current: <img width="1779" alt="Screenshot 2023-06-29 at 11 51 00" src=""With less prominent hints: <img width="1779" alt="Screenshot 2023-06-29 at 11 47 31" src=""I think in the latter screenshot, inlay hints are less prominent but still as useful, as they are literally "hints" and don't need to be so prominent. If not as default, having a setting to tweak the background & color of hints would be great.
I think I've read a similar issue recently (should have the inlay-hint label).
Can be configured via and leaving it up to to tweak this further.
Updatde the default light/dark themes in to make these more subtle. Still want to keep the backgrounds since these could otherwise be confused with the ghost text in Copilot, comments in some themes, etc. <img width="422" alt="CleanShot 2023-06-29 at 11 23 35 src=""<img width="430" alt="CleanShot 2023-06-29 at 11 22 43 src=""
Code change:
*--------------------------------------------------------------------------------------------*/ import * as assert from 'assert'; <del> import { Emitter } from 'vs/base/common/event'; </del> <ins> import { Emitter, Event } from 'vs/base/common/event'; </ins> import { DisposableStore } from 'vs/base/common/lifecycle'; import { ResourceMap } from 'vs/base/common/map'; import { waitForState } from 'vs/base/common/observable';

Related discussion:
text: There are some parts in notebook land that depend on . This service and its provider are deprecated and should be removed. As of today the following dependencies must be cleaned up first: , , The should be used instead, it will allow you to know if a agent per location exists or not
Code change:
commandsToSkipShell: string[]; cwd: string; confirmOnExit: boolean; <ins> env: { linux: { [key: string]: string }; osx: { [key: string]: string }; windows: { [key: string]: string }; }; </ins> } export interface ITerminalConfigHelper {

Related discussion:
text: VSCode Version: 1.7.1 OS Version: Win 10 Pro Add an option to set environment variables before starting the terminal. Something like: Or maybe you want to split variable and value something like: Obviously the same goes for Linux and Mac
I'm curious what your use case is for wanting this in VS Code but not in Windows?
Here are some use cases (first two from personal experience): Different paths to libs per workbench Test your application with different languages/translations. It would also have made a much better work-around for You just don't want to set set the right vars every time you open a terminal.
! how should i fix this problem
If you are asking because I mentioned in my previous comment, I have no idea about that issue. That one is not my bug report. I just ran into that issue when I was searching around if the request I wanted to submit was not a dup.
Its not hard to see in the Python context an app needing a specific PYTHON_PATH, and other languages needing class paths/library paths. My thoughts here is that the tasks may be the workaround - a task can have associated env vars - and a make/rake/grunt/gulp/fabfile or something could be used to set it all up for your project.
I would love to see that too. For me it's about setting workspace env variables to be used with node gyp. Like OPENCV location
How does one configure this on the Insiders build?
It will be in the next build of Insiders, you will be able to use the new settings:
I can confirm that it works great for me, i now use it in almost all my projects Thanks!
UPDATE Again: Just found :man_facepalming: ! UPDATE: DOH! I just realized . God I love this editor! Amazing job. Is there any way to make this project specific? I am using this now for GOPATH but would love if it changed to the current working directory, which the integrated terminal seems to be aware of when it starts up. Maybe there is a variable I could set the envs to that contains the same value used by the starting terminal.
Anything in is already specific to the root folder that is open in VS Code. This is called the Workspace settings.
how to specify the GOPATH env variable inside the integrated terminal to be the same as the one inside your ?
Code change:
commandsToSkipShell: string[]; cwd: string; confirmOnExit: boolean; <ins> env: { linux: { [key: string]: string }; osx: { [key: string]: string }; windows: { [key: string]: string }; }; </ins> } export interface ITerminalConfigHelper {

Related discussion:
text: I am trying this on 1.17.1 and does not seem to work:
Thanks but in my case the following is what I'm after, but doesn't seem to be working. The use of the variable seems to work fine because it stops the underlined errors in code related to gopath, but the env var on the terminal still is bork. I'm mostly good because I also setup an install task that works. Now if I could only get that to like the libraries do correctly so things would compile automatically on changes (which I realize many would not like). ! By the way, here is an (old) task that works. But, it is interesting that everyone has different variable names for the same thing (workspaceFolder v.s. workspaceRoot): !
You are using in the env var for the which doesnt get resolved. Should we add resolution of such variables when using the setting? For vs see
Resolving variables in the setting is tracked in
After upgrading from 1.17 to 1.18, the setting doesn't work anymore (OS Version: OSX High Sierra) version 1.18: <img width="1064" alt="screen shot 2017-11-15 at 10 12 25" src="https://user-"version 1.17: <img width="442" alt="screen shot 2017-11-15 at 10 16 13" src="https://user-"
Just tried on my Mac, it works as expected. One thing to keep in mind is that the env vars will not affect terminals that were created before the env vars were to the setting. Can you create a new terminal and check there?
it was indeed on a new terminal after the env was . I've retried it on two high sierra machines recently.
I tried on a co-worker's high sierra machine. Works there as well. Can you try on our Insiders? Can you try with extensions disabled?
Code change:
__vsc_prompt_cmd_original() { __vsc_status="$?" <ins> builtin local cmd </ins> __vsc_restore_exit_code "${__vsc_status}" # Evaluate the original PROMPT_COMMAND similarly to how bash would normally # See https://unix.stackexchange.com/a/672843 for technique <del> builtin local cmd </del> for cmd in "${__vsc_original_prompt_command[@]}"; do eval "${cmd:-}" done

Related discussion:
text: Type: <bBug</bThe issue shows up if I have a custom PS1 prompt that looks at the exit code of the previous command (using ). Here's a minimal configuration in the .bashrc file on my remote Linux host: Expected results: When I run in a terminal outside vscode or disable automatic script injection in the integrated terminal, I get this: Actual results: when I enable integrated terminal shell injection, I instead see this output running the same commands: That is, the exit code is now always 0. I tried manually injecting the scripts using the command from ; no change in behavior. Looking at the script that gets loaded (.../server/out/vs/workbench/contrib/terminal/browser/media/shellIntegration-), I see these lines: As an experiment, I tried moving the call later and opening a new terminal, which fixed the issue for me: So it looks like the step that clobbers the exit code is the step. Remote OS: RHEL 8.10, bash 4.4.20 VS Code version: Code 1.91.0 (, 2024-07-01T18:52:22.949Z) OS version: WindowsNT x64 10.0. Modes: Remote OS version: Linux x64 4.18.0-553.5.1.el810.x8664 Remote OS version: Linux x64 4.18.0-553.5.1.el810.x8664 Remote OS version: Linux x64 4.18.0-553.5.1.el810.x86_64 <details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
In VS Code version 1.92.0, I still see this issue. In this version I now see that the method calls instead of just , but running this after the function still clobbers out the return code to zero. says this about running :
Code change:
}); }); <del> suite('image-caching', () => { </del> <ins> suite.only('image-caching', () => { </ins> const input = '![](img.png) [](no-img.png) ![](http://example.org/img.png) ![](img.png) ![](./img2.png)'; test('Extracts all images', async () => { const engine = createNewMarkdownEngine(); <del> assert.deepStrictEqual((await engine.render(input)), { html: '<p data-line="0" class="code-line" dir="auto">' + '<img src="img.png" alt="" class="loading" id="image-hash--754511435" data-src="img.png"> ' + '<a href="no-img.png" data-href="no-img.png"></a> ' + '<img src="http://example.org/img.png" alt="" class="loading" id="image-hash--1903814170" data-src="http://example.org/img.png"> ' + '<img src="img.png" alt="" class="loading" id="image-hash--754511435" data-src="img.png"> ' + '<img src="./img2.png" alt="" class="loading" id="image-hash-265238964" data-src="./img2.png">' + '</p>n' , containingImages: [{ src: 'img.png' }, { src: 'http://example.org/img.png' }, { src: 'img.png' }, { src: './img2.png' }], }); </del> <ins> const result = await engine.render(input); assert.deepStrictEqual(result.html, '<p data-line="0" class="code-line" dir="auto">' + '<img src="img.png" alt="" data-src="img.png"> ' + '<a href="no-img.png" data-href="no-img.png"></a> ' + '<img src="http://example.org/img.png" alt="" data-src="http://example.org/img.png"> ' + '<img src="img.png" alt="" data-src="img.png"> ' + '<img src="./img2.png" alt="" data-src="./img2.png">' + '</p>n' ); assert.deepStrictEqual([...result.containingImages], ['img.png', 'http://example.org/img.png', './img2.png']); </ins> }); }); });

Related discussion:
text: <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.68.1 OS Version: Windows 10 Steps to Reproduce: a Markdown file and open "Open Preview to the Side" add line: ! image in preview second line: ! second image shows up. Remove the line above image preview shows 2 images and does not update properly !
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.68.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Still happens in 1.68.1. Updating bug
Does this reproduce in the with all ?
Yes still happens with all extensions disabled
Code change:
if (configuration.enableTsServerTracing && !isWeb()) { tsServerTraceDirectory = this._logDirectoryProvider.getNewLogDirectory(); if (tsServerTraceDirectory) { <del> args.push('--traceDirectory', tsServerTraceDirectory.path); </del> <ins> args.push('--traceDirectory', tsServerTraceDirectory.fsPath); </ins> } }

Related discussion:
text: Type: <bBug</btypescript server keeps crashing after the latest update VSCODE ! I can reproduce this with all the extensions disabled. LOG: ! VS Code version: Code - Insiders 1.76.0-insider (, 2023-02-03T05:23:17.202Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: Yes <details<summarySystem Info</summary </details<details<summaryExtensions (11)</summaryExtensionVersion ------ ng-template15.1.0 atlascode3.0.1 vscode-markdownlint0.49.0 vscode-eslint2.2.6 githistory0.6.19 gitlens13.2.0 prettier-vscode9.10.4 vscode-yaml1.11.0 sonarlint-vscode3.14.0 code-spell-checker2.16.0 vscode-stylelint1.2.3 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Please try collecting the TS Server log from the crashed instance: VS Code and reproduce the problem the section of the output panel the very top, find the first line that prints to path to the semantic error log file. It should look something like: That file contains the typescript logs. Look through that log file for the first error or stack trace you see. If you can share the log, I can also take a look to see if anything stands out
, for some reason the log file location is shown as [Object object] (as pointed out by the pink arrow), I checked in the folder pointed out by the red arrow and the folder is empty. ! I have checked this for multiple folder I could see in the log prompt but all of them are empty.
a Microsoft member created same/duplicate issue , in case this could help with the debugging
Confirming that I also see when using verbose setting and all the log files are empty for me, which is also noted and shown on microsoft/vscode.
For me the directory under the object object is also empty, is that the case with you?
Yes, same.
should be fixed in the next insider release: microsoft/vscode
the object object issue is resolved, however, the file pointed by the log still does not exist. can you give it a try if you can see the logs?
Code change:
if (configuration.enableTsServerTracing && !isWeb()) { tsServerTraceDirectory = this._logDirectoryProvider.getNewLogDirectory(); if (tsServerTraceDirectory) { <del> args.push('--traceDirectory', tsServerTraceDirectory.path); </del> <ins> args.push('--traceDirectory', tsServerTraceDirectory.fsPath); </ins> } }

Related discussion:
text: i did some commenting in the file and found that commenting out setting stops the repeated crash. Note: I am not sure why I have /enabled this setting in the first place.
Oh wow, exactly the same for me. I also do not remember ever setting , but it was in my and removing it fixes the crash for me too!
Also confirming that with latest update is fixed but log directories are still empty. I've closed my bug as a duplicate of this one since it's pretty clear these are the same issue now. Are you able to repro using is Also do you know if this would ever have been set on user's behalf, which could impact the severity here if lots of people would have this in their settings?
Thanks and I can confirm that enabling cause the server to crash on windows. Oddly I don't see it on Mac. The server is likely crashing before logging can start too, which is why the log files don't exist I'm not sure how this setting got enabled for you. It's only meant for detailed performance investigations and should never be turned on automatically
Yay, thank you and
Code change:
if (platform === 'win32' && await exists(path.join(rootPath!, 'node_modules', '.bin', 'gulp.cmd'))) { const globalGulp = path.join(process.env.APPDATA ? process.env.APPDATA : '', 'npm', 'gulp.cmd'); if (await exists(globalGulp)) { <del> gulpCommand = globalGulp; </del> <ins> gulpCommand = '"' + globalGulp + '"'; </ins> } else { gulpCommand = path.join('.', 'node_modules', '.bin', 'gulp.cmd'); }

Related discussion:
text: <!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.31.0 OS Version: Windows 10 Steps to Reproduce: a system with user home containing a space some gulp task configured you will have: <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No I think it was introduced by this commit: it is now using a global gulp which is installed in user home instead of local one. The command has never escaped space in path though
Thank you for catching this! The fix will be available in the next Insiders build.
Why are you looking in now, was that on purpose?
Ah that was already fixed
Code change:
this.loadedScriptsItemType = CONTEXT_LOADED_SCRIPTS_ITEM_TYPE.bindTo(contextKeyService); } <ins> @memoize private get treeRefreshScheduler(): RunOnceScheduler { return new RunOnceScheduler(() => { if (this.tree) { this.tree.refresh(undefined, this.shouldRefreshRecursive); this.shouldRefreshRecursive = false; } }, 300); } </ins> protected renderBody(container: HTMLElement): void { dom.addClass(container, 'debug-loaded-scripts');

Related discussion:
text: debugging the loaded scripts view open debugging, notice exception in the console can not reproduce with Stable so it might be that my listener refactoring caused this If you pause on exception you will see that caused it.
did you have a chance to look into this? Or would you like me to investigate? I suspect this is breaking the loaded scripts view and is the root cause for
no, please investigate since this and was working before, and I haven't touched this code for two weeks.
end session events are not arriving in As a consequence the tree for the session is not properly removed.
I see something differnetly, the end sessions are arriving however when the last session end arrives view starts refreshing the tree and while that is in progress the view gets disposed which throws an exception. Looking into a fix...
I have created a PR which address this issue
Code change:
import { ViewContainerLocation } from 'vs/workbench/common/views'; import { OPEN_TO_SIDE_COMMAND_ID, COMPARE_WITH_SAVED_COMMAND_ID, SELECT_FOR_COMPARE_COMMAND_ID, ResourceSelectedForCompareContext, COMPARE_SELECTED_COMMAND_ID, COMPARE_RESOURCE_COMMAND_ID, COPY_PATH_COMMAND_ID, COPY_RELATIVE_PATH_COMMAND_ID, REVEAL_IN_EXPLORER_COMMAND_ID, OPEN_WITH_EXPLORER_COMMAND_ID, SAVE_FILE_COMMAND_ID, SAVE_FILE_WITHOUT_FORMATTING_COMMAND_ID, SAVE_FILE_AS_COMMAND_ID, SAVE_ALL_COMMAND_ID, SAVE_ALL_IN_GROUP_COMMAND_ID, SAVE_FILES_COMMAND_ID, REVERT_FILE_COMMAND_ID, REMOVE_ROOT_FOLDER_COMMAND_ID, PREVIOUS_COMPRESSED_FOLDER, NEXT_COMPRESSED_FOLDER, FIRST_COMPRESSED_FOLDER, LAST_COMPRESSED_FOLDER, NEW_UNTITLED_FILE_COMMAND_ID, NEW_UNTITLED_FILE_LABEL, NEW_FILE_COMMAND_ID } from './fileConstants'; import { IFileDialogService } from 'vs/platform/dialogs/common/dialogs'; <ins> import { RemoveRootFolderAction } from 'vs/workbench/browser/actions/workspaceActions'; </ins> export const openWindowCommand = (accessor: ServicesAccessor, toOpen: IWindowOpenable[], options?: IOpenWindowOptions) => { if (Array.isArray(toOpen)) {

Related discussion:
text: Steps: multi root workspace with 2-3 folders right click into empty space below last folder select "Remove Folder from Workspace" nothing happens //cc
I guess this should remove the last workspace folder.
Not sure, if you invoke this command from F1 list, you get a picker asking which folder to remove. We could do the same here.
Sometimes the empty area takes the last workspace folder as context and sometimes not. So we should be consistent and check what other actions do on the empty area. Maybe the only exception is actually drag and drop, which on drop on empty area drops to the last workspace folder.
! context menu of empty area should be something like this.
! and also change this icons when there is no folder selected.
works fine, but "Open Folder Settings" does not bring up a picker, should it?
Code change:
} }); <ins> // Hide when the window loses focus this._register(dom.addDisposableListener(window, 'blur', () => this.dispose())); </ins> const rowElement = $('div.hover-row.markdown-hover'); const contentsElement = $('div.hover-contents'); if (typeof options.content === 'string') {

Related discussion:
text: On Windows: something with a rich hover in a tree view, like an extension or an item in the activity bar +tab off the window back to VS Code the hover is still there and stays around around until you hover something else with a rich hover, or click on it and hit escape