jiebi/CodeConvo huggingface dataset:
Change:
@ILabelService private readonly _labelService: ILabelService ) { super(); <ins> for (const commandSelector of this._terminalContributionService.quickFixes) { this.registerCommandSelector(commandSelector); } </ins> const commandDetectionCapability = this._capabilities.get(TerminalCapability.CommandDetection); if (commandDetectionCapability) { this._registerCommandHandlers();

Discussion:
Running out of sources I see this:
This means that the contribution isn't getting evaluated before is called. Not too familiar with how / when is handled, but we call when the is created
I think perhaps moving that to the top of the constructor (before registering the command handlers) will fix this
This happens on window open
and the quick fix does work for that extension !
Seeing this in error telemetry for Insiders from 12/23:
This is the 6th error by machines in telemetry https://vscode-
I cannot reproduce this in Insider's. did you notice this after doing anything in particular?
I got this error when using remote dev container <details<summaryWindow</summary</details
Fixed in
Actually still found it in my devtools today:
I can't reproduce, but I can simulate the race by adding to 's promise in
HI, im having the same problem here 2023-02-16 17:10:14.453 [error] Error: No registered selector for ID: ms- at R.registerQuickFixProvider (vscode-file://vscode-) at r.$registerQuickFixProvider (vscode-file://vscode-) at m.N (vscode-file://vscode-) at m.M (vscode-file://vscode-) at m.H (vscode-file://vscode-) at m.G (vscode-file://vscode-) at vscode-file://vscode- at g.invoke (vscode-file://vscode-) at n.deliver (vscode-file://vscode-) at a.fire (vscode-file://vscode-) at r.fire (vscode-file://vscode-) at Z.onmessage (vscode-file://vscode-) I got vs code 1.71.1 running on W11 21H2 How i am supposed to fix this, or it's not a problem and vs code is working normally? Thank you!
Update your VS code version, where this is fixed
Sorry, i typed incorrectly mi vs code version. It is the latest one 1.75.1, i reinstalled it today.
I can still reproduce in latest stabel 1.75.1 https://user-
Change:
dependencies: brace-expansion "^2.0.1" <del> minimatch@^5.0.1: version "5.1.0" resolved "https://registry.yarnpkg.com/minimatch/-/minimatch-5.1.0.tgz#1717b464f4971b144f6aabe8f2d0b8e4511e09c7" integrity sha512-9TPBGGak4nHfGZsPBohm9AWg6NoT7QTCehS3BIJABslyZbzxfV78QM2Y6+i741OPZIafFAaiiEMh5OyIrJPgtg== dependencies: brace-expansion "^2.0.1" </del> minimatch@^7.4.3: version "7.4.6" resolved "https://registry.yarnpkg.com/minimatch/-/minimatch-7.4.6.tgz#845d6f254d8f4a5e4fd6baf44d5f10c8448365fb"

Discussion:
<img width="415" alt="image" src=""Looks localized here though, and hasn't changed in 13 months
language pack looks ok too... Looking into this some more... it seems that the new lines aren't being handled properly.
This still repros :/ is the loc pipeline maybe not running?
it is the newlines... which I thought I fixed... sigh... They are being escaped in the language pack: if I manually delete these extra slashes locally, the problem goes away.
Update... the text has change: Now it's using when it should use and I think I know why. So exporting looks find: is turned in to (we do this manually and it's the XML way to say ) but what we get from the translators... they replace with actual new lines That's not what I was expecting. I would expect them to use the encoded characters but they're not. hacky quick fix that fixes likely most of the scenarios: more accurate longer fix: now that I think about it, this is probably the correct workaround for extensions as well
<img alt="image" src=""Looks like it works now
Change:
} run(accessor: ServicesAccessor): void { <ins> if (this._currentQuickPick) { this._currentQuickPick.hide(); return; } </ins> const contextKeyService = accessor.get(IContextKeyService); const commandService = accessor.get(ICommandService); const quickInputService = accessor.get(IQuickInputService); const quickPick = quickInputService.createQuickPick(); <ins> this._currentQuickPick = quickPick; </ins> quickPick.items = this.getItems(contextKeyService); quickPick.ignoreFocusOut = true; quickPick.hideInput = true;

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.67 OS Version: macOS 12.3.1 (21E258) using the button the button again to close it but cannot close it3. <img width="1076" alt="a" src="https://user-" Its always running show method, so I think it should have an open/close state to manage it.
Try clicking here: !
Thank you for the comment. Yes, I know I can close it by clicking the button, but it would be nice to close it by clicking the original button.
please improve the issue title, which currently states that you "cannot close" it.
My bad. I'll fix it now
for UX guidance here. when actions open quick picks we don't tend to have an inverse action if its still open. this is not usually the case because it is closed when focus is lost, but not something we can rely on here.
Thank you Even if the focus is lost, the action view won't be closed on Mac. Also, other buttons allow us to open and close by clicking, so it should be consistent. I often click the button by accident and need to move cursor to close the view. That would be nice to have a toggle feature on the button too.
Maybe use the setting which removes the button completely?
We don't currently hide any of the quick picks with other actions or clicking the same action (changing focus would actually close it). I think given that we have the key and the close button in the top right of the quick pick, I don't think we'd be able to do anything else.
Change:
issueType?: IssueType; extensionId?: string; experiments?: string; <ins> restrictedMode: boolean; </ins> githubAccessToken: string; readonly issueTitle?: string; readonly issueBody?: string;

Discussion:
When I report an issue from our issue reporter from an untrusted workspace, there is no info about this in the GH issue.
Marking as important to make sure we care about this before enabling trust by default to not make our life harder for triaging issues than it needs to be.
Two examples: in an effort to make the smallest change this late in the game, I’ve put it in System Info however when you report a performance issue, we also have a section called “Workspace Info” that shows up that gives details on the workspace (like number of files, etc). I think it should eventually go there
lol jk sent a PR putting it next to the OS which I don't love... but the change is small and it means the user can't not tell us their WT situation which is good.
Change:
const textModel = editorControl.codeEditor.getModel(); if (notebookDocument && textModel) { <del> const previousValue = historyService.getNextValue(notebookDocument.uri); if (previousValue) { textModel.setValue(previousValue); </del> <ins> const nextValue = historyService.getNextValue(notebookDocument.uri); if (nextValue !== null) { textModel.setValue(nextValue); </ins> } } }

Discussion:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --four cells from the interactive window input box, e.g. , , , reexecute multiple commands from earlier in your history, e.g. and use via the up arrow executing an entry from earlier in the history e.g. , scroll position resets to the bottom of the history, and you have to start over and scroll up from the most recent command (4 -3 - 2 -1). This can be frustrating for users who are trying to reexecute multiple commands. Note also that the original interactive window used to preserve your scroll history in the interactive window so that you didn't have to scroll back up through the entire history, and users have complained about this behavior change:
The expectation is that the interactive window input behaves just like a REPL. would address this. Per discussion with we should have shared logic for handing history traversal.
Any news on that? I agree with the PR that the current behavior is quite frustrating and deserves further attention.
Yes this is one of my main frustrations with the IW still. At minimum I just want the up arrow to go to the last executed code, not have cycle through like 20 cells every time I need to re-run something. And it did used to work this way ~1.5 yrs ago.
Change:
resolved "https://registry.yarnpkg.com/xterm-addon-webgl/-/xterm-addon-webgl-0.12.0-beta.36.tgz#460f80829a78c979a448d5b764699af3f0366ff1" integrity sha512-sgX7OHSGZQZE5b4xtPqd/5NEcll0Z+00tnTVxKZlXf5XEENcG0tnBF4I4f+k9K3cmjE1UIUVG2yYPrqWlYCdpA== <del> xterm-headless@4.19.0-beta.55: version "4.19.0-beta.55" resolved "https://registry.yarnpkg.com/xterm-headless/-/xterm-headless-4.19.0-beta.55.tgz#0f8fafefef57cd033100f4ffa60a04e71ed5e122" integrity sha512-LR2LyKLF/eo/m52qIlONnxNYr7a/Vp6X0M3CnaCFmYKXhjEMHqEOJOAUz/hhKG/R9j7apLgaNj/uw0mCdL780g== xterm@4.19.0-beta.55: version "4.19.0-beta.55" resolved "https://registry.yarnpkg.com/xterm/-/xterm-4.19.0-beta.55.tgz#b2b4acca6ef5c7a4761098b5e1629b7f93deefc9" integrity sha512-AGT7b6UYZ0o7jtyLZ8KwY8Rchdqv3Pi6Nkcs4YbxR0opbQjIovEc44jkGmudfVYcGaFWsA/bdxM6feJ7VXRAlg== </del> <ins> xterm-headless@4.19.0-beta.56: version "4.19.0-beta.56" resolved "https://registry.yarnpkg.com/xterm-headless/-/xterm-headless-4.19.0-beta.56.tgz#7e6bdc8d647916bf5de64a73eee6bd508d25e344" integrity sha512-EZoR/HqZoernhFngFQp7gUPy+G0TpEJkbJ9HVZcINC3m8wuV1wZKfZ4xBhsRPfhSJ7rsPnqbC+qez5ZjxwYEIw== xterm@4.19.0-beta.56: version "4.19.0-beta.56" resolved "https://registry.yarnpkg.com/xterm/-/xterm-4.19.0-beta.56.tgz#a3f1021b43ac04aa0c3f7b06f1b44ad34d487879" integrity sha512-kywKIK61oPjbloZI+jXY1zgjQm/ghOsFFMjb79IIMaWocUDDqdpo9MmGwziTVZYu4w/Air2Zfas9UWBu4/KEyA== </ins> y18n@^3.2.1: version "3.2.2"

Discussion:
Testing Have the same content in the editor and in the terminal. Search for something. Notice how the occurrence are fat and visible in the editor scrollbar. Notice how they are not fat and sparse in terminal. They seem to be incorrectly placed since my match is almost on every line and that is not the feeling I get from the terminal scroll bar ! !
How many lines do you have in the editor for this example? It looks like there are a bunch of empty lines near the bottom? The way we calculate the position of terminal scroll bar decorations is line / number of lines in the buffer.
I had the same number of lines as the terminal which is 23. If I had more lines in the editor I think that would mean that the decorations are smaller in the editor, not larger and that seems to be happening :)
to me, it looks like the decorations are closer together and not taking up as much vertical space in the scrollbar see how the lower half is just empty? !
Good point. Now I have disabled scrolling beyond last line in the editor. And they render the equal height. But look at the decorations - they are very different. Do you also see this on your machine? !
The ones in the editor are double the height - likely because of device pixel ratio on a mac that's getting taken into account there and probably should be also for the terminal. ! !
Strange because we are doing the right thing here, but is 1 here for me on a mac . !
We can make these heights different based on the number of lines in the buffer similar to what the editor does
Upstream issue:
Change:
placeholderText: searchBoxLabel, focusContextKey: this.searchFocusContextKey, // TODO: Aria-live <del> })); </del> <ins> }) ); </ins> this._register(attachSuggestEnabledInputBoxStyler(this.searchWidget, this.themeService, { inputBorder: settingsTextInputBorder

Discussion:
Issue Type: <bFeature Request</bTesting Just a thought: When I see "Modified in: Workspace" I might want to go there and check. I'd keep font and color as they are and add an underline and pointer cursor to "Workspace" on hover. VS Code version: Code - Insiders 1.27.0-insider (, 2018-08-29T05:12:15.247Z) OS version: Darwin x64 17.7.0 <!-- generated by issue reporter --
Good idea!
I would take a PR for this "Modified in: Workspace" - the word Workspace is underlined When clicked, it switches to the Workspace scope, and copies the setting key into the search bar, so the view is filtered to just that one setting
I'm interested in looking into this if that is alright.
Change:
this._loadState(); this._register(this._storageService.onWillSaveState(() => this._saveState())); this._register(this._storageService.onDidChangeValue(StorageScope.WORKSPACE, NotebookKernelHistoryService.STORAGE_KEY, this._register(new DisposableStore()))(() => { <del> this._restoreState(); </del> <ins> this._loadState(); </ins> })); }

Discussion:
Going through the error logs showed the error below . No steps but it is rooted at this line
verification - Perform a few actions in a notebook, add cells, run cells, close/reopen the tab, run more cells Open the dev tools and ensure the error is not in the console
Change:
</thead> <tbody><tr> <td><span class="codicon codicon-zap"></span></td> <del> <td><a href="" data-href="#link" title="#link"><span class="codicon codicon-zap"></span>-link</a></td> </del> <ins> <td><a data-href="#link" href="" title="#link"><span class="codicon codicon-zap"></span>-link</a></td> </ins> </tr> </tbody></table> `);

Discussion:
Issue Type: <bBug</bHello, Regarding the , in Markdown this: Renders a link. In a VS Code Extension, this is also possible: Creating a link to run a command. One would think creating an actual anchor link like this: Would work but the click does not execute the command. VS Code version: Code 1.63.0 (, 2021-12-07T05:18:59.299Z) OS version: Linux arm64 5.15.7-1-MANJARO-ARM Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (4)</summaryExtensionVersion ------ vscode-eslint2.2.2 gitlens11.7.0 vscode-drawio1.6.4 vsliveshare1.0.5242 </details<!-- generated by issue reporter --
can i take this?
I think they'd be happy if you created a PR. For completeness: works: but the cursor does not change to a hand icon like if was populated.
Thanks, will take a look
This is what I found. In markdown links are detected at two places: detects anything starting with http:// or https:// or file:// checks for and returns anything inside () as URI That's why is detected as a link but isn't. I couldn't get to work. I tried holding ctrl while clicking it and tried in preview as well. Can you tell me how to reproduce it?
You'll need to for it to take an action. The example in the link is probably the easiest. After registration create a MarkdownString containing the registered command. In regards to the linked example: You should be able to click on it and see the console log. Note that the cursor doesn't change to a hand icon.
Have you found any solution? For me even doesn't work. :( I've used a registered and available command.
The way I implemented Markdown and executing a registered command (through ) was by adding a . The structure is very particular because it is an implementation of the and is something like this: Make sure you are using the correct VS Code version too.
Command links in should now also work for normal elements included in the markdown (you have to set and on the to enable this)
where should links work? I tried this in a completion item and neither link syntaxes work: !
Sorry for not adding verification details. The markdown string needs to both trusted and have html enabled:
Change:
this.currentSuggestionDetails = createCancelablePromise(token => item.resolve(token)); this.currentSuggestionDetails.then(() => { <ins> if (this.list.length < index) { return; } </ins> // item can have extra information, so re-render this.ignoreFocusEvents = true; this.list.splice(index, 1, [item]);

Discussion:
Issue Id: <-96b3-ca5f-4d05-</b<br /<br /Versions <br /- <br /- <br /- <br /- <br /- <br /- <br /- <br /- <br /- <br /- <br /Stack <br /Error: Invalid start index: 1<br /)<br /<br /at <anonymous<br /at process._tickCallback (:188:7)<br /
this does not provide a lot of context, but became our number 2 top crash in error telemetry. Maybe we need to add more logging to get behind it?
This is an issue with the suggest widget.
has a good set of repro steps in using which I can repro the issue in Insiders but not in Stable 1.26.1 This is a case when an item from a list is selected, the list gets focus, and the corresponding event handler is called. If the event handler deals with promises, then by the time the promise is resolved, the list is gone. Should we probably have a way of identifying if the list got focus due to selection vs other cases?
I don't understand how the two things are related. If there is code which might access the list after it's been disposed, its caller should beware of this. It doesn't seem related to focus or selection at all.
Change:
protected readonly _mouseDownOperation: MouseDownOperation; private lastMouseLeaveTime: number; private _height: number; <ins> private _mouseLeaveMonitor: IDisposable | null = null; </ins> constructor(context: ViewContext, viewController: ViewController, viewHelper: IPointerHandlerHelper) { super();

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.63.0 OS Version: Windows 11 Steps to Reproduce: a file where breakpoints can be set around the edge of the editor, in and out of the margin until the breakpoint stays even though the mouse is outside of the editor (see GIF below). ! This is important to me because I am using margin decorations in Monaco and running into the same issue there. Internally the event isn't triggered, so the decorations aren't removed. It seems to be specific to decorations in the glyph margin, as without these (e.g. line decorations) it doesn't seem to reproduce.
I can reproduce when moving the mouse quickly. I find it interesting that also the scrollbars suffer form the same problem (the scrollbars listen independently to ). I've also tried locally to replace with the somewhat more modern and I could still reproduce. Basically the browser simply forgets soemtiems to send us a or a event: <img width="538" alt="image" src="https://user-"
Change:
"semver": "4.3.6", "vscode-extension-telemetry": "^0.0.5", "vscode-nls": "^2.0.1", <del> "typescript": "2.1.4" </del> <ins> "typescript": "2.1.5-insiders.20161213" </ins> }, "devDependencies": { "@types/semver": "^5.3.30"

Discussion:
VSCode Version: 1.7.2 OS Version: Ubuntu 16.04 I have yet to find out how to reproduce this, but VS Code creates a Microsoft/TypeScript/node_modules/ directory with the types-registry npm module in it in the home directory. The package readme says This is the source code for the types-publisher service, which publishes the contents of DefinitelyTyped to npm. I never set anything to be shared or published. So what exactly is this and what does it do?
Steps to reproduce: VS Code any JavaScript file It only happens for the first JS file that is opened. Could be a bug, too.
I guess this is from the automatic typings acquisition in recent versions of TypeScript. Are you saying the folder is under ?
is correct - this is location of global cache for acquired type declarations. These files are downloaded on user machine to power JavaScript intelligence and never uploaded anywhere.
What are the paths that are used for this cache on the different platforms? I think on Linux it might make sense to used a folder name with a leading '.' to hide it from default and file explorer behavior - like other tools do. /cc
Now that you mention this I have this too. We should absolutely not be putting the types in . would probably make the most sense, where defaulting to if it is not defined as per the . I'm proposing instead of to prevent potential future conflicts. this is actually quite bad imo, is this a purely upstream problem?
This issue was moved to Microsoft/TypeScript
Let's keep this open on vscode to track it. I'd like to mention the fix in release notes when it comes.
This is going into TypeScript 2.2, so we will not be picking it up in VSCode 1.8. You can install a TS 2.2 insiders build to your workspace to work around this for now.
Change:
import { IExtensionService } from 'vs/workbench/services/extensions/common/extensions'; import { LifecyclePhase } from 'vs/workbench/services/lifecycle/common/lifecycle'; import { KeybindingsEditorInput } from 'vs/workbench/services/preferences/browser/keybindingsEditorInput'; <del> import { IPreferencesService } from 'vs/workbench/services/preferences/common/preferences'; </del> <ins> import { DEFINE_KEYBINDING_EDITOR_CONTRIB_ID, IDefineKeybindingEditorContribution, IPreferencesService } from 'vs/workbench/services/preferences/common/preferences'; </ins> import { SettingsEditor2Input } from 'vs/workbench/services/preferences/common/preferencesEditorInput'; import { IUserDataProfileService, CURRENT_PROFILE_CONTEXT } from 'vs/workbench/services/userDataProfile/common/userDataProfile'; import { IUserDataProfilesService } from 'vs/platform/userDataProfile/common/userDataProfile'; <ins> import { isCodeEditor } from 'vs/editor/browser/editorBrowser'; </ins> const SETTINGS_EDITOR_COMMAND_SEARCH = 'settings.action.search';

Discussion:
With there is a new -menu which a big blue buttons. This is used in the merge editor and to hint to open the merge editor. This new menu should be used for: [x] [ ] ~~ / [x] [ ]
Other potential adoptors [ ] [ ] [ ] [ ]
Digging into it, I don't think can be adopted for the diff editor, as the button should be for both editors, not only the right side ( is a , but is ).
Change:
*/ export interface IEditorPartsView { <del> /** * An array of all editor groups across all editor parts. */ readonly groups: IEditorGroupView[]; </del> <ins> readonly mainPart: IEditorGroupsView; </ins> <del> /** * Get the group based on an identifier across all opened * editor parts. */ </del> <ins> readonly activeGroup: IEditorGroupView; readonly groups: IEditorGroupView[]; </ins> getGroup(identifier: GroupIdentifier): IEditorGroupView | undefined; <ins> mergeGroup(group: IEditorGroupView, target: IEditorGroupView, options?: IMergeGroupOptions): IEditorGroupView; </ins> } /**

Discussion:
Testing It would be great if we can have a command to bring back those editors to the main window.
I think that should actually be the default behaviour when you just close the window. That will prevent ugly confirmation dialogs for dirty editors when you attempt to close the floating window.
Verification: open a floating window with some editors (e.g. by dragging an editor tab out of the window) close the floating window, e.g. from the X window button verify all editors of the floating window are moved back to the main window