jiebi/CodeConvo huggingface dataset:
Change:
import { CommentMenus } from 'vs/workbench/contrib/comments/browser/commentMenus'; import { ICellRange } from 'vs/workbench/contrib/notebook/common/notebookRange'; import { IWorkbenchLayoutService } from 'vs/workbench/services/layout/browser/layoutService'; <ins> import { IConfigurationService } from 'vs/platform/configuration/common/configuration'; import { COMMENTS_SECTION, ICommentsConfiguration } from 'vs/workbench/contrib/comments/common/commentsConfiguration'; </ins> export const ICommentService = createDecorator<ICommentService>('commentService');

Discussion:
See related issue that was closed by user who opened it: I think it'd be fantastic to hide the discussion/comment bar for those of us that like to keep our interface really minimal. Part of it is how it's distracting to see the + sign moving all over the document with the cursor. I'd like to be able to turn it off in the settings for all circumstances. <img width="115" alt="image" src="https://user-"
I second that! VSCode already has a reputation of being an angry fruit salad. A car radio with a full color display in demo-mode, and then 50 of them built into a store display, scream less than VSCode. Ok I might be exaggerating a bit here.. but I am for from exaggerating when I say that I have about 180 lines in my file just to tone it down. Today I would like to make that a 181 lines. Cheerio!
Have you tried the command "Comments: Toggle Editor Commenting"? If that's not enough then I can also add a setting.
While the "Comments: Toggle Editor Commenting" command is useful, it doesn't persist and doesn't completely solve the issue: if I enable Zen mode and then disable Zen mode, then this gutter will reappear and I will need to toggle again. after running the toggle, the gutter is still wider than it would be without this extension enabled. I just disable this extension until I need it and then enable it temporarily when I need it.
I'll make some updates to better persist the disablement.
Hello! I'm also looking forward to hiding this button. Actually I just need to make commits in vs code, and I don't use review even when a pull request is open But of course someday I will use it, it's just that this good function is not for every day
Incoming change does the following: Persists your pre-zen mode comment toggled state when exiting zen mode Introduces the setting Still let you quickly toggle commenting on an off irrespective of , similar to how toggle word wrap works.
Thanks for the progress!! It seems like the new settings don't do anything about the double-wide gutter. That's a pretty big deal because I'm losing a decent chunk of screen real estate even when commenting is turned off.
I was going to address that in a separate PR to keep my changes smaller. I'm planning to fix it today!
Oh hurray!! So exciting!!
Change:
* Allows to register on the event that quick open is hiding */ onHide: Event<void>; <del> } </del>  No newline at end of file <ins> } </ins>

Discussion:
VSCode Version: 1.5.0-insider OS Version: Windows 10 Steps to Reproduce: value is highlighted/selected Currently we can't put the cursor at the end of the default value when running . In this case, users have to move the cursor manually if we want to keep the default value as prefix always.
That's actually indented use case since the user is likely to accept <kbdEnter</kbdor over write the pre-set value. What is your use-case for this?
This features originally comes from implementing Vim's Ex commands, which support line range as a prefix like represents and represents . When users trigger Ex command by , Vim will help fulfill the line range prefix automatically and then users can type commands directly, eg for replacement. If users don't like the line range Vim puts there automatically, they need to use to delete the range characters. Vim doesn't select those characters it auto-completes but Code does, so I'm asking if it's possible to add this support to .
It would also help if a selection range could be defined. In my case I would like set the whole file path as value but only select the file base name. e.g. /path/to/file/ Users most likely will only change the but should also have the possibility to change the path.
Concurring to what said. I have an open question on Stack overflow:
+1 to this, it is very counterintuitive to do visual block find/replaces with VSCodeVim as noted in the above mentioned issues with this default behavior. If it were configurable like makes it, that would be useful for better emulating vim-style editing for VSCodeVim users like myself!
Change:
resolved "https://registry.yarnpkg.com/@vscode/iconv-lite-umd/-/iconv-lite-umd-0.7.0.tgz#d2f1e0664ee6036408f9743fee264ea0699b0e48" integrity sha512-bRRFxLfg5dtAyl5XyiVWz/ZBPahpOpPrNYnnHpOpUZvam4tKH35wdhP4Kj6PbM0+KdliOsPzbGWpkxcdpNB/sg== <del> "@vscode/proxy-agent@^0.13.1": version "0.13.1" resolved "https://registry.yarnpkg.com/@vscode/proxy-agent/-/proxy-agent-0.13.1.tgz#c03e9a9d65b62c762f31fa95bf9d9f52372c4825" integrity sha512-6z/EQ4IrVYJ35f7g/HoDsVIcBjBHJtUOe/msBoTQ6B/LN2TTlxTHH1TWAwMxQgKZkKrjD5JJG2ZJN8qThQlVaQ== </del> <ins> "@vscode/proxy-agent@^0.13.2": version "0.13.2" resolved "https://registry.yarnpkg.com/@vscode/proxy-agent/-/proxy-agent-0.13.2.tgz#0d289826c07faecc4ca07de80a8e5a9459d06119" integrity sha512-BSUd0NTj44WvG4O9A6N+4R1XhxtPqCYltWeHyNkquX9T//a1US+cd8fxzcZCPd3z7dygdYIPkZAKM+CrefWWOA== </ins> dependencies: "@tootallnate/once" "^1.1.2" agent-base "^6.0.2"

Discussion:
Copied from
By based on the error from , looks like this commit was not released and consumed in VSCode
I assume this change was done in March and therefore it also exists in 1.77.0 ?
Not sure why you're assuming the change was done in March. The change was done in April: It's new in 1.78.0. This breaks automatic proxy discovery in the extension host on Windows platforms only. I don't think it's a stop ship because: affects extension host on Windows only. affects users who rely on automatic proxy discovery. There is a workaround: manually configure the proxy on VS Code. were seemingly no reports of breakage the entire month of April on Insiders. I suggest merging the fix in as a candidate of an April recovery milestone. Leaving it to you as endgame champ, to chime in.
Because I saw the dependency on was in March - May be this is nothing to do with this change. I agree to take this as a candidate for next recovery
Just to clarify: This breaks loading of OS certificates on Windows (not proxy discovery). This will affect users relying on self-signed certificates for development and those requiring a CA certificate from their network proxy. Only HTTP/S requests made by extensions using the Node API are affected.
Can a test get to prevent this from happening again?
This is also affecting remote-containers extension. I'm trying to open a folder in my remote linux machine using remote-containers extension in vscode(windows workstation). It just silently fails with the following error:
Thanks Manually setting the proxy in remote settings worked for me !
Verification: VS Code on Windows the output channel that there's no exception regarding <img width="1026" alt="image" src=""
Change:
return this._channel.call('$getWslPath', [original]); } <del> setTerminalLayoutInfo(layout: ITerminalsLayoutInfoById): Promise<void> { </del> <ins> setTerminalLayoutInfo(layout?: ITerminalsLayoutInfoById): Promise<void> { </ins> const workspace = this._workspaceContextService.getWorkspace(); const args: ISetTerminalLayoutInfoArgs = { workspaceId: workspace.id, <del> tabs: layout.tabs </del> <ins> tabs: layout ? layout.tabs : [] </ins> }; return this._channel.call<void>('$setTerminalLayoutInfo', args); }

Discussion:
Also repro's in stable
unsure when this started happening. I don't see any open issues about it, which makes me think this is expected in WSL?
was last working in stable 1.59
and because it was broken in stable 1.60, we can narrow it down - the breaking change happened in August
looks like perhaps a race condition - get layout info is called w the correct workpsaceId, but then set layout info is called so might be wiping out the stored info before the reconnect can occur.
I open a terminal in a Remote-SSH window, reload the window, it is not reconnected
still doesn't work for WSL. based on my investigation, the pty service gets re-created when the window is reloaded, thus losing the and maps
when connected to localhost via ssh, reloading does persist the terminals but I thought this would still be using the ... !
Yep !
Also working for me in codespaces https://user-
It does work in WSL. interestingly, other state isn't persisted that should be though (see the layout change) !
this works on all remote platforms based on my testing. i saw a few times reloading WSL didn't work, but now cannot reproduce
Oh cool, I thought the situation was much worse. I'll reopen to verify on my side since we definitely want to make sure this is working everywhere
All seems to work
verified
Change:
} } <del> emitAlignment(c.original.endLineNumberExclusive, c.modified.endLineNumberExclusive); </del> <ins> emitAlignment(c.original.endLineNumberExclusive, c.modified.endLineNumberExclusive, true); </ins> lastOriginalLineNumber = c.original.endLineNumberExclusive; lastModifiedLineNumber = c.modified.endLineNumberExclusive;

Discussion:
. To verify the bugfix, check that in the newest version of the monaco editor the alignment is as expected. edit from <!-- 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 <!-- 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.89.1 (user setup) Commit: Date: 2024-05-07T05:13:33.891Z Electron: 28.2.8 ElectronBuildId: Chromium: 120.0.6099.291 18.18.2 V8: 12.0.267.19-electron.0 OS: Windows_NT x64 10.0. Searched existing issues by "compare vertical alignment" - no relevant results. Steps to Reproduce: files test2 and test1 them Fact wrong vertical alignment of identical rows after delete-add section ! Expected !
Thanks for sharing the input documents and the screenshot! Unfortunately, it is still not clear what this issue is about - I don't see a big difference in the screenshots. Can you add more details?
difference (expected empty range) is shown on this picture !
Ahh, I see. Can you check the dev console?
No. I want fix in my test. Not in dev console. Can you reproduce my simple test in user interface?
No, I cannot reproduce. But I think VS Code might have logged some errors to the VS Code dev console. You could help me fixing this bug, but sharing if there are any error messages in the VS Code dev console.
Show your comparison result. Here is log from dev console: An iframe which has both allow-scripts and allow-same-origin for its sandbox attribute can escape its sandboxing. !
Change:
import { darken, editorBackground, editorForeground, listInactiveSelectionBackground, opaque, registerColor } from 'vs/platform/theme/common/colorRegistry'; import { themeColorFromId } from 'vs/platform/theme/common/themeService'; import { IEditorDecorationsCollection } from 'vs/editor/common/editorCommon'; <ins> import { CommentThreadState } from 'vs/editor/common/languages'; </ins> export const overviewRulerCommentingRangeForeground = registerColor('editorGutter.commentRangeForeground', { dark: opaque(listInactiveSelectionBackground, editorBackground), light: darken(opaque(listInactiveSelectionBackground, editorBackground), .05), hcDark: Color.white, hcLight: Color.black }, nls.localize('editorGutterCommentRangeForeground', 'Editor gutter decoration color for commenting ranges. This color should be opaque.')); registerColor('editorGutter.commentGlyphForground', { dark: editorForeground, light: editorForeground, hcDark: Color.black, hcLight: Color.white }, nls.localize('editorGutterCommentGlyphForeground', 'Editor gutter decoration color for commenting glyphs.'));

Discussion:
Comments in the editor have a different color based on their resolved status. We could do something similar for the icon in the gutter, and make obvious which comment is resolved even when comments are folded. Maybe change the icon color? Or use a different icon? (also related to )
Example of how it currently looks: ! Example with adjusted colours: ! Note that colour alone is not a full solution since it is not that accessible, but I think it should be included in the final solution.
A different icon/unicode character for resolved would be good here.
Let's get done first.
Change:
"meta.embedded.block.pug": "jade", "meta.embedded.block.javascript": "javascript", "meta.embedded.block.json": "json", <ins> "meta.embedded.block.jsonc": "jsonc", </ins> "meta.embedded.block.less": "less", "meta.embedded.block.objc": "objc", "meta.embedded.block.scss": "scss",

Discussion:
This problem still occurs even if you disable all extensions. in Fenced code blocks for JSONC doesn't work well in Markdown. On the other hand, in Fenced code blocks for JSON and JSON5 does work well. Create the following Fenced code blocks for JSONC. jsonc { "settings": true } Then run on the line with . You will get the following results: jsonc { &lt;!-- "settings": true --} The correct result is: jsonc { // "settings": true } ` Execute repeatedly !
I'd like to work on this. Could you please give me some leads?
I made the PR. Could you please check it?
Change:
}); } <del> private _suggestBasedOnExecutables(): string[] { if (!process.env.PATH || this._exeBasedRecommendations.length > 0) { return this._exeBasedRecommendations; } let envpaths = process.env.PATH.split(process.platform === 'win32' ? ';' : ':'); </del> <ins> private _suggestBasedOnExecutables(recommendations: string[]): void { const homeDir = os.homedir(); </ins> let foundExecutables: Set<string> = new Set<string>(); <ins> let findExecutable = (exeName, path) => { return pfs.fileExists(path).then(exists => { if (!foundExecutables.has(exeName)) { foundExecutables.add(exeName); recommendations.push(...product.exeBasedExtensionTips[exeName]['recommendations']); } }); }; </ins> // Loop through recommended extensions forEach(product.exeBasedExtensionTips, entry => { <del> let executables = entry.value.split(','); // Loop through executables that would result in recommending current extension for (let i = 0; i < executables.length; i++) { if (!foundExecutables.has(executables[i])) { </del> <ins> if (typeof entry.value !== 'object' || !Array.isArray(entry.value['recommendations'])) { return; } </ins> <del> // Loop through paths in PATH to find current executable for (let pathEntry of envpaths) { let fullPath = paths.join(pathEntry, executables[i]); if (process.platform === 'win32') { fullPath += '.exe'; } if (fs.existsSync(fullPath)) { foundExecutables.add(executables[i]); break; } } } if (foundExecutables.has(executables[i])) { this._exeBasedRecommendations.push(entry.key); break; </del> <ins> let exeName = entry.key; if (process.platform === 'win32') { let windowsPath = entry.value['windowsPath']; if (!windowsPath || typeof windowsPath !== 'string') { return; </ins> } <ins> windowsPath = windowsPath.replace('%USERPROFILE%', process.env['USERPROFILE']); findExecutable(exeName, windowsPath); } else { findExecutable(exeName, paths.join('/usr/local/bin', exeName)); findExecutable(exeName, paths.join(homeDir, exeName)); </ins> } }); <del> return this._exeBasedRecommendations; </del> } private setIgnoreRecommendationsConfig(configVal: boolean) {

Discussion:
In the renderer we want to stay away from sync fs API calls to because each call will stop the VM from doing anything. We should try to use the async fs APIs. The code in question is:
What about ?
yes, I reported those at the same time I reported this one via
There about 20 files that I need to run the checks on (this will definitely grow). Assuming there are about 20 paths in the PATH env variable, that is about 400 file checks to make in the worst case scenario If I do all of this async, thats about 400 async calls made at the same time. This can have an adverse affect as well correct? Or it doesnt matter at all?
anything is better than doing it sync, especially if you are stat'ing 400 files which probably means that the user cannot do anything for a couple of 100ms. We have  that allows to batch resolve. my 2 cents: having to stat 400 files for a feature seems wrong to me, especially if this blocks a piece of UI from working properly. At the very minimum this should run in the background, maybe buffered and not block any UI from showing up.
Change:
item.row.domNode.style.height = ''; item.size = item.row.domNode.offsetHeight; if (item.size === 0 && !isAncestor(item.row.domNode, getWindow(item.row.domNode).document.body)) { <del> console.warn('Measuring item node that is not in DOM! Add ListView to the DOM before measuring row height!'); </del> <ins> console.warn('Measuring item node that is not in DOM! Add ListView to the DOM before measuring row height!', new Error().stack); </ins> } item.lastDynamicHeightWidth = this.renderWidth; return item.size - size;

Discussion:
I see multiple of these in dev console but that's not helpful since it's hard to trace the buggy caller. Should we include in the warning? !
Sure, I'll add the stack trace, however, it's possible that it won't be very helpful as it's likely to stem from a list event. If that is the case we can consider logging more detailed information on the list/node.
verification by code review
Change:
export class WebviewElement extends Disposable implements IWebview, WebviewFindDelegate { public readonly id: string; <del> private readonly iframeId: string; </del> <ins> protected readonly iframeId: string; </ins> protected get platform(): string { return 'browser'; }

Discussion:
(observed for installed extensions, but I think it is slower for all extensions) Insiders: ! Stable: !
cc
Seeing similar slowness in Getting Started, cc is it maybe a general markdown issue?
Yes, I can confirm that markdown rendering has slowed down. Hence assigning back to
Doesn't seem to happen for the markdown preview which suggests to me something in core with markdown rendering. Let me know if you notice this for any other webviews
I have a potential fix but don't yet understand why it works To summarize: when loading webviews, we load a file called from the disk. This file is very small and should be loaded almost instantly. And it is for normal webviews However for the extension editor, the network request for this file is in the state for almost a full second. I've confirmed that our code to serve this file runs very quickly (however it is only hit after the stall) so the stall must be happening somewhere else: Unlike other webviews, the extension editors all share a single internal webview identifier. This means that the requests look like: However if I change the extension editors to also have unique ids for the requests, the stall disappears My best guess right now is there's a cache lookup or something that causes the stall (I thought it could be the service worker, but both cases have the service worker enabled and the service worker also only sees the fetch after the stall)
cc
Also porting fix to November release
There is a limit on the number of socket connections per host, currently it is set to 6 in all chromium based browsers ;l=43-54, it is very likely possible that we hit this when using the same origin for extension editors. I can confirm if this is the case by taking a net log with . Edit: custom protocol requests don't show up in the above netlog trace, I will confirm with this in runtime trace and follow-up here.
Change:
location: ChatAgentLocation, editor: ICodeEditor, @IInstantiationService private readonly _instaService: IInstantiationService, <ins> @ILogService private _logService: ILogService, </ins> @IContextKeyService contextKeyService: IContextKeyService, @IConfigurationService configurationService: IConfigurationService, ) {

Discussion:
start inline on a line in the middle of the view port :bug: when the zone shows, the "focus line" is scrolls towards the bottom
Change:
let navigationResult = await this.findConflictForNavigation(editor, direction); if (!navigationResult) { <ins> // Check for autoNavigateNextConflict, if it's enabled(which indicating no conflict remain), then do not show warning const mergeConflictConfig = vscode.workspace.getConfiguration('merge-conflict'); if (mergeConflictConfig.get<boolean>('autoNavigateNextConflict.enabled')) { return; } </ins> vscode.window.showWarningMessage(localize('noConflicts', 'No merge conflicts found in this file')); return; }

Discussion:
Testing Enable After merging the last conflict following warning is shown ! If auto navigation is enabled then I do not think this warning is needed
Would like to pick this up
Change:
if (saveBeforeRunTaskConfig === SaveBeforeRunConfigOptions.Never) { return false; <del> } else if (saveBeforeRunTaskConfig === SaveBeforeRunConfigOptions.Prompt) { </del> <ins> } else if (saveBeforeRunTaskConfig === SaveBeforeRunConfigOptions.Prompt && this._editorService.editors.some(e => e.isDirty())) { </ins> const dialogOptions = await this._dialogService.show( Severity.Info, nls.localize('TaskSystem.saveBeforeRun.prompt.title', 'Save all editors?'),

Discussion:
<!-- 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 <!-- 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: current development branch OS Version: MacOS 12.5.1 Steps to Reproduce: sure setting is set to all editors a task that the editor asks whether to save all editors When no editor is dirty, it is disconcerting when trying to run a task asks me whether I should save all editors – I need to stop and think what is unsaved and whether I should save it. This can be avoided if the code checks that any editor is dirty before asking. PR submitted: