jiebi/CodeConvo huggingface dataset:
Change:
const newMenubarVisibility = getMenuBarVisibility(this.configurationService, this.environmentService); this.setMenubarVisibility(newMenubarVisibility, !!skipLayout); <ins> // Centered Layout this.centerEditorLayout(this.state.editor.centered, skipLayout); </ins> } private setSideBarPosition(position: Position): void {

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. --When in centered layout, opening a diff view in inline mode (as opposed to side-by-side mode) should not force the diff view into full editor width as it does for side-by-side diff views. This is a follow-up from where we discussed this might be a bug. Steps to Reproduce: centered layout a diff view in inline mode diff view now occupies full editor width (as if centered layout was not enabled) Demo: ! <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
how to check if diff is in inline view? would you like to submit a PR to fix this? Code pointer
I'm afraid this is too much for me at this moment. The method is not fired when I switch from inline to side-by-side diff view and I could not figure out how to query the instance for the current display mode. Both of these events would need to be handled so that we can keep the centered layout when an inline diff is opened and we should switch to full-width layout when the diff editor's layout is switched from inline to side-by-side.
no worries, thanks for trying. Peng might give some good tips, and I might also look into this in the future.
Apologies for not mentioning that I was working on this, but I implemented a fix for this in
I was playing around with this too and managed to fix it, so I created a PR. My browser did not update so I didn't see your message, sorry for the duplicate PR :sweat_smile:
No problem! haha both our bads I guess :rofl: Next time I'll comment beforehand
Change:
order: 10, command: { id: COPY_FILE_ID, <del> title: COPY_FILE_LABEL </del> <ins> title: COPY_FILE_LABEL, </ins> }, when: ExplorerRootContext.toNegated() });

Discussion:
Sometimes "Paste" fails: The file(s) to paste have been deleted or moved since you copied them. TreeError [FileExplorer] Tree element not found: [object Object] Maybe should be disabled for as long as we do not update properly.
Change:
const colorThemeSettingEnumItemLabels: string[] = []; const colorThemeSettingEnumDescriptions: string[] = []; <ins> function formatSettingAsLink(str: string) { return ``#${str}#``; } </ins> const colorThemeSettingSchema: IConfigurationPropertySchema = { type: 'string', description: nls.localize('colorTheme', "Specifies the color theme used in the workbench."),

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:
constructor( private readonly options: ExtensionHoverOptions, private readonly extensionStatusAction: ExtensionStatusAction, <del> private readonly reloadAction: ReloadAction, </del> @IExtensionsWorkbenchService private readonly extensionsWorkbenchService: IExtensionsWorkbenchService, @IHoverService private readonly hoverService: IHoverService, @IConfigurationService private readonly configurationService: IConfigurationService,

Discussion:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --Hello, I searched for an existing ticket with , but didn't find anything related. <!-- Describe the feature you'd like. --Prior to v1.72.0, the extension sidebar showed which version an extension will be updated to. And when hovering over the extension in the sidebar, or opening the extension in a tab, you could see the currently installed one. That way you could see for example if an update is a major, minor, or patch update, and depending on that dig into the release notes or not. Further in the past, IIRC, the extension sidebar even showed both, installed and target version, which was even more convenient. Now with v1.72.0, I don't see anywhere the target version of an extension update. Many extensions don't keep a proper changelog, so that's not a reliable place to check. Here's an example for vscode-icons, a very popular extension with 12 million installs: ! Only when going to the Marketplace webpage () we see the target version: ! =Feature request: Please make the target version for extension updates visible inside of VS Code again.
Latest version is now shown in the hover. Update button in the extension editor shows the version.
Change:
{ label: 'fileBasename', detail: vscode.l10n.t("The current opened file's basename") }, { label: 'fileBasenameNoExtension', detail: vscode.l10n.t("The current opened file's basename with no file extension") }, { label: 'defaultBuildTask', detail: vscode.l10n.t("The name of the default build task. If there is not a single default build task then a quick pick is shown to choose the build task.") }, <del> { label: 'pathSeparator', detail: vscode.l10n.t("The character used by the operating system to separate components in file paths") }, </del> <ins> { label: 'pathSeparator', detail: vscode.l10n.t("The character used by the operating system to separate components in file paths. Is also aliased to '/'.") }, </ins> { label: 'extensionInstallFolder', detail: vscode.l10n.t("The path where an an extension is installed."), param: 'publisher.extension' }, ].map(variable => ({ label: `${${variable.label}}`,

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. --. However, it is very long and explicit and thus decreases readability: I would like to request a new variable, , that would be its shorter alias that also stands out visually due to no alphanumeric characters: This is inspired by .
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our . Happy Coding!
<!-- -c9e0-7adb-d31b- --:slightlysmilingface: This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our . Happy Coding!
Change:
} .vscode-light h1, <ins> .vscode-light h2, </ins> .vscode-light hr, .vscode-light td { border-color: rgba(0, 0, 0, 0.18); } .vscode-dark h1, <ins> .vscode-dark h2, </ins> .vscode-dark hr, .vscode-dark td { border-color: rgba(255, 255, 255, 0.18);

Discussion:
Here are our headers (left) compared with GitHub's (right): <img width="649" alt="image" src=""Things to note: H2 still has a bottom border in GitHub, looks great Our H4 feels very much like plain text, GitHub is definitely larger than plain Our H5 is even smaller than plain text, GitHub is at least in bold cc
Agreed. I've wanted to update these for a while now.
Change:
private _grid!: Grid<IView>; <del> private readonly input1View = this.instantiation.createInstance(InputCodeEditorView, 1, { readonly: !this.inputsWritable }); private readonly input2View = this.instantiation.createInstance(InputCodeEditorView, 2, { readonly: !this.inputsWritable }); private readonly inputResultView = this.instantiation.createInstance(ResultCodeEditorView, { readonly: false }); </del> <ins> private readonly input1View = this._register(this.instantiation.createInstance(InputCodeEditorView, 1, { readonly: !this.inputsWritable })); private readonly input2View = this._register(this.instantiation.createInstance(InputCodeEditorView, 2, { readonly: !this.inputsWritable })); private readonly inputResultView = this._register(this.instantiation.createInstance(ResultCodeEditorView, { readonly: false })); </ins> private readonly _ctxIsMergeEditor: IContextKey<boolean>; private readonly _ctxUsesColumnLayout: IContextKey<boolean>;

Discussion:
While working on I noticed that some of the UI elements (and maybe other things?) are not registered as disposable, and thus may leak when the merge editor is freed from an editor group that closes. For example the and all input views seem to not dispose.
Hm, I think also the merge model, I suggest to do a pass and register as appropiate.
Change:
*--------------------------------------------------------------------------------------------*/ 'use strict'; <del> import { IChange, IModel } from 'vs/editor/common/editorCommon'; </del> <ins> import { IChange, IModel, IIdentifiedSingleEditOperation } from 'vs/editor/common/editorCommon'; </ins> import { Range } from 'vs/editor/common/core/range'; <ins> import { Position } from 'vs/editor/common/core/position'; </ins> import { Selection } from 'vs/editor/common/core/selection'; <ins> import { EditOperation } from 'vs/editor/common/core/editOperation'; /** * Represents the selected portion of an IChange, and includes the start/end line numbers of the full change */ export class SelectedChange implements IChange { readonly originalStartLineNumber: number; readonly originalEndLineNumber: number; readonly modifiedStartLineNumber: number; readonly modifiedEndLineNumber: number; readonly fullModifiedStartLineNumber: number; readonly fullModifiedEndLineNumber: number; constructor(selected: IChange, full: IChange) { this.originalStartLineNumber = selected.originalStartLineNumber; this.originalEndLineNumber = selected.originalEndLineNumber; this.modifiedStartLineNumber = selected.modifiedStartLineNumber; this.modifiedEndLineNumber = selected.modifiedEndLineNumber; this.fullModifiedStartLineNumber = full.modifiedStartLineNumber; this.fullModifiedEndLineNumber = full.modifiedEndLineNumber; } /** * True when the change is entirely selected */ get isCompletelySelected(): boolean { return this.modifiedStartLineNumber === this.fullModifiedStartLineNumber && this.modifiedEndLineNumber === this.fullModifiedEndLineNumber; } } </ins> function sortChanges(changes: IChange[]): void { changes.sort((left, right) => {

Discussion:
There's probably already a feature request for this but I can't find it. I want to be able to select a change in the diff editor and revert it, same as how I can stage it. In SourceTree this is called "discard selected lines" although "revert" seems better, unless it's "discard selected changes". I'm working on a PR for this.
I think it is connected with
Change:
if (!extension) { return ''; } <del> const publisher = localize('extension.arialabel.publihser', "Publisher {0}", extension.publisherDisplayName); </del> <ins> const publisher = extension.publisherDomain?.verified ? localize('extension.arialabel.verifiedPublihser', "Verified Publisher {0}", extension.publisherDisplayName) : localize('extension.arialabel.publihser', "Publisher {0}", extension.publisherDisplayName); </ins> const deprecated = extension?.deprecationInfo ? localize('extension.arialabel.deprecated', "Deprecated") : ''; return `${extension.displayName}, ${deprecated ? `${deprecated}, ` : ''}${extension.version}, ${publisher}, ${extension.description}`; },

Discussion:
Currently the aria label of extension items does not announce if the author is verified or not. We should change that as it was requested by users and overall makes good sense. fyi
Announces verified publisher: <img width="641" alt="image" src="https://user-"CC
Awesome! Works great -verified
Change:
.extension-list-item .monaco-action-bar > .actions-container > .action-item.action-dropdown-item > .monaco-dropdown .extension-action.label { border-left-width: 0; } <ins> /* single install */ .extension-list-item .monaco-action-bar > .actions-container > .action-item.action-dropdown-item.empty > .extension-action { border-radius: 2px; } /* split install */ .extension-list-item .monaco-action-bar > .actions-container > .action-item.action-dropdown-item:not(.empty) > .extension-action.label:not(.dropdown) { border-radius: 2px 0 0 2px; } .extension-list-item .monaco-action-bar > .actions-container > .action-item.action-dropdown-item > .monaco-dropdown .extension-action { border-radius: 0 2px 2px 0; } </ins>

Discussion:
Looking at ways to make VS Code feel ever so slightly more approachable. A subtle 2px border radius on our common input components could be one way to make the UI feel more inviting and less harsh: <img width="361" alt="CleanShot 2022-04-08 at 14 48 52 src="https://user-"<img width="522" alt="CleanShot 2022-04-08 at 14 55 52 src="https://user-"<img width="494" alt="CleanShot 2022-04-08 at 14 58 01 src="https://user-"<img width="437" alt="CleanShot 2022-04-08 at 14 49 46 src="https://user-"<img width="500" alt="CleanShot 2022-04-08 at 15 01 55 src="https://user-"! FWIW, we already use a border radius on our icon buttons: <img width="300" alt="CleanShot 2022-04-08 at 15 03 36 src="https://user-"cc
I like this idea for buttons. I am not so sure about input/combo boxes.
I'm a +1 on this one, I think the inputs might need a bit of spacing from the side to feel more natural. We should also make sure that our labels are distinguishable as they start looking similar. Maybe we update the labels to be more pill-like?
As in padding L/R? I think they are indeed a bit different from our dropdowns if memory serves. Good call on the labels/tags.
Border-radius on buttons was merged but inputs is still under discussion so I'll keep this one open.
Good job
Change:
const matchingRule = scopesDefinition[property]; if (matchingRule && scopesDefinition.scope) { const strScopes = Array.isArray(matchingRule.scope) ? matchingRule.scope.join(', ') : String(matchingRule.scope); <del> return `${escape(scopesDefinition.scope.join(' '))}<br><code class="tiw-theme-selector">${strScopes}n${JSON.stringify(matchingRule.settings, null, 't')}</code>`; </del> <ins> elements.push( scopesDefinition.scope.join(' '), $('br'), $('code.tiw-theme-selector', undefined, strScopes, $('br'), JSON.stringify(matchingRule.settings, null, 't'))); return elements; </ins> } <del> return ''; </del> <ins> return elements; </ins> } else if (SemanticTokenRule.is(definition)) { const scope = theme.getTokenStylingRuleScope(definition); if (scope === 'setting') { <del> return `User settings: ${definition.selector.id} - ${this._renderStyleProperty(definition.style, property)}`; </del> <ins> elements.push(`User settings: ${definition.selector.id} - ${this._renderStyleProperty(definition.style, property)}`); return elements; </ins> } else if (scope === 'theme') { <del> return `Color theme: ${definition.selector.id} - ${this._renderStyleProperty(definition.style, property)}`; </del> <ins> elements.push(`Color theme: ${definition.selector.id} - ${this._renderStyleProperty(definition.style, property)}`); return elements; </ins> } <del> return ''; </del> <ins> return elements; </ins> } else { const style = theme.resolveTokenStyleValue(definition); <del> return `Default: ${style ? this._renderStyleProperty(style, property) : ''}`; </del> <ins> elements.push(`Default: ${style ? this._renderStyleProperty(style, property) : ''}`); return elements; </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. --The next step in resolving . Simirarly to , it aims to replace construction of HTML elements by string concatenation in file. The code contains mainly a table construction by concatenating strings of . The goal is to replace them all with function calls.
I verified by running the monaco editor from source and testing the inspect token hover
To verify, open the hover and verify it looks all proper.
Change:
}, ['interactiveWindow.executeWithShiftEnter']: { type: 'boolean', <del> default: true, </del> <ins> default: false, </ins> markdownDescription: localize('interactiveWindow.executeWithShiftEnter', "Execute the interactive window (REPL) input box with shift+enter, so that enter can be used to create a newline.") } }

Discussion:
With the new REPL from Python extension merged, user has to explicitly set in their in order to execute via Enter Keypress when using interactive Native REPL. They won't have to manually change this setting once the default value for interactiveWindow.execute is changed to True in core. In order to provide closer experience to the traditional Python interactive interpreter experience (pressing enter would smartly execute or wait for more complete code), we should change the default value for interative.execute to be True. Users who explicitly set their are respected at the current moment in a way that their settings are respected when using Python extension's native REPL to shift+enter or enter. Related:
Change:
*--------------------------------------------------------------------------------------------*/ .monaco-editor .margin-view-overlays .folding { <del> margin-left: 5px; </del> cursor: pointer; background-repeat: no-repeat; background-origin: border-box; <del> background-position: 3px center; background-size: 15px; </del> <ins> background-position: calc(50% + 2px) center; background-size: auto calc(100% - 3px); </ins> opacity: 0; transition: opacity 0.5s; }

Discussion:
! !
Good catch
Same for breakpoints. Looks like Visual Studio also doesn't grow the breakpoint and folding icons with the font size. Users can always use the Zoom feature, which zooms everything.
I removed the code that grows the folding icon gutter by font size to avoid the clipping that can bee seen in the second screenshot. We can add that again if we decide to grow the icons along with the font size
I can fix this by converting the icon sizing to ems, but it could possibly affect the pixel-perfect lines of the icon; I wouldn't be able to test it before the freeze (because my Retina screen lies to me about how other screens will alias it. I would need my desktop). Let's hold off until March on this one just to be safe and not compromise the icon.
Makes sense. As the breakpoints also don't grow/shrink I think we are consistent.
This is fixed now I guess. !
this actually happens when you change , which is different from
Change:
if (uri === undefined) { return; } // Run the store action to get back a ref <del> const ref = await that.storeEditSession(); </del> <ins> const ref = await that.storeEditSession(false); </ins> // Append the ref to the URI if (ref !== undefined) {

Discussion:
Testing If there are no changes, we should not be able to create a new edit session. In this particular case, I would expect that an information message is being shown, and that the existing edit session is not being overwritten.
Change:
'tr': { codePage: 'CP1254' } }; <del> // Transifex Localizations const apiHostname = process.env.TRANSIFEX_API_URL; const apiName = process.env.TRANSIFEX_API_NAME; const apiToken = process.env.TRANSIFEX_API_TOKEN; gulp.task(task.define( 'vscode-translations-push', task.series( compileBuildTask, compileExtensionsBuildTask, optimizeVSCodeTask, function () { const pathToMetadata = './out-vscode/nls.metadata.json'; const pathToExtensions = '.build/extensions/*'; const pathToSetup = 'build/win32/**/{Default.isl,messages.en.isl}'; return es.merge( gulp.src(pathToMetadata).pipe(i18n.createXlfFilesForCoreBundle()), gulp.src(pathToSetup).pipe(i18n.createXlfFilesForIsl()), gulp.src(pathToExtensions).pipe(i18n.createXlfFilesForExtensions()) ).pipe(i18n.findObsoleteResources(apiHostname, apiName, apiToken) ).pipe(i18n.pushXlfFiles(apiHostname, apiName, apiToken)); } ) )); </del> gulp.task(task.define( 'vscode-translations-export', task.series( <del> compileBuildTask, </del> <ins> core, </ins> compileExtensionsBuildTask, <del> optimizeVSCodeTask, </del> function () { const pathToMetadata = './out-vscode/nls.metadata.json'; <ins> const pathToRehWebMetadata = './out-vscode-reh-web/nls.metadata.json'; </ins> const pathToExtensions = '.build/extensions/*'; const pathToSetup = 'build/win32/i18n/messages.en.isl'; return es.merge( <del> gulp.src(pathToMetadata).pipe(i18n.createXlfFilesForCoreBundle()), </del> <ins> gulp.src([pathToRehWebMetadata]).pipe(merge({ fileName: 'nls.metadata.json', jsonSpace: '', concatArrays: true })).pipe(i18n.createXlfFilesForCoreBundle()), </ins> gulp.src(pathToSetup).pipe(i18n.createXlfFilesForIsl()), gulp.src(pathToExtensions).pipe(i18n.createXlfFilesForExtensions()) ).pipe(vfs.dest('../vscode-translations-export'));

Discussion:
Testing in Firefox, with Spanish (es-es) set Open "Get Started with VS Code in the Web" walkthrough Select last step (open up your code), then first command ("Open Folder" in English, "Abrir carpeta" in Spanish) Modal is in English: ! It isn't a new string, and I didn't think getting started or this command would be from an extension, but perhaps that is the case.
I also see this on modals on the overall welcome page when I try opening a file or folder: !
Thank you for your feedback. We are currently reviewing it (reference ).
This is an odd one. The string looks good here: but the file that that comes from doesn't show up at all in our Spanish files: I'll have to dig into why this is... any ideas?
might be a bug in the tool so that the localize call is not detected. When you generate the export is the string included.
Ok the web strings are now bundled in language packs. It may take a minute for all these new strings to make their way through the translation system... but by end game it should be good.
Change:
const _href = function (href: string, isDomUri: boolean): string { const data = markdown.uris && markdown.uris[href]; <del> if (!data) { return href; // no uri exists } </del> let uri = URI.revive(data); if (isDomUri) { if (href.startsWith(Schemas.data + ':')) { return href; } <ins> if (!uri) { uri = URI.parse(href); } </ins> // this URI will end up as "src"-attribute of a dom node // and because of that special rewriting needs to be done // so that the URI uses a protocol that's understood by // browsers (like http or https) return FileAccess.asBrowserUri(uri).toString(true); } <ins> if (!uri) { return href; } </ins> if (URI.parse(href).toString() === uri.toString()) { return href; // no transformation performed }

Discussion:
Version: 1.62.0-insider (Universal) Commit: Date: 2021-10-28T05:14:00.367Z Electron: 13.5.1 Chrome: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Darwin arm64 20.6.0 Setting , on the markdown document of a completion item, an tag cannot load a PNG file if the path given as a URI with . If the path given as the path of a local filesystem, it can load the file. Steps to Reproduce: one of images cannot be loaded. !
Can I pick this up?
Sure, the relevant code where we fix image paths is:
For the markdown syntax images, if the URI schema is , that's being changed to . For the HTML tag images, the file URI remains as is. The HTML image with URI doesn't load due to CSP violation.
Yes uris are blocked for security reasons. The problem is that raw html tags don't go through the transform that I linked to One thing to try would be to look for image nodes in the rendered markdown and then transform their uris instead of relying on the markdown parser to handle the transform. Try looking at for that
/verified