jiebi/CodeConvo huggingface dataset:
Code change:
const extension = await this.toScannedExtension(webExtension, true); if (extension.isValid || !scanOptions?.skipInvalidExtensions) { result.push(extension); <ins> } else { this.logService.info(`Skipping invalid additional builtin extension ${webExtension.identifier.id}`); </ins> } } catch (error) { this.logService.info(`Error while fetching the additional builtin extension ${location.toString()}.`, getErrorMessage(error));

Related discussion:
text: Each machine remembers what builtin extensions it syncs and make sure it won't remove them while syncing. Also some logs to get more information if the issue still occurs.
If I uninstall GHPRI from desktop and then Sync Now in , the extension appears to be 'uninstalled' on , is that expected? ! After reloading the extension is still installed though.
I don't have a second desktop to verify with at the moment.
Yeah in your case it is expected because, GHPRI extension seems to be user installed and settings sync is removing that.
Code change:
integrity sha512-ynEGytvgTb6HVSUwPJIAZgiHQmPCx8bZ8w5um5Lz+q5DjP0Zj8wTFhQpyg8xaMvefDytw2+HH5yzqS+FhsR28A== vscode-languageserver-types@^3.15.1: <del> version "3.16.0" resolved "https://registry.yarnpkg.com/vscode-languageserver-types/-/vscode-languageserver-types-3.16.0.tgz#ecf393fc121ec6974b2da3efb3155644c514e247" integrity sha512-k8luDIWJWyenLc5ToFQQMaSrqCHiLwyKPHKPQZ5zz21vM+vIVUSvsRpcbiECH4WR88K2XZqc4ScRcZ7nk/jbeA== vscode-nls@^5.0.0: version "5.0.0" resolved "https://registry.yarnpkg.com/vscode-nls/-/vscode-nls-5.0.0.tgz#99f0da0bd9ea7cda44e565a74c54b1f2bc257840" integrity sha512-u0Lw+IYlgbEJFF6/qAqG2d1jQmJl0eyAGJHoAJqr2HT4M2BNuQYSEiSE75f52pXHSJm8AlTjnLLbBFPrdz2hpA== </del> <ins> version "3.17.2" resolved "https://registry.yarnpkg.com/vscode-languageserver-types/-/vscode-languageserver-types-3.17.2.tgz#b2c2e7de405ad3d73a883e91989b850170ffc4f2" integrity sha512-zHhCWatviizPIq9B7Vh9uvrH6x3sK8itC84HkamnBWoDFJtzBf7SWlpLCZUit72b3os45h6RWQNC9xHRDF8dRA== </ins> vscode-uri@^2.1.2: version "2.1.2"

Related discussion:
text: Similar to but for libraries... Here are the docs for : <!-- 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. -- (, ) (, Needs version bump)
The HTML/CSS/JSON services are now all using adds the code to configure the servers with location of the localization bundle
Code change:
let match = url.match(SshProtocolMatcher); if (match) { return stripLowLevelDomains(match[2]); <ins> } else { return null; </ins> } } try {

Related discussion:
text: Repro: Open DevTools: !
This started occurring recently due to It is now possible to get this warning from various parts of the product.
Yes. That's on purpose and the goal is to get rid of invalid URIs in our system. So, when your code causes such warnings, you need to change it ;-). I can consult. The background is that an URI must have a scheme but we never enforced that. The warning I have is the first step into that direction.
The warning is valid. We're passing a path to , which is wrong. Git remote addresses are not always uris, they can be paths; even relative paths.
So the consumers of should beforehand check if what they are passing is valid uri or not? Doesnt that fail the purpose of ? is used to parse json content. We can pass non json to it as well. It throws an error. Can we not expect something similar from ? If we are worried that throwing errors will break existing code, then can we have a stricter that we can use?
Yes, parse will throw an error but it never used to do that for missing scheme. I didn't think it's a good idea to now start throwing errors at first because not everyone encloses in a try catch block and also often people confuse and .
Code change:
.extension-list-item > .details > .description { padding-right: 11px; <ins> line-height: normal; </ins> color: var(--vscode-descriptionForeground); }

Related discussion:
text: While helping Marketplace improve extension search I noticed that for most queries there are no more than 5 good results. And we currently show an infinite list which depending on Monitor size would show 10 - 20 extensions. Also we sometimes struggle with the small size of extension items in the list - not enough space for all the decorations we would like to render. Based on the two above, I suggest we explore with increasing the vertical size of the extension items in the list. Ideally this would allow to present the information in a cleaner way when users search for extensions. I am not sure how this would effect the list of installed and recommended extensions. Ideally we would also increase the size of those to be consistent, but for those cases I am not convinced if it would be a win. what do you think? for ux thoughts Example from my screen !
From a visual standpoint it makes sense to explore giving these some breathing room. As far as solving for quality results, I don't know if making them bigger will necessarily solve that problem alone. It could be that we have a sort of "Top Results" section up top with the remaining results in another section. Just one idea off the top of my head.
I agree its worth exploring it give more space for an extension in the viewlet. But this might impact if the size of the screen is smaller.
We closed this issue because we in the foreseeable future. If you disagree and feel that this issue is crucial: we are happy to listen and to reconsider. If you wonder what we are up to, please see our and . Thanks for your understanding, and happy coding!
I see this is merged and should be latest VS Code Insiders but I do not see any changes in my VS Code Insiders. am I missing something here?
I'm seeing the latest after updating: <img width="320" alt="CleanShot 2023-01-03 at 08 48 48 src="https://user-"<img width="328" alt="CleanShot 2023-01-03 at 08 49 32 src="https://user-"
I just got the update. Looks ok to me - I will need some time to adjust. Let's see what insiders users and the rest of the team says :)
Code change:
return; } <ins> if (e.browserEvent.defaultPrevented) { return; } </ins> const focus = this.list.getFocus(); this.list.setSelection(focus, e.browserEvent); <ins> e.browserEvent.preventDefault(); </ins> } private changeSelection(e: IListMouseEvent<T> | IListTouchEvent<T>): void {

Related discussion:
text: see gif open GH notebook with a few cell that reference a variable run peek references and select entries notice how notebook cells are being highlighted, like "Milestone Work" get selected !
I can repro in Insiders but not master, I'll check again tomorrow
This happens because of this listener: Tho, not yet sure why the selection keeps changing... Maybe some inner list event (from the references list) bubbles up to the outer list
That listener is fine, it's the nested lists
Hey do you have any thoughts on handling this? We have a list inside another list. The inner list handles the touch event properly. The outer list then handles the event and picks up the wrong index because it finds the data attribute inside the inner list in We can Make sure the event is fired on the outer list with the correct element, by fixing to check whether it's in the right list Not fire the event on the outer list at all, when we see that it originates in a different list Add some property to the list event that says it originated in a different list so the consumer can decide In this particular case, I think any of these are fine
Thinking more, I don't think that the event should ever be handled by two lists at all. Meaning we either mark the browserEvent as handled, like with preventDefault/isDefaultPrevented, or we make the list check every event to be sure that it originated in this list.
This sounds good to me. This also sounds good to me.
related when I do peek references, I see markdown cells being selected? ! Notice I'm looking for under-discussion but "Configure" is being highlighted as one of the references
From Good catch, I didn't notice that
Thanks for the quick handling!
Code change:
import { IChatEditorOptions } from 'vs/workbench/contrib/chat/browser/chatEditor'; import { ChatEditorInput } from 'vs/workbench/contrib/chat/browser/chatEditorInput'; import { ChatViewPane } from 'vs/workbench/contrib/chat/browser/chatViewPane'; <del> import { ChatAgentLocation } from 'vs/workbench/contrib/chat/common/chatAgents'; import { CONTEXT_CHAT_ENABLED, CONTEXT_CHAT_INPUT_CURSOR_AT_TOP, CONTEXT_CHAT_LOCATION, CONTEXT_IN_CHAT_INPUT, CONTEXT_IN_CHAT_SESSION } from 'vs/workbench/contrib/chat/common/chatContextKeys'; </del> <ins> import { CONTEXT_CHAT_ENABLED, CONTEXT_CHAT_INPUT_CURSOR_AT_TOP, CONTEXT_IN_CHAT_INPUT, CONTEXT_IN_CHAT_SESSION } from 'vs/workbench/contrib/chat/common/chatContextKeys'; </ins> import { IChatDetail, IChatService } from 'vs/workbench/contrib/chat/common/chatService'; import { IChatRequestViewModel, IChatResponseViewModel, isRequestVM } from 'vs/workbench/contrib/chat/common/chatViewModel'; import { IChatWidgetHistoryService } from 'vs/workbench/contrib/chat/common/chatWidgetHistoryService';

Related discussion:
text: Testing Repro: /explain in inline chat to get a long response. using to focus the last response (does not work) to focus the last response using to scroll up in list view of chat messages. (does not work)
Same for panel chat. I believe the keybinding simply isn't bound
You may have to press it twice, once to move the cursor to the top of the editor, and then another time to trigger the chat keybinding, does that work? It's working fine for me.
Oh, not in inline chat though
I can't remember what terminal chat looked like in March, do you still want this disabled? I think we probably want it enabled in all chat widgets now:
I fixed this so that cmd+up/down will work in the terminal and inline chat widgets. But in the terminal, once the list is focused, then the arrow keys still navigate history. It looks like the terminal widget is registering a bunch of its own commands for history and for moving focus around. You shouldn't need to do that anymore, since you can use the commands that the ChatWidget has.
Code change:
private _startBarrier: Barrier; private _persistentTerminalId: number; <ins> public get id(): number { return this._persistentTerminalId; } </ins> private _inReplay = false; constructor( <del> readonly id: number, </del> <ins> private readonly _instanceId: number, </ins> readonly shouldPersist: boolean, private readonly _shellLaunchConfig: IShellLaunchConfig, private readonly _activeWorkspaceRootUri: URI | undefined,

Related discussion:
text: We should filter out the terminal if this is undefined, otherwise bad bugs like could happen where we restore a terminal into the wrong window: The chances of this happening are pretty slim so not doing this in Feb.
Falling back to 0 as it has been seems to work well, if we need to handle this on reconnect we will have a persistentProcessId of 0 which isn't valid anyway.
Code change:
if (OpenPrivacyStatementUrlAction.AVAILABE) { registerAction2(OpenPrivacyStatementUrlAction); } <ins> registerAction2(GetStartedWithAccessibilityFeatures); </ins>

Related discussion:
text: Screen reader and low vision (or other accessibility) users often use our menu items to discover things. We should include a menu item to open the getting started walkthrough under .
and WDYT?
Seems reasonable to me. The title suggests that it could also be a walkthrough, or part of an existing walkthrough. The tradeoff there would be discoverability.
I see an error in the console when opening accessible view from that welcome experience:
Cc
Related:
Code change:
export const statesInOrder = Object.keys(statePriority).map(s => Number(s) as TestResultState).sort(cmpPriority); export const isRunningState = (s: TestResultState) => s === TestResultState.Queued || s === TestResultState.Running; <ins> /** * Some states are considered terminal; once these are set for a given test run, they * are not reset back to a non-terminal state, or to a terminal state with lower * priority. */ export const terminalStatePriorities: { [key in TestResultState]?: number } = { [TestResultState.Passed]: 0, [TestResultState.Skipped]: 1, [TestResultState.Failed]: 2, [TestResultState.Errored]: 3, }; </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. --<!-- 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.64.0-insider () In the Catch2 C++ test framework it is possible to have multiple test results for the same test in one run. This happens for example for the following code: In this scenario, the section "S" is run twice, and the first time it fails, the second time it succeeds. The C++ TestMate extension will see the two test runs, and call for the first one, and for the second, with the same for both calls. This results in the confusing display that the section is green, even though it shows a failure inside: <img width="653" alt="image" src="https://user-" does it make sense to change and (et al) so that when called multiple times, it sets the item's state to the max of the old and the new state? This seems to be analogous to what happens with the test messages (they are appended, and doesn't clear them). Or would you say it's the extension's responsibility to not set the state more than once for a given TestItem? (Cc Or maybe it is even Catch2's responsibility to accumulate the results for any section that is run more than once?
IMHO, Catch2 reports it and definitely not the responsibility of vscode. It leaves it to me.. (Though I don't know how I can solve this properly)
Why definitely? It doesn't seem so unreasonable to me. As I said, it already does something similar with the test messages.
As I think of it, vscode part is just the UI, the controlling is in my hand. More precisely and . the test provider is the .
Code change:
export const statesInOrder = Object.keys(statePriority).map(s => Number(s) as TestResultState).sort(cmpPriority); export const isRunningState = (s: TestResultState) => s === TestResultState.Queued || s === TestResultState.Running; <ins> /** * Some states are considered terminal; once these are set for a given test run, they * are not reset back to a non-terminal state, or to a terminal state with lower * priority. */ export const terminalStatePriorities: { [key in TestResultState]?: number } = { [TestResultState.Passed]: 0, [TestResultState.Skipped]: 1, [TestResultState.Failed]: 2, [TestResultState.Errored]: 3, }; </ins>

Related discussion:
text: I'm not so sure in this case. VS Code is also responsible for setting T's state correctly, you don't do that at all (as far as I'm aware). And note that it gets that one right, so it has some logic already for computing the resulting state of all child runs if there are multiple for the same item.
I would be very interested in your opinion on this.
Yea, I think it would be reasonable to no-op if the extension tries to change the test state to one with a lower priority. For instance, going from passed-skipped or failed-passed.
can you add some steps?
the test sample: this block F5.Verify that, with these changes, test that should pass remain passed in the UI, and tests that failed remain failed.
Code change:
renderedWordCount: wordCountResult.actualWordCount, lastRenderTime: Date.now(), isFullyRendered: wordCountResult.isFullString, <ins> originalMarkdown: part.content, </ins> }; wordCountResults[index] = wordCountResult; } else if (!renderedPart.isFullyRendered && !wordCountResult) {

Related discussion:
text: Steps: extension that registers a document and a document range formatting provider open a test workspace that activates the extension and trigger a range format. You get:
Code change:
constructor(private repository: Repository) { this.disposables.push( window.registerFileDecorationProvider(this), <del> repository.onDidRunGitStatus(this.onDidRunGitStatus, this) </del> <ins> runAndSubscribeEvent(repository.onDidRunGitStatus, () => this.onDidRunGitStatus()) </ins> ); }

Related discussion:
text: Testing When turning off , the decorations disappear. When turning back on, they do not reappear automatically. !
Code change:
const message = localize('confirm force delete branch', "The branch '{0}' is not fully merged. Delete anyway?", name); const yes = localize('delete branch', "Delete Branch"); <del> const pick = await window.showWarningMessage(message, yes); </del> <ins> const pick = await window.showWarningMessage(message, { modal: true }, yes); </ins> if (pick === yes) { await run(true);

Related discussion:
text: The new notifications pop open at the lower right corner of the editor. Some command palette actions pop these up with a button that I need to click on to proceed. In these cases, I have to move my mouse from the top center of the window down to the bottom right corner of the window. One such example is the "Git: Delete branch" command. I have to click on the branch I want to delete from the drop down selector, then click the notification button far away in the corner to confirm the delete. If I am deleting multiple branches at a time (because I'm finally cleaning up my local state ) I have to move the mouse back and forth a ton of times so now I use a terminal for this task instead. It would be nice to have an option that lets me decide where I want the notifications to appear. I would choose the top right corner to reduce mouse movement.
I'll narrow this issue down to make the delete branch popup a modal one, which it should be anyways.
I'm trying to repro, but don't get any such popup after selecting a branch to delete. The branch is instantly deleted. I'm on Mac OS X 10.11.16, vscode version 1.21.1
Code change:
private async updateCustomBuiltinExtensionsCache(): Promise<IWebExtension[]> { if (!this._updateCustomBuiltinExtensionsCachePromise) { this._updateCustomBuiltinExtensionsCachePromise = (async () => { <del> // Clear Cache await this.writeCustomBuiltinExtensionsCache(() => []); const { extensions } = await this.readCustomBuiltinExtensionsInfoFromEnv(); if (!extensions.length) { return []; } const galleryExtensionsMap = await this.getExtensionsWithDependenciesAndPackedExtensions(extensions); const missingExtensions = extensions.filter(({ id }) => !galleryExtensionsMap.has(id.toLowerCase())); if (missingExtensions.length) { this.logService.info('Skipping the additional builtin extensions because their compatible versions are not found.', missingExtensions); } </del> <ins> this.logService.info('Updating additional builtin extensions cache'); </ins> const webExtensions: IWebExtension[] = []; <del> await Promise.all([...galleryExtensionsMap.values()].map(async gallery => { try { webExtensions.push(await this.toWebExtensionFromGallery(gallery, { isPreReleaseVersion: gallery.properties.isPreReleaseVersion, preRelease: gallery.properties.isPreReleaseVersion, isBuiltin: true })); } catch (error) { this.logService.info(`Ignoring additional builtin extension ${gallery.identifier.id} because there is an error while converting it into web extension`, getErrorMessage(error)); </del> <ins> const { extensions } = await this.readCustomBuiltinExtensionsInfoFromEnv(); if (extensions.length) { const galleryExtensionsMap = await this.getExtensionsWithDependenciesAndPackedExtensions(extensions); const missingExtensions = extensions.filter(({ id }) => !galleryExtensionsMap.has(id.toLowerCase())); if (missingExtensions.length) { this.logService.info('Skipping the additional builtin extensions because their compatible versions are not found.', missingExtensions); </ins> } <del> })); </del> <ins> await Promise.all([...galleryExtensionsMap.values()].map(async gallery => { try { webExtensions.push(await this.toWebExtensionFromGallery(gallery, { isPreReleaseVersion: gallery.properties.isPreReleaseVersion, preRelease: gallery.properties.isPreReleaseVersion, isBuiltin: true })); } catch (error) { this.logService.info(`Ignoring additional builtin extension ${gallery.identifier.id} because there is an error while converting it into web extension`, getErrorMessage(error)); } })); } </ins> await this.writeCustomBuiltinExtensionsCache(() => webExtensions); return webExtensions; })();

Related discussion:
text: Each machine remembers what builtin extensions it syncs and make sure it won't remove them while syncing. Also some logs to get more information if the issue still occurs.
If I uninstall GHPRI from desktop and then Sync Now in , the extension appears to be 'uninstalled' on , is that expected? ! After reloading the extension is still installed though.
I don't have a second desktop to verify with at the moment.
Yeah in your case it is expected because, GHPRI extension seems to be user installed and settings sync is removing that.
Code change:
import { DisassemblyViewInput } from 'vs/workbench/contrib/debug/common/disassemblyViewInput'; import { DebugLifecycle } from 'vs/workbench/contrib/debug/common/debugLifecycle'; import { Icon } from 'vs/platform/action/common/action'; <ins> import { EditorContextKeys } from 'vs/editor/common/editorContextKeys'; </ins> const debugCategory = nls.localize('debugCategory', "Debug"); registerColors();

Related discussion:
text: When I press Ctrl+Shift+P to open the command panel and type "", it shows "No matching commands". So I can't execute this command by Ctrl+Shift+P. I can only bind a shortcut key to this command and then execute it via the shortcut key. I think this is a bug that the command panel search is incomplete.
Please edit this issue title to become:
indicates it may already be there and you just need to know what the command text is.
OK, but according to my observation, there are other commands that cannot be found in the panel. For example, "".
The issue I raised is different from him. His issue is that the shortcut key does not work after binding. My issue is that I can't find the command in the command panel. In fact, some other commands cannot be found, indicating that the search of the command panel is incomplete.
Some commands never appear in the Command Palette because they define their clause as
I open the page where I set the keyboard shortcut and see that their when clause is - not false.
Sorry, I wasn't clear. This is what I am referring to.
I read your link and I probably understand. Please set the when clause of "" to "inDebugMode" instead of false. This is more in line with our needs.
Looks like that command is missing from here: is also missing.
/confirm
I will submit a PR
Thanks!