jiebi/CodeConvo huggingface dataset:
Change:
</head> <body style="margin: 0; overflow: hidden; width: 100%; height: 100%" role="document"> <ins> <!-- TODO: Remove additional script tag once Firefox is fixed https://bugzilla.mozilla.org/show_bug.cgi?id=1737882 --> <script></script> </ins> <script async type="module"> // @ts-check /// <reference lib="dom" />

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.75.0 OS Version: Windows 10 Browser: Firefox 109.0.1 Commit: Date: 2023-02-01T15:20:55.110Z Steps to Reproduce: in Firefox Extensions (Ctrl+Shift+X) an extension to display details Additional Details: Webviews do not display in Firefox version 109.0.1. There are several errors that appear in the browser's console. Here's a copy of my logs: Additionally, each time a webview is opened, the following warning appears in the console: This seems to impact all webviews. The easiest place to see the bug is in the extensions interface. Here I have tried to view details about an extension, but the webview that displays those details does not load: Extension details in Firefox 109.0.1 <img width="1792" alt="Screen Shot 2023-02-06 at 4 43 30 PM" src="https://user-"Expected behavior (Google Chrome) <img width="1792" alt="Screen Shot 2023-02-06 at 4 47 08 PM" src="https://user-"
This also affects the markdown file preview, and started Feb 3rd.
Change:
"main": "./out/htmlServerMain", "dependencies": { "vscode-css-languageservice": "^3.0.13-next.6", <del> "vscode-html-languageservice": "^2.1.11-next.3", </del> <ins> "vscode-html-languageservice": "^2.1.11-next.4", </ins> "vscode-languageserver": "^5.1.0", "vscode-languageserver-types": "^3.13.0", "vscode-nls": "^4.0.0",

Discussion:
Semantic selections: LSP: works CSS/SCSS/LESS: doesn't work, but it works in Atom. Probably need to update our dependencies. The plan now is to use emmet's "balance" commands. The challenge is that HTML/CSS language service need to include emmet. Alternatively, we can implement these commands ourselves.
Please review the animated gifs in the original thread: Seems to me the emmet functionality as it stands is wholly inadequate.
This will be available in tomorrow's insiders: !
is this suppose to work in Javascript? It's not nearly as functional as Webstorm. Also fails dramatically with HTML in .Vue files. Oh well.
Vue — it'll be available once we update the dependencies. JavaScript — we'll need to wait for TypeScript to add the semantic selection. I don't have any estimate.
Change:
this._register(this.list); this._register(this.listLabels); <ins> // Register the refresh scheduler let labelChangeListeners: IDisposable[] = []; this.listRefreshScheduler = this._register(new RunOnceScheduler(() => { // No need to refresh the list if it's not rendered if (!this.list) { return; } labelChangeListeners = dispose(labelChangeListeners); const previousLength = this.list.length; const elements = this.getElements(); this.list.splice(0, this.list.length, elements); this.focusActiveEditor(); if (previousLength !== this.list.length) { this.updateSize(); } this.needsRefresh = false; if (this.sortOrder === 'alphabetical' || this.sortOrder === 'fullPath') { // We need to resort the list if the editor label changed elements.forEach(e => { if (e instanceof OpenEditor) { labelChangeListeners.push(e.editor.onDidChangeLabel(() => this.listRefreshScheduler?.schedule())); } }); } }, this.structuralRefreshDelay)); </ins> this.updateSize(); // Bind context keys

Discussion:
it needs the to work but that only comes in when is called then why is the scheduler not created from and associated code that calls it? the scheduler is never disposed
Change:
"Failed to update keyring with new credentials: {}", e ); <ins> if let Some(fb) = storage.fallback_storage.take() { storage.storage = Box::new(fb); match storage.storage.store(creds.clone()) { Err(e) => { warning!(self.log, "Also failed to update fallback storage: {}", e) } Ok(_) => debug!(self.log, "Updated fallback storage successfully"), } } </ins> } storage.last_read.set(Ok(Some(creds))); }) }

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?: Not sure. I run "code tunnel" without opening the UI. <!-- 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.80.0 OS Version: Ubuntu 22.04 LTS Steps to Reproduce: Install VSCode or Code Cli on Ubuntu Desktop 22.04 "code tunnel" on Ubuntu. server license terms and login to and enter the code. tunnel will show: . VSCode tunnel and rerun "code tunnel". It will ask for GitHub authentication again, because it failed to update keyring.
Seems to duplicate the upstream issue on To work around this, you can set the environment variable (e.g. by running and reconnecting). But this seems fairly common, we should automatically use a file keychain if we get this error.
Hi Connor, Thanks for your help! It would be wonderful if the error can be automatically dealt with since many people don't know the environment variable.
yes,
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Putting in a new line in does the trick for me. (putting the env var in a global file ensures that it will be defined regardless of where it's running or who is running it; note that on some systems this may be a massive security hole)
I now see this in insiders: and then when I restart: looks verified to me.
Change:
if (!this._editor) { const that = this; this._editor = { <del> get document() { return that.notebookData.apiNotebook; }, </del> get notebook() { return that.notebookData.apiNotebook; },

Discussion:
The has been finalized with VS Code 1.68 (). If your extension was using the proposal, you should now switch to the finalized version of this API. In the majority of cases, this switch is as simple as: your extension to target VS Code in the new from your list of enabled API proposal. However there are few small bumps to be aware of: has been renamed . Please make sure to switch over to the new property name as part of this migrationWe did not finalize the version of that takes a uri. Instead you can use Here's a list of all current consumers of the old API proposal: [x] ms-vsliveshare.vsliveshare — [X] ms- — [x] Dot net interactive — [x] GitHub.codespaces — [x] ms- — If you own one of these extensions, please migrate to the finalized notebook editor API. Let me know once the new version of your extension is published and I will remove your extension from the list of api consumers
I am actually fine in ESLint. The dependency was because of notebook support in LSP and LSP already converted to the final version for the 8.x release of the LSP libs.
Thank you everyone who's checked off their extension so far! If you have, I plan to remove your extension from the list of API consumers in July. This will only start effecting the insiders builds of VS Code at first, but please let me know if you notice any issues
I'm working on the change for Codespaces and expect it to be in our next extension release (1.10.0) in a few days. I'll reply back once it's on the marketplace.
We just published GitHub Codespaces 1.10.0 with this change, so you should be able to remove our extension from the list of proposed API consumers.
Change:
import { IProductService } from 'vs/platform/product/common/productService'; import { IStorageService, StorageScope } from 'vs/platform/storage/common/storage'; import { IOpenerService } from 'vs/platform/opener/common/opener'; <ins> import { timeout } from 'vs/base/common/async'; </ins> const enum AuthStatus { Initializing = 'Initializing',

Discussion:
Steps to Repro Set up settings sync - Follow instructions Turn on Sync From the gear icon, select entry Quick pick is shown. From the quick pick click on entry Quick pick with wrong selected items is shown <img width="631" alt="image" src="https://user-"Expected: <img width="632" alt="image" src="https://user-"Note: Expected is shown when you use keyboard to select entry. It happens only when you use mouse and click.
There is a change event on the checkbox from the mouse up on the entry. I don't have a fix in QuickInput currently, can we change to: That appears to let the mouse up pass without triggering the change event on the checkbox.
Is this a temp workaround and do you have plans to fix it in quick pick later?
It’s certainly a workaround. I don’t have a proper fix yet.
Change:
this.multiSessionDebug = CONTEXT_MULTI_SESSION_DEBUG.bindTo(contextKeyService); this.terminateDebuggeeSuported = CONTEXT_TERMINATE_DEBUGGEE_SUPPORTED.bindTo(contextKeyService); this.disassembleRequestSupported = CONTEXT_DISASSEMBLE_REQUEST_SUPPORTED.bindTo(contextKeyService); <ins> this.focusedStackFrameHasInstructionPointerReference = CONTEXT_FOCUSED_STACK_FRAME_HAS_INSTRUCTION_POINTER_REFERENCE.bindTo(contextKeyService); </ins> }); }

Discussion:
Testing As already pointed out The "Open Disassembly View" command is now only visible when the active stackframe has a instructionPointerReference property. This makes it hard to discover. I suggest to have the context menu's "Open Disassembly View" command always visible if a debug adapter has the supportsDisassembleRequest capability. But the command should only be enabled if the active stackframe has a instructionPointerReference property. That results in a more stable user experience. Apart from that we should have the Open Disassembly View command in the command palette.
That's a fair suggestion. However, we are not sure how to disable a command...
commands have clauses and . clause determines if the command is present at all and if it is disabled. So please use the when registering the editor command for disablement.
Also we should consider to introduce a call stack context menu action for the Open Disassembly View.
will fix this.
Change:
if (configuration.brackets) { richEditConfig.brackets = configuration.brackets; <ins> } if (configuration.autoClosingPairs) { richEditConfig.__characterPairSupport = { autoClosingPairs: this._mapCharacterPairs(configuration.autoClosingPairs) }; } else if (configuration.brackets) { </ins> richEditConfig.__characterPairSupport = { <del> autoClosingPairs: configuration.brackets.map(pair => { let [open, close] = pair; return { open: open, close: close }; }) </del> <ins> autoClosingPairs: this._mapCharacterPairs(configuration.brackets) </ins> }; } <ins> if (richEditConfig.__characterPairSupport && configuration.surroundingPairs) { richEditConfig.__characterPairSupport.surroundingPairs = this._mapCharacterPairs(configuration.surroundingPairs); } </ins> this._modeService.registerRichEditSupport(modeId, richEditConfig); } <ins> private _mapCharacterPairs(pairs:CharacterPair[]): IAutoClosingPair[] { return pairs.map(pair => { let [open, close] = pair; return { open: open, close: close }; }); } </ins> }

Discussion:
I have editor.autoClosingBrackets set to true but it seems it works stricly with brackets. I guess autoclosing single/double quotes is not implemented yet? If not, please do it. I think it is a common feature for every editor.
What language is missing them?
Closing after a number of days without a reply.
Change:
} registerEditorContribution(LinkDetector.ID, LinkDetector, EditorContributionInstantiation.AfterFirstRender); <del> registerEditorContribution(LinkOpener.ID, LinkOpener, EditorContributionInstantiation.Lazy); </del> registerEditorAction(OpenLinkAction);

Discussion:
The content of the line: Open definition does nothing !
Also happens on Mac with Cmd+Click. Makes it very difficult to navigate my documentation.
I believe this is a result of fixing Markdown has a link provider and a definition provider. However in this case, the definition provider returns since we are not on a reference link
revert of the bad change is up
Change:
} private _disposeOfWebglRenderer(): void { <del> this._webglAddon?.dispose(); </del> <ins> try { this._webglAddon?.dispose(); } catch { // ignore } </ins> this._webglAddon = undefined; }

Discussion:
Part of We should also improve the fallback logic to do this: Try webgl If it threw an exception, try canvas If frame rendering averages 50ms (existing detection), use DOM We will keep the canvas renderer around for now mainly because Safari doesn't support webgl2 and can evaluate again at a later date.
It looks like canvas is still the default for me -- the is present unless I explicitly enable experimentalWebgl. I don't see any notifications of errors that could be causing it.
Change:
TestingViewAsTreeAction, ToggleInlineTestOutput, UnhideTestAction, <ins> UnhideAllTestsAction, </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. --I would like to run all the tests from the task. However, if there is a hidden test (e.g. by mistake), that test will not be executed. Is it possible to make work from task? Or if there is a command that ignores the hidden ones and runs all tests, that would be fine.
It looks like expects some arguments but you're looking for a command that unhides all instead.
Code pointer for the existing action:
Should there be a new command to unhide all tests say testing.hideAll or a task to run all tasks including hidden tests - testing.runAllIncludingHidden?
Yes! please.
Verified it unhides all hidden tests.
Change:
/** * Editor background color. <del> * Because of bug https://monacotools.visualstudio.com/DefaultCollection/Monaco/_workitems/edit/13254 * we are *not* using the color white (or #ffffff, rgba(255,255,255)) but something very close to white. </del> */ <del> export const editorBackground = registerColor('editor.background', { light: '#fffffe', dark: '#1E1E1E', hcDark: Color.black, hcLight: Color.white }, nls.localize('editorBackground', "Editor background color.")); </del> <ins> export const editorBackground = registerColor('editor.background', { light: '#ffffff', dark: '#1E1E1E', hcDark: Color.black, hcLight: Color.white }, nls.localize('editorBackground', "Editor background color.")); </ins> /** * Editor foreground color.

Discussion:
Please could someone provide a summary of what this bug is and why the color white cannot be used? (I'm wondering if using it will cause problems in our project) I'm unable to view the link in the comment as I don't have access to the project: Screenshot: ! Many thanks
Do you remember more about
I believe that was some IE limitation from back in the days and not needed anymore. Adding for a trip down memory-lane. do answer you question: No, using white shouldn't cause any issue
Yes, this was a workaround for an old IE version. We can remove this safely.
Change:
}; const preferredHCDarkThemeSettingSchema: IConfigurationPropertySchema = { type: 'string', <del> markdownDescription: nls.localize({ key: 'preferredHCDarkColorTheme', comment: ['`#{0}#` will become a link to an other setting. Do not remove backtick or #'] }, 'Specifies the preferred color theme used in high contrast dark mode when `#{0}#` is enabled.', ThemeSettings.DETECT_HC), </del> <ins> markdownDescription: nls.localize({ key: 'preferredHCDarkColorTheme', comment: ['{0} will become a link to another setting.'] }, 'Specifies the preferred color theme used in high contrast dark mode when {0} is enabled.', formatSettingAsLink(ThemeSettings.DETECT_HC)), </ins> default: ThemeSettingDefaults.COLOR_THEME_HC_DARK, enum: colorThemeSettingEnum, enumDescriptions: colorThemeSettingEnumDescriptions,

Discussion:
open the settings, in the filter box enter . Check the settings description. It should contain links. The links use a special syntax: that must not be changed. The translated string has a message mentioning that. !
Thank you for your feedback. We are currently reviewing it (reference ).
could you please lock the placeholders with these annotations? I'll fix the local translation meanwhile.
I've got a fix out ^^
Verified in code while the translation is in work.
Change:
private _onDidChange = new vscode.EventEmitter<vscode.Uri>(); private _waiting: boolean; <del> constructor(private engine: MarkdownEngine, private context: vscode.ExtensionContext) { </del> <ins> constructor( private engine: MarkdownEngine, private context: vscode.ExtensionContext ) { </ins> this._waiting = false; }

Discussion:
The current behaviour of Code's Markdown previewer when clicking a relative link is actually a bit cryptic: it attempts to open the file relative to the user's home path with the system's application of choice. This will commonly lead to errors being dispatched because the file cannot be found. If I have the following Markdown: Clicking the link will make my system attempt to open . Given that even , I strongly believe that they should be supported here. Such links should instead be relative to the markdown file's directory and open the linked file using the Code editor.
+1; opening markdown files by clicking a (relative) link in the preview would be a very powerful feature both for writing developer documentation (split into individual files by topic) for a project, but also for viewing that documentation.
Related: Is this behavior something vscode could change for its markdown preview?
Change:
import { RunOnceScheduler } from 'vs/base/common/async'; import * as env from 'vs/base/common/platform'; import { visit } from 'vs/base/common/json'; <ins> import { setProperty } from 'vs/base/common/jsonEdit'; </ins> import { Constants } from 'vs/base/common/uint'; import { KeyCode } from 'vs/base/common/keyCodes'; import { IKeyboardEvent } from 'vs/base/browser/keyboardEvent';

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.44.0 OS Version: Win 10 1909, .720 Steps to Reproduce: a multi root workspace panel -Add configuration (workspace)... Expected to see a dropdown list showing supported debug configurations (just like in single root mode). Actual behavior is that only the .code-workspace file gets focus. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
Aha, for the the Add configuration (workspace) you would like the debug configuration providers to be called. This is a fair feature request, however not on the immedaite plan thus assigning to backlog. We would be open to a pr that adds this. If you are intersted let me know and I can provide a code pointer
Sure I'd like to make the change. And it would be great if you can give me some code pointers.
Here's a code pointer Thanks
After looking at the code, I found that the suggestions wouldn't pop up if the "configurations" field doesn't exist in single root mode as well. So I'm planning to add some code to insert launch configure lines when they don't exist. Since I didn't find anywhere in this code base inserting some texts at a certain position into a file, do you have an example (I think settings is already doing something like this)?
If you have an instance of an you could for example.
Change:
): Proto.ExternalProjectCompilerOptions { const projectConfig: Proto.ExternalProjectCompilerOptions = { module: 'ESNext' as Proto.ModuleKind, <del> moduleResolution: (version.gte(API.v500) ? 'Bundler' : 'Node') as Proto.ModuleResolutionKind, </del> <ins> moduleResolution: 'Node' as Proto.ModuleResolutionKind, </ins> target: 'ES2022' as Proto.ScriptTarget, jsx: 'react' as Proto.JsxEmit, };

Discussion:
Testing This would also enable IntelliSense. The only way I could get it working is by changing the to an , but that then fails at runtime suggesting to use in the
I think this is something in TS. It seems like types recently(?) stopped working in commonjs .js files. For instance, making a new file in the vscode repo doesn't get types for requiring TypeScript. It also doesn't get types for built-in Node modules, in spite of them appearing as completions, even with . ! Intellisense did work in commonjs files when I first made it a few weeks ago.
Change:
scrollTarget.scrollIntoView(); } } else { <del> host.postMessage('did-click-link', node.href); </del> <ins> host.postMessage('did-click-link', node.href.baseVal || node.href); </ins> } event.preventDefault(); break;

Discussion:
This is for . Steps to reproduce: the extension (of version 1.3.2 or up). if necessary. a new document with the following content: the language to “Graphviz (dot)”. “Graphviz: Open Preview to the Side” command. the text in the preview. Expect to be opened in a browser window.