jiebi/CodeConvo huggingface dataset:
Change:
return; } <del> if (!this.forceUpdate && this.currentVersion && this.currentVersion.resource.fsPath === resource.fsPath && this.currentVersion.version === document.version) { </del> <ins> const pendingVersion = new PreviewDocumentVersion(resource, document.version); if (!this.forceUpdate && this.currentVersion && this.currentVersion.equals(pendingVersion)) { </ins> if (this.line) { this.updateForView(resource, this.line); }

Discussion:
Issue Type: <bBug</bSometimes the Markdown preview stops updating when I am typing if the source document is very large. It is not easy to reproduce, but when it happens, it is very annoying. Here is a video clip to describe what happened: ! Notice that at the end, no matter how long I wait, the preview never updates (two s are missing from the preview). It is acceptable if the preview has some delay if the source document is very large, but this seems like some scheduling issue that the final updates from the source document is ignored. The preview should be updated to match the source document if I wait long enough. VS Code version: Code 1.33.1 (, 2019-04-11T08:27:14.102Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </detailsExtensions disabled <!-- generated by issue reporter --
, Yes this is happening and I think this happens in the case when you change something and then wait for like 2/3 seconds and change something again and similarly repeat it or stop, Just changing once seems to be working but takes some time. , I think the refresh preview calls are getting clogged because of the way the user is updating the markdown document , Can you please confirm any way we can fix this ?
Thanks looking into this. I'm having trouble reproducing this issue but there are two places where I believe that updates to the preview could be getting out of sync: the call to itself: We're currently stabilizing vscode's master branch so I can't check this in but here's a PR that should the problem: the updates to the webview content itself. Here's the code that runs inside the webview that does the update: If you can reproduce this problem, try taking a look the PR and try it out on your local machine to see if it fixes this.
, Not sure exactly how to fix this as the issue is not consistent and when I checked it today, it seems to work ( but surely the preview refresh and sync takes some time, which is considerable for that large file) , So I leave it open for you to take a call on this. I would suggest to check it again and give it some time to update.

Please test this again on the VS Code 1.35 insiders builds that should be coming out at the end of next week
New insiders builds are out. Can you please test this again using them
It seems the problem still exists: ! The last letter is missing from the preview.
I'm closing this given that no one else has reported this issue and no one on the vs code team can reproduce it either Please investigate and submit a fix if you are consistently running into this. I've linked to most of the relevant code locations
Change:
} dispose() { <del> const indicators = [this.workspaceTrustIndicator, this.scopeOverridesIndicator, this.syncIgnoredIndicator, this.defaultOverrideIndicator]; for (const indicator of indicators) { </del> <ins> this.keybindingListeners.dispose(); for (const indicator of this.allIndicators) { </ins> indicator.disposables.dispose(); } }

Discussion:
Change the key event handling so that the user can tab once into the indicators container, and then use left/right arrows to focus on different indicators.
the Settings editor, search on the setting. tab should focus on the first indicator. again should go to the checkbox. -tabbing twice from there should focus the entire setting again. again to the indicator. The left and right arrow keys, along with the home and end keys should allow the user to focus onto the other indicators. indicators container should keep track of the focused indicator. If the second indicator is focused, and the user tabs to the checkbox and back, the second indicator should be the one focused rather than the first one.
Change:
// ------ text preformat export const textPreformatForeground = registerColor('textPreformat.foreground', <del> { light: '#A31515', dark: '#D7BA7D', hcDark: '#FFFFFF', hcLight: '#000000' }, </del> <ins> { light: '#A31515', dark: '#D7BA7D', hcDark: '#000000', hcLight: '#FFFFFF' }, </ins> nls.localize('textPreformatForeground', "Foreground color for preformatted text segments.")); export const textPreformatBackground = registerColor('textPreformat.background',

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: 1.90.0 OS Version: Debian GNU/Linux trixie/sid I'm using dark high contrast theme. After updating vscode to 1.90.0 text inside textPreformat by default is the same color as background namely white. Adding this to setting: solves the problem.
One for recovery?
Fix looks good: !
Related on Stack Overflow:
Change:
*  - the rendering width of a tab character; *  - the number of spaces to insert when [insertSpaces](#TextEditorOptions.insertSpaces) is true. */ <del> tabSize: number; </del> <ins> tabSize: number | string; </ins> /** * When pressing Tab insert [n](#TextEditorOptions.tabSize) spaces. */ <del> insertSpaces: boolean; </del> <ins> insertSpaces: boolean | string; </ins> } /**

Discussion:
We are working on the EditorConfig plugin and we have issues regarding . Users don't have to specify values for let's say . Let's take the following And my VSCode settings file looks like this If I open , the style should be set to and the indent size to . If I open , it should set the to and take the global setting (which is ) so it should be calculated by VS Code itself. At the moment this is not possible. Because you have to overwrite the entire object which prevents auto-calculating the indent size. I think you are in charge for something like this :)?
These are my findings. Please let me know if I'm wrong :). So internally VS Code has some decision check wether it should recalculate the settings for a file in the text editor. Based on some debugging, it looks like the decision looks like this. Is the options object still referring to the initial options object? -YES: No plugin changed the settings so recalculate them based on the user settings -NO: Do nothing as someone altered the object Because when I only change one value , it still takes my global VS Code settings because (in my opinion) the object is still referring to the initial options object and thus is not changed. This is how this issue can be resolved. Values passed in as should be calculated by VS Code (based upon the user settings). If my global settings is set to , VS Code will determine the tab size for me based on the current file being opened. Same goes for .
you can get the right GitHub code coloring for files by using the file type, see?
Thanks :)
This issue is thoroughly discussed here
It looks like I found a solution in It looks like the interface is defined like Which makes it not possible to provide as value for either one of the properties. But actually, it is perfectly valid to provide as VS Code will then auto calculate the value for that property. So I guess a solution for this would be to update that interface.
For the record, you're referring to . Would Microsoft be willing to update this interface or is there a good reason they don't use union types for these settings?
Did a PR I guess they will accept it as I don't see any reason to not allow strings.
Thank you for the PR! :+1: I went a bit further to try to clarify things:
Change:
this.runConfigureTasks(); return; } <del> this.run(task).then(undefined, reason => { </del> <ins> this.run(task, undefined, TaskRunSource.User).then(undefined, reason => { </ins> // eat the error, it has already been surfaced to the user and we don't care about it here }); });

Discussion:
Issue Type: <bBug</bRecent update to 1.48.0 seems to have killed sorting the Run Build Task list by most recently used. In fact, the list doesn't appear to change order at all (not sorting lexicographically, either). VS Code version: Code 1.48.0 (, 2020-08-13T07:50:42.600Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (7)</summaryExtensionVersion ------ vscode-open-in-application1.0.5 cortex-debug0.3.7 cpptools0.29.0 cmake0.0.17 vscodeintellicode1.2.10 clang-format1.9.0 linkerscript1.0.1 </details<!-- generated by issue reporter --
To verify: Open a folder with build tasks, such as the VS Code repo. If you use the VS Code repo, in the change the of the task to simply be (no ). Run the Tasks: Run Build Task command Choose a build task and run it from that quick pick Run the Tasks: Run Build Task command again. Verify that the task you just ran shows at the top of the list in the recently used section. Repeat with another build task.
Verified in Version: 1.48.1 Commit: Date: 2020-08-18T17:06:48.722Z
Change:
vulns: readonly IMarkdownVulnerability[]; }>(); <ins> /** * Max number of models to keep in memory. * * Currently always maintains the most recently created models. */ private readonly maxModelCount = 100; </ins> constructor( @ILanguageService private readonly languageService: ILanguageService, @ITextModelService private readonly textModelService: ITextModelService

Discussion:
We accumulate model references but don't really release/dispose them. Only when the chat session ends (a new model is being set)
Change:
.monaco-inputbox > .ibwrapper > .mirror { /* Customizable */ <del> padding: 4px; </del> <ins> padding: 4px 6px; </ins> } .monaco-inputbox > .ibwrapper {

Discussion:
Looking at ways to make VS Code feel ever so slightly more approachable. A subtle 2px border radius on our common input components could be one way to make the UI feel more inviting and less harsh: <img width="361" alt="CleanShot 2022-04-08 at 14 48 52 src="https://user-"<img width="522" alt="CleanShot 2022-04-08 at 14 55 52 src="https://user-"<img width="494" alt="CleanShot 2022-04-08 at 14 58 01 src="https://user-"<img width="437" alt="CleanShot 2022-04-08 at 14 49 46 src="https://user-"<img width="500" alt="CleanShot 2022-04-08 at 15 01 55 src="https://user-"! FWIW, we already use a border radius on our icon buttons: <img width="300" alt="CleanShot 2022-04-08 at 15 03 36 src="https://user-"cc
I like this idea for buttons. I am not so sure about input/combo boxes.
I'm a +1 on this one, I think the inputs might need a bit of spacing from the side to feel more natural. We should also make sure that our labels are distinguishable as they start looking similar. Maybe we update the labels to be more pill-like?
As in padding L/R? I think they are indeed a bit different from our dropdowns if memory serves. Good call on the labels/tags.
Border-radius on buttons was merged but inputs is still under discussion so I'll keep this one open.
Good job
Change:
import { ContextKeyExpr } from 'vs/platform/contextkey/common/contextkey'; import { KeybindingWeight } from 'vs/platform/keybinding/common/keybindingsRegistry'; import { AbstractInlineChatAction } from 'vs/workbench/contrib/inlineChat/browser/inlineChatActions'; <del> import { CTX_INLINE_CHAT_EMPTY, CTX_INLINE_CHAT_FOCUSED, CTX_INLINE_CHAT_HAS_AGENT } from 'vs/workbench/contrib/inlineChat/common/inlineChat'; </del> <ins> import { CTX_INLINE_CHAT_EMPTY, CTX_INLINE_CHAT_FOCUSED } from 'vs/workbench/contrib/inlineChat/common/inlineChat'; </ins> import { isDetachedTerminalInstance } from 'vs/workbench/contrib/terminal/browser/terminal'; import { registerActiveXtermAction } from 'vs/workbench/contrib/terminal/browser/terminalActions'; import { TerminalContextKeys } from 'vs/workbench/contrib/terminal/common/terminalContextKey';

Discussion:
The context key used in terminal and notebook chat which is wrong because it signals that there is a chat participant for the editor location and it doesn't know anything about other locations.
It's now removed from the notebook side.
Change:
interface ISessionTemplateData { session: HTMLElement; name: HTMLElement; <del> state: HTMLElement; </del> stateLabel: HTMLSpanElement; label: HighlightedLabel; actionBar: ActionBar;

Discussion:
Testing Badge should use text ellipsis when there is not enough room to display the full message: !
Good catch. Yes, we should improve this.
Not for endgame since we always behaved like this. Moving out of milestone and opening up for PRs. Code pointer
Change:
this.list.setSelection([focus], e.browserEvent); } <del> e.browserEvent.preventDefault(); </del> this._onPointer.fire(e); }

Discussion:
When opening as quickpick with , the latest Insiders builds only handle click events on the checkbox and not on the row item. In Stable, clicking on the row works as expected. This sounds very similar to and might have the same cause. <!-- 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?: Unsure, probably 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.75.0-insider, Commit: OS Version: Windows11(.963), macOS Ventura 13.1; using the VS Code in the web Steps to Reproduce: a quick pick UI with multiple selection options Try to click a row and observe that the selection doesn't change on the checkbox and observe the selection does change This bug was observed with the Codespaces extension, but should happen for any extension/UI using multi-select quick picks.
can you update to the latest Insiders from today and try again?
Sure! It's still broken with the latest insiders: Version: 1.75.0-insider (Universal) Commit: Date: 2023-01-09T05:30:04.983Z Electron: 19.1.8 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Darwin arm64 22.2.0 Sandboxed: Yes https://user- Here's Stable for comparison: https://user-
Yes, more fallout from , apologies
Change:
} /** <ins> * Removes any query string from the link. * @param link The link to use. */ export function removeLinkQueryString(link: string): string { // Skip ? in UNC paths const start = link.startsWith('?') ? 4 : 0; const index = link.indexOf('?', start); if (index === -1) { return link; } return link.substring(0, index); } /** </ins> * Returns the optional link suffix which contains line and column information. * @param link The link to parse. */

Discussion:
<img width="1440" alt="image" src="https://user-"path: Versions:
I have one question wish can get help: how vscode terminal detect the path cwd? why can the path correctlly go to the file with a releative path? <img width="1440" alt="image" src="https://user-"I guess it may use the But seems I can get the cwd in TerminalLinkProvider now: <img width="1440" alt="image" src="https://user-"
We check a few things to determine which to use
vite become more and more popular recent days, I think it would be convinient to support the path with query string: !
When I click, it opens the right file, but it underlines the first query argument when I hover, is that an issue? <img width="539" alt="image" src=""
not much of an issue but it would look more polished by just underlining the whole thing
Change:
} run(accessor: ServicesAccessor, ...args: any[]) { <ins> announceChatCleared(accessor); </ins> const widgetService = accessor.get(IChatWidgetService); const widget = widgetService.lastFocusedWidget;

Discussion:
Reported by Use or as a SR user. there's no indication that that has succeeded. We could alert with info or use an audio cue
I don't see the chat clear history action in core, so we'd need to do this in the extension. There's a clear input history, though I don't think we want to alert for that case.
Actually, found it
Change:
} getPosition(): IContentWidgetPosition | null { <ins> // We cannot put the content widget after line 0, as line 0 gets normalized to line 1. // Thus, we put the content widget before line 1 to make it slightly less buggy. // TODO: Fix this properly. if (this.lineNumber === 0) { return { position: { lineNumber: 1, column: 1, }, preference: [ContentWidgetPositionPreference.ABOVE], }; } </ins> return { position: { lineNumber: this.lineNumber, column: 1, }, preference: [ContentWidgetPositionPreference.BELOW],

Discussion:
<img width="1054" alt="image" src="https://user-"I opened an old merge conflict and I saw that things looked a little funky in the merge editor. The text for "Accept Current" and "No Changes Accepted" are overlapped. Also, I see some symbols before the branch names that I'm not sure where it's from? I was thinking that this might be due to the super long branch name that is part of this merge conflict Feel free to close if you can't repro, not too sure what caused this.
This only happens for conflicts that start with line 1.
Change:
}); }); }); <ins> suite('gitTwoDashes', async () => { const expectedMap = new Map(); const command = `git add . -all`; const output = 'error: did you mean `--all` (with two dashes)?'; const exitCode = 1; const actions = [ { id: 'terminal.gitTwoDashes', label: 'Run: git add . --all', run: true, tooltip: 'Run: git add . --all', enabled: true } ]; setup(() => { const command = gitTwoDashes(); expectedMap.set(command.commandLineMatcher.toString(), [command]); quickFixAddon.registerCommandFinishedListener(command); }); suite('returns undefined when', () => { test('output does not match', () => { strictEqual(getQuickFixes(createCommand(command, `invalid output`, GitTwoDashesRegex, exitCode), expectedMap), undefined); }); test('command does not match', () => { strictEqual(getQuickFixes(createCommand(`gt sttatus`, output, GitTwoDashesRegex, exitCode), expectedMap), undefined); }); }); suite('returns undefined when', () => { test('expected unix exit code', () => { assertMatchOptions(getQuickFixes(createCommand(command, output, GitTwoDashesRegex, exitCode), expectedMap), actions); }); test('matching exit status', () => { assertMatchOptions(getQuickFixes(createCommand(command, output, GitTwoDashesRegex, 2), expectedMap), actions); }); }); }); </ins> if (!isWindows) { suite('freePort', () => { const expected = new Map();

Discussion:
With we're getting some initial terminal quick fixes. We have a bunch more ideas, let's use this issue to track adding more at a later date when we have more information on how the feature is received.
Also want to consider the setting to disable one or more of these
The open URL one (the only one I’ve seen so far) was a really pleasant surprise and I immediately adopted it into my workflow for opening a GitHub PR after pushing a new branch. Another one I would love to see is opening files with merge conflicts: <img width="615" alt="image" src="https://user-"
great idea!
I think this can be closed since we have individual issues tracking ideas
Change:
import { IUserDataAutoSyncEnablementService } from 'vs/platform/userDataSync/common/userDataSync'; import { ILifecycleService, LifecyclePhase } from 'vs/workbench/services/lifecycle/common/lifecycle'; import { INotificationService, Severity } from 'vs/platform/notification/common/notification'; <del> import { IInstantiationService } from 'vs/platform/instantiation/common/instantiation'; import { ReloadWindowAction } from 'vs/workbench/browser/actions/windowActions'; </del> <ins> import { IHostService } from 'vs/workbench/services/host/browser/host'; </ins> const SOURCE = 'IWorkbenchExtensionEnablementService';

Discussion:
Steps to Reproduce: = workbench does not open From: Workaround:
I think depending on is logically correct. But, in web is depending on other workbench services like --and causing cycle. Not having consistent base services in desktop and web is causing confusion and debt and it might add up as we evolve. I think fixing in is just a patch. To unblock for now, I removed the dependency on and used . Assigning back to you for fixing this in .
Change:
private rochade(from: Position, to: Position): void { <del> // Move editor to new position </del> <ins> // Move container to new position const containerFrom = this.silos[from].child(); containerFrom.appendTo(this.silos[to]); const containerTo = this.silos[to].child(); containerTo.appendTo(this.silos[from]); // Inform editor </ins> const editor = this.visibleEditors[from]; <del> editor.getContainer().offDOM().build(this.silos[to].child()); </del> editor.changePosition(to); // Change data structures

Discussion:
For: scoped keybinding service scoped progress service For the title area and the editor itself. This requires a common parent (or the editor-container itself) to be reparented instead of the editor moving around. Enables more scenarios around menu and command contributions for contexts.
I merged this to master: title container, editor container, progress bar widget and the instantiation service are now within a new container that gets reparented when a) you move an editor around or b) you close editor group LEFT when LEFT | RIGHT exist and RIGHT becomes LEFT as well as for when you have 3 editors open and you close the left or center group. Is there a way to verify this works for the scenario you disabled late before we finished June milestone? I remember you reverted a commit and I am not sure if this can be now reverted back again. !
I can verify
LGTM - will push the revert revert commit
Verified via
Change:
const data = await this.sessionSyncWorkbenchService.read(ref); if (!data) { <ins> if (ref === undefined) { this.notificationService.info(localize('no edit session', 'There are no edit sessions to apply.')); } else { this.notificationService.warn(localize('no edit session content for ref', 'Could not apply edit session contents for ID {0}.', ref)); } </ins> this.logService.info(`Edit Sessions: Aborting applying edit session as no edit session content is available to be applied from ref ${ref}.`); return; }

Discussion:
Testing Referencing to , when I run out of sessions to resume, I don't see any indication that it didn't change anything. This might be a little tricky for people who think that they've restored a session but accidentally forgot to store or something. Perhaps there should be a notification of some sort or a warning in the case where it doesn't change anything or no sessions are restored?