jiebi/CodeConvo huggingface dataset:
Code change:
When installing the extension completes, the message is shown: "Completed installing the extension <publisher.<name. Instead, the extension displayName should be shown. VSCode Version: 1.36 OS Version: Windows 10 !
Currently, is displayed, it would be better if is shown.

Related discussion:
text: .then(extensions => { for (const extension of extensions) { const requireReload = !(extension.local && this.extensionService.canAddExtension(toExtensionDescription(extension.local))); <del> const message = requireReload ? localize('InstallVSIXAction.successReload', "Please reload Visual Studio Code to complete installing the extension {0}.", extension.identifier.id) : localize('InstallVSIXAction.success', "Completed installing the extension {0}.", extension.identifier.id); </del> <ins> const message = requireReload ? localize('InstallVSIXAction.successReload', "Please reload Visual Studio Code to complete installing the extension {0}.", extension.displayName || extension.name) : localize('InstallVSIXAction.success', "Completed installing the extension {0}.", extension.displayName || extension.name); </ins> const actions = requireReload ? [{ label: localize('InstallVSIXAction.reloadNow', "Reload Now"), run: () => this.windowService.reloadWindow()
Code change:
Apparently resolving a string like will work but it will leave the last curly brace. We should disallow this case or throw an error, etc. See
Still seeing some odd behavior (although this may be expected) Repro MacOs : new terminal Bug In the terminal, see: This does not happen if I use a setting such as
Looks like that's a side effect of 'breaking' the path. Nested variables are just no longer interpolated, it's left as:
are those side effects you listed above intended side effects of the change? If so, I see the same thing on codespaces and we can just leave this issue verified. Otherwise, should the issue be moved to the next milestone?
Yes, it's intended that variables that have nested segments are no longer replace. Previously it would have resulted in a malformed string.

Related discussion:
text: export class AbstractVariableResolverService implements IConfigurationResolverService { <ins> static readonly VARIABLE_LHS = '${'; </ins> static readonly VARIABLE_REGEXP = /${(.*?)}/g; declare readonly _serviceBrand: undefined;
Code change:
Apparently resolving a string like will work but it will leave the last curly brace. We should disallow this case or throw an error, etc. See
Still seeing some odd behavior (although this may be expected) Repro MacOs : new terminal Bug In the terminal, see: This does not happen if I use a setting such as
Looks like that's a side effect of 'breaking' the path. Nested variables are just no longer interpolated, it's left as:
are those side effects you listed above intended side effects of the change? If so, I see the same thing on codespaces and we can just leave this issue verified. Otherwise, should the issue be moved to the next milestone?
Yes, it's intended that variables that have nested segments are no longer replace. Previously it would have resulted in a malformed string.

Related discussion:
text: // loop through all variables occurrences in 'value' const replaced = value.replace(AbstractVariableResolverService.VARIABLE_REGEXP, (match: string, variable: string) => { <ins> // disallow attempted nesting, see #77289 if (variable.includes(AbstractVariableResolverService.VARIABLE_LHS)) { return match; } </ins> let resolvedValue = this.evaluateSingleVariable(match, variable, folderUri, commandValueMapping);
Code change:
Apparently resolving a string like will work but it will leave the last curly brace. We should disallow this case or throw an error, etc. See
Still seeing some odd behavior (although this may be expected) Repro MacOs : new terminal Bug In the terminal, see: This does not happen if I use a setting such as
Looks like that's a side effect of 'breaking' the path. Nested variables are just no longer interpolated, it's left as:
are those side effects you listed above intended side effects of the change? If so, I see the same thing on codespaces and we can just leave this issue verified. Otherwise, should the issue be moved to the next milestone?
Yes, it's intended that variables that have nested segments are no longer replace. Previously it would have resulted in a malformed string.

Related discussion:
text: } }); <ins> test('disallows nested keys (#77289)', () => { assert.strictEqual(configurationResolverService!.resolve(workspace, '${env:key1} ${env:key1${env:key2}}'), 'Value for key1 ${env:key1${env:key2}}'); }); </ins> // test('substitute keys and values in object', () => { // 	const myObject = { // 		'${workspaceRootFolderName}': '${lineNumber}',
Code change:
Are there any commands in VScode to navigate "up" or "down" (a folder, directly) in a selection in breadcrumbs? <img width="659" alt="Screen Shot 2019-07-13 at 7 04 55 PM" src="https://user-"
for what the command id is but pressing ArrowLeft does the job for me
The command is actually . It will collapse a node. If already collapsed, it will select the parent. Should we implement a command to simply select the parent?
I can do this and have a try
i make a PR but not very clear about how primary work.
Command is , you'll be able to configure a custom key binding when it's out.

Related discussion:
text: } } }); <ins> KeybindingsRegistry.registerCommandAndKeybindingRule({ id: 'list.focusParent', weight: KeybindingWeight.WorkbenchContrib, when: WorkbenchListFocusContextKey, primary: KeyCode.Shift | KeyCode.LeftArrow, handler: (accessor) => { const focused = accessor.get(IListService).lastFocusedList; // Tree only if (focused && !(focused instanceof List || focused instanceof PagedList)) { if (focused instanceof ObjectTree || focused instanceof DataTree || focused instanceof AsyncDataTree) { const tree = focused; const focusedElements = tree.getFocus(); if (focusedElements.length === 0) { return; } const focus = focusedElements[0]; const parent = tree.getParentElement(focus); if (parent) { const fakeKeyboardEvent = new KeyboardEvent('keydown'); tree.setFocus([parent], fakeKeyboardEvent); tree.reveal(parent); } } else { const tree = focused; tree.focusParent({ origin: 'keyboard' }); } } } }); </ins>  No newline at end of file
Code change:
Testing Please see the attached recording ! Notice how 'bb' is only shown after adding 'ccc'
Good catch. The "fast update" only applied when list DOM element is in focus but not when list item is in focus.

Related discussion:
text: // If a single setting is being refreshed, it's ok to refresh now if that is not the focused setting if (key) { const focusedKey = focusedSetting.getAttribute(AbstractSettingRenderer.SETTING_KEY_ATTR); <del> /** * Update `list`s live if focused item is whole list or list item, * as they have a separate "submit edit" step built in before this */ if ( focusedKey === key && !DOM.hasClass(focusedSetting, 'setting-item-list') && !DOM.hasClass(focusedSetting, 'setting-item-contents') </del> <ins> if (focusedKey === key && // update `list`s live, as they have a separate "submit edit" step built in before this (focusedSetting.parentElement && !DOM.hasClass(focusedSetting.parentElement, 'setting-item-list')) </ins> ) { this.updateModifiedLabelForKey(key);
Code change:
Issue Type: <bBug</bIf you have keyboard with multimedia buttons using them in Explorer tree triggers highlights/filtering. focus to Explorer tree Play/Pause media key that filter for was applied ! This keyboard have only one multimedia key, but I expect that other might be affected too. VS Code version: Code - Insiders 1.37.0-insider (, 2019-08-01T05:37:54.848Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </detailsExtensions: none <!-- generated by issue reporter --
I would like to have a go at this.
Can you still reproduce this? Think it may have been fixed in commit . I know I used to be able to reproduce this but I can't anymore.
thanks for checking this issue. Unfortunately I'm still able to reproduce this issue wits latest Insiders build. ! Version: 1.40.0-insider (user setup) Commit: Date: 2019-10-22T05:27:32.053Z Electron: 6.0.12 Chrome: 76.0.3809.146 12.4.0 V8: 7.6.303.31-electron.0 OS: Windows_NT x64 10.0. Reported key is (which looks like expected key code for this button) ! UPD. While looks good media key might "leak" somewhere on
Issue related. I am thinking that this key filtering (see below) could be simplified massively. Instead of blacklisting all of these edge cases, we could just check if is a single character. I believe this should only allow key presses that we want. Then we can just add the exceptions such as . If we remove L660 and modify L664 to be: Key filtering:
I thought about this. But you're going to hit issues with unicode characters, in which one visible character actually has length 1. Let's just keep filtering out these cases one by one, it's fine. Simply add .
Cannot reproduce in 1.39. Could someone who can verify the fix in the latest Insiders?
Fix works as expected for me. Version: 1.40.0-insider (user setup) Commit: Date: 2019-10-31T05:42:33.138Z

Related discussion:
text: const onKeyDown = Event.chain(domEvent(this.view.getHTMLElement(), 'keydown')) .filter(e => !isInputElement(e.target as HTMLElement) || e.target === this.filterOnTypeDomNode) <del> .filter(e => e.key !== 'Dead') </del> <ins> .filter(e => e.key !== 'Dead' && !/^Media/.test(e.key)) </ins> .map(e => new StandardKeyboardEvent(e)) .filter(this.keyboardNavigationEventFilter || (() => true)) .filter(() => this.automaticKeyboardNavigation || this.triggered)
Code change:
Reported here: Nice example:
Sorry didn't get the chance to get this done, pushing it out to September.
Note to self: remember to revert

Related discussion:
text: private async doRefresh(elements: ITreeItem[]): Promise<void> { if (this.tree) { this.refreshing = true; <del> await Promise.all(elements.map(element => this.tree.updateChildren(element, true))); elements.map(element => this.tree.rerender(element)); </del> <ins> const parents: Set<ITreeItem> = new Set<ITreeItem>(); elements.forEach(element => { if (element !== this.root) { const parent = this.tree.getParentElement(element); parents.add(parent); } else { parents.add(element); } }); await Promise.all(Array.from(parents.values()).map(element => this.tree.updateChildren(element, true))); </ins> this.refreshing = false; this.updateContentAreas(); if (this.focused) {
Code change:
VSCode Version: 1.37.1 OS Version: Fedora 30 I'm extracting the CSS Language Server for usage in 3rd party IDE (Eclipse IDE). I noticed that if I start the CSS-LS without passing a element to initialization, the LS will fail because of . One of the important lines in the stack trace is .
Submitted PR for this issue.
Fixed by .
Verified in master by removing the dataPaths

Related discussion:
text: } } <del> const dataPaths: string[] = params.initializationOptions.dataPaths; </del> <ins> const dataPaths: string[] = params.initializationOptions.dataPaths || []; </ins> const customDataProviders = getDataProviders(dataPaths); function getClientCapability<T>(name: string, def: T) {
Code change:
VSCode Version: 1.37.1 OS Version: Fedora 30 I'm extracting the CSS Language Server for usage in 3rd party IDE (Eclipse IDE). I noticed that if I start the CSS-LS without passing a element to initialization, the LS will fail because of . One of the important lines in the stack trace is .
Submitted PR for this issue.
Fixed by .
Verified in master by removing the dataPaths

Related discussion:
text: viewStates[handle] = { visible: input === group.activeEditor, active: input === activeInput, <del> position: editorGroupToViewColumn(this._editorGroupService, group.id || 0), </del> <ins> position: editorGroupToViewColumn(this._editorGroupService, group.id), </ins> }; } }
Code change:
VSCode Version: 1.37.1 OS Version: Fedora 30 I'm extracting the CSS Language Server for usage in 3rd party IDE (Eclipse IDE). I noticed that if I start the CSS-LS without passing a element to initialization, the LS will fail because of . One of the important lines in the stack trace is .
Submitted PR for this issue.
Fixed by .
Verified in master by removing the dataPaths

Related discussion:
text: } private onDidClickLink(handle: WebviewPanelHandle, link: URI): void { <del> if (!link) { return; } </del> const webview = this.getWebviewEditorInput(handle); if (this.isSupportedLink(webview, link)) { this._openerService.open(link);
Code change:
VSCode Version: 1.37.1 OS Version: Fedora 30 I'm extracting the CSS Language Server for usage in 3rd party IDE (Eclipse IDE). I noticed that if I start the CSS-LS without passing a element to initialization, the LS will fail because of . One of the important lines in the stack trace is .
Submitted PR for this issue.
Fixed by .
Verified in master by removing the dataPaths

Related discussion:
text: return; case 'did-click-link': <del> let [uri] = event.args; </del> <ins> const [uri] = event.args; </ins> this._onDidClickLink.fire(URI.parse(uri)); return;
Code change:
VSCode Version: 1.37.1 OS Version: Fedora 30 I'm extracting the CSS Language Server for usage in 3rd party IDE (Eclipse IDE). I noticed that if I start the CSS-LS without passing a element to initialization, the LS will fail because of . One of the important lines in the stack trace is .
Submitted PR for this issue.
Fixed by .
Verified in master by removing the dataPaths

Related discussion:
text: clientY: rawEvent.clientY + bounds.top, })); return; <del> } catch (TypeError) { </del> <ins> } catch { </ins> // CustomEvent was treated as MouseEvent so don't do anything - https://github.com/microsoft/vscode/issues/78915 return; } } case 'did-set-content':
Code change:
Issue Type: <bBug</bSteps to Reproduce: a project/folder mouse into Editor and then move it out from right edge of the window Activity Bar mouse into Side Bar and then move it out from left edge of the window VS Code version: Code 1.37.1 (, 2019-08-15T16:16:34.800Z) OS version: Darwin x64 18.7.0 <!-- generated by issue reporter --
The issue seems to be in , but I am not sure what the difference is between that edge of the editor and the others. For some reason the mouseLeave event is not being fired on the right-hand side. It seems it thinks the is the same as the initially given - which means the leave event is never fired. I'm happy to keep digging into this if that's ok with you.

Related discussion:
text: export function addDisposableNonBubblingMouseOutListener(node: Element, handler: (event: MouseEvent) => void): IDisposable { return addDisposableListener(node, 'mouseout', (e: MouseEvent) => { // Mouse out bubbles, so this is an attempt to ignore faux mouse outs coming from children elements <del> let toElement: Node | null = <Node>(e.relatedTarget || e.target); </del> <ins> let toElement: Node | null = <Node>(e.relatedTarget); </ins> while (toElement && toElement !== node) { toElement = toElement.parentNode; }
Code change:
Issue Type: <bBug</bSteps to Reproduce: a project/folder mouse into Editor and then move it out from right edge of the window Activity Bar mouse into Side Bar and then move it out from left edge of the window VS Code version: Code 1.37.1 (, 2019-08-15T16:16:34.800Z) OS version: Darwin x64 18.7.0 <!-- generated by issue reporter --
The issue seems to be in , but I am not sure what the difference is between that edge of the editor and the others. For some reason the mouseLeave event is not being fired on the right-hand side. It seems it thinks the is the same as the initially given - which means the leave event is never fired. I'm happy to keep digging into this if that's ok with you.

Related discussion:
text: export function addDisposableNonBubblingPointerOutListener(node: Element, handler: (event: MouseEvent) => void): IDisposable { return addDisposableListener(node, 'pointerout', (e: MouseEvent) => { // Mouse out bubbles, so this is an attempt to ignore faux mouse outs coming from children elements <del> let toElement: Node | null = <Node>(e.relatedTarget || e.target); </del> <ins> let toElement: Node | null = <Node>(e.relatedTarget); </ins> while (toElement && toElement !== node) { toElement = toElement.parentNode; }
Code change:
, Replace string functionality in search does not work properly for hyphen and underscore separated variables , Initially figured it out from this Example: Replacingto with preserve case turned on replaces correctly to Replacing to with preserve case turned on replaces incorrectly to instead of PS : Additional Info from the code I found out there is a bug in function. The whole idea to call the replacement function again at was to reuse the already existing replacement logic ( First char capital , full caps and full small) but there was a bug as the hyphens and underscores were not even called because of wrong ordering in the condition checking logic.
Thanks for the PR, can you please phrase this issue in the form of a bug report (ie describe what to do, what happens, what is supposed to happen)

Related discussion:
text: export function buildReplaceStringWithCasePreserved(matches: string[] | null, pattern: string): string { if (matches && (matches[0] !== '')) { <ins> const containsHyphens = validateSpecificSpecialCharacter(matches, pattern, '-'); const containsUnderscores = validateSpecificSpecialCharacter(matches, pattern, '_'); if (containsHyphens && !containsUnderscores) { return buildReplaceStringForSpecificSpecialCharacter(matches, pattern, '-'); } else if (!containsHyphens && containsUnderscores) { return buildReplaceStringForSpecificSpecialCharacter(matches, pattern, '_'); } </ins> if (matches[0].toUpperCase() === matches[0]) { return pattern.toUpperCase(); } else if (matches[0].toLowerCase() === matches[0]) { return pattern.toLowerCase(); } else if (strings.containsUppercaseCharacter(matches[0][0])) { <del> const containsHyphens = validateSpecificSpecialCharacter(matches, pattern, '-'); const containsUnderscores = validateSpecificSpecialCharacter(matches, pattern, '_'); if (containsHyphens && !containsUnderscores) { return buildReplaceStringForSpecificSpecialCharacter(matches, pattern, '-'); } else if (!containsHyphens && containsUnderscores) { return buildReplaceStringForSpecificSpecialCharacter(matches, pattern, '_'); } else { return pattern[0].toUpperCase() + pattern.substr(1); } </del> <ins> return pattern[0].toUpperCase() + pattern.substr(1); </ins> } else { // we don't understand its pattern yet. return pattern;
Code change:
, Replace string functionality in search does not work properly for hyphen and underscore separated variables , Initially figured it out from this Example: Replacingto with preserve case turned on replaces correctly to Replacing to with preserve case turned on replaces incorrectly to instead of PS : Additional Info from the code I found out there is a bug in function. The whole idea to call the replacement function again at was to reuse the already existing replacement logic ( First char capital , full caps and full small) but there was a bug as the hyphens and underscores were not even called because of wrong ordering in the condition checking logic.
Thanks for the PR, can you please phrase this issue in the form of a bug report (ie describe what to do, what happens, what is supposed to happen)

Related discussion:
text: assert.equal(buildReplaceStringWithCasePreserved(actual, 'newfoo-newbar-newabc'), 'Newfoo-Newbar-Newabc'); actual = ['Foo-Bar-abc']; assert.equal(buildReplaceStringWithCasePreserved(actual, 'newfoo-newbar'), 'Newfoo-newbar'); <ins> actual = ['foo-Bar']; assert.equal(buildReplaceStringWithCasePreserved(actual, 'newfoo-newbar'), 'newfoo-Newbar'); actual = ['foo-BAR']; assert.equal(buildReplaceStringWithCasePreserved(actual, 'newfoo-newbar'), 'newfoo-NEWBAR'); </ins> actual = ['Foo_Bar']; assert.equal(buildReplaceStringWithCasePreserved(actual, 'newfoo_newbar'), 'Newfoo_Newbar');
Code change:
, Replace string functionality in search does not work properly for hyphen and underscore separated variables , Initially figured it out from this Example: Replacingto with preserve case turned on replaces correctly to Replacing to with preserve case turned on replaces incorrectly to instead of PS : Additional Info from the code I found out there is a bug in function. The whole idea to call the replacement function again at was to reuse the already existing replacement logic ( First char capital , full caps and full small) but there was a bug as the hyphens and underscores were not even called because of wrong ordering in the condition checking logic.
Thanks for the PR, can you please phrase this issue in the form of a bug report (ie describe what to do, what happens, what is supposed to happen)

Related discussion:
text: assert.equal(buildReplaceStringWithCasePreserved(actual, 'newfoo_newbar'), 'Newfoo_newbar'); actual = ['Foo_Bar-abc']; assert.equal(buildReplaceStringWithCasePreserved(actual, 'newfoo_newbar-abc'), 'Newfoo_newbar-abc'); <ins> actual = ['foo_Bar']; assert.equal(buildReplaceStringWithCasePreserved(actual, 'newfoo_newbar'), 'newfoo_Newbar'); actual = ['Foo_BAR']; assert.equal(buildReplaceStringWithCasePreserved(actual, 'newfoo_newbar'), 'Newfoo_NEWBAR'); </ins> }); test('preserve case', () => {
Code change:
, Replace string functionality in search does not work properly for hyphen and underscore separated variables , Initially figured it out from this Example: Replacingto with preserve case turned on replaces correctly to Replacing to with preserve case turned on replaces incorrectly to instead of PS : Additional Info from the code I found out there is a bug in function. The whole idea to call the replacement function again at was to reuse the already existing replacement logic ( First char capital , full caps and full small) but there was a bug as the hyphens and underscores were not even called because of wrong ordering in the condition checking logic.
Thanks for the PR, can you please phrase this issue in the form of a bug report (ie describe what to do, what happens, what is supposed to happen)

Related discussion:
text: actual = replacePattern.buildReplaceString(['Foo-Bar-abc'], true); assert.equal(actual, 'Newfoo-newbar'); <ins> replacePattern = parseReplaceString('newfoo-newbar'); actual = replacePattern.buildReplaceString(['foo-Bar'], true); assert.equal(actual, 'newfoo-Newbar'); replacePattern = parseReplaceString('newfoo-newbar'); actual = replacePattern.buildReplaceString(['foo-BAR'], true); assert.equal(actual, 'newfoo-NEWBAR'); </ins> replacePattern = parseReplaceString('newfoo_newbar'); actual = replacePattern.buildReplaceString(['Foo_Bar'], true); assert.equal(actual, 'Newfoo_Newbar');
Code change:
, Replace string functionality in search does not work properly for hyphen and underscore separated variables , Initially figured it out from this Example: Replacingto with preserve case turned on replaces correctly to Replacing to with preserve case turned on replaces incorrectly to instead of PS : Additional Info from the code I found out there is a bug in function. The whole idea to call the replacement function again at was to reuse the already existing replacement logic ( First char capital , full caps and full small) but there was a bug as the hyphens and underscores were not even called because of wrong ordering in the condition checking logic.
Thanks for the PR, can you please phrase this issue in the form of a bug report (ie describe what to do, what happens, what is supposed to happen)

Related discussion:
text: replacePattern = parseReplaceString('newfoo_newbar-abc'); actual = replacePattern.buildReplaceString(['Foo_Bar-abc'], true); assert.equal(actual, 'Newfoo_newbar-abc'); <ins> replacePattern = parseReplaceString('newfoo_newbar'); actual = replacePattern.buildReplaceString(['foo_Bar'], true); assert.equal(actual, 'newfoo_Newbar'); replacePattern = parseReplaceString('newfoo_newbar'); actual = replacePattern.buildReplaceString(['foo_BAR'], true); assert.equal(actual, 'newfoo_NEWBAR'); </ins> }); });