jiebi/CodeConvo huggingface dataset:
Change:
import { FloatingEditorClickWidget } from 'vs/workbench/browser/codeeditor'; import { Extensions, IConfigurationMigrationRegistry } from 'vs/workbench/common/configuration'; import { AccessibilityVerbositySettingId, AccessibleViewProviderId } from 'vs/workbench/contrib/accessibility/browser/accessibilityConfiguration'; <del> import { getCommentCommandInfo } from 'vs/workbench/contrib/accessibility/browser/accessibilityContributions'; </del> import { AccessibleViewType, IAccessibleViewService } from 'vs/workbench/contrib/accessibility/browser/accessibleView'; import { AccessibilityHelpAction } from 'vs/workbench/contrib/accessibility/browser/accessibleViewActions'; <ins> import { getCommentCommandInfo } from 'vs/workbench/contrib/accessibility/browser/editorAccessibilityHelp'; </ins> import { IEditorService } from 'vs/workbench/services/editor/common/editorService'; class DiffEditorHelperContribution extends Disposable implements IDiffEditorContribution {

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. --In previous versions, with the use of and the extension, I could easily select and copy terminal output content in the "Accessible View" via Vi mode. However, in the update, I noticed a change that "The Accessible View now closes when a user starts typing and focuses the prior element for a smoother work flow.". This change prevents me from using Vi mode to select content in the "Accessible View." Could you please consider providing an option that allows users to choose whether or not this feature is enabled? Alternatively, are there any other solutions to this issue?
Related to
can you take a look at this one? Thanks!
To verify, disable and make sure the view does not close on key press.
Fixed now! Thanks for the quick resolution!
Change:
export const contrastBorder = registerColor('contrastBorder', { light: null, dark: null, hc: '#6FC3DF' }, nls.localize('contrastBorder', "An extra border around elements to separate them from others for greater contrast.")); export const activeContrastBorder = registerColor('contrastActiveBorder', { light: null, dark: null, hc: focusBorder }, nls.localize('activeContrastBorder', "An extra border around active elements to separate them from others for greater contrast.")); <ins> export const selectionBackground = registerColor('selection.background', { light: null, dark: null, hc: null }, nls.localize('selectionBackground', "The background color of text selections in the workbench (e.g. for input fields or text areas). Note that this does not apply to selections within the editor and the terminal.")); </ins> // ----- widgets export const widgetShadow = registerColor('widget.shadow', { dark: '#000000', light: '#A8A8A8', hc: null }, nls.localize('widgetShadow', 'Shadow color of widgets such as find/replace inside the editor.'));

Discussion:
All input box based widgets (find, file search, etc) need text selection foreground/background UI colors. Have to decide if there should be a global ::selection color or any individual ones are needed. !
Added via for May.
Change:
showCwd = cwdUri.fsPath.localeCompare(instance.workspaceFolder.uri.fsPath, undefined, { sensitivity: caseSensitive ? 'case' : 'base' }) !== 0; } if (showCwd) { templateProperties.cwdFolder = path.basename(templateProperties.cwd); } }

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 usually give a meaningful name to my folders in the workspace config file, like this: It would be very useful if the integrated terminal title could show this name instead of the folder name. Currently these variables can be used in the property: ${cwd} ${cwdFolder} ${workspaceFolder} ${local} ${process} ${separator} ${sequence} ${task} The refers to the property of the folder. There could be a new variable, or something like that. Thank you in advance! Keep up the good work!
<!-- -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!
If this just needs to point at it should be trivial to add:
Is this still in the backlog for a future release? It would be very useful for accessibility platforms like talon voice where we rely on parsing context information out of the window title.
Change:
"command.undoCommit": "Undo Last Commit", "command.checkout": "Checkout to...", "command.branch": "Create Branch...", <ins> "command.merge": "Merge Branch...", </ins> "command.pull": "Pull", "command.pullRebase": "Pull (Rebase)", "command.push": "Push",

Discussion:
It does not currently appear possible to merge local git branches in VS Code. Quite a common workflow is to have a "development" branch to develop new features on (or alternatively have feature specific branches). When the development is finished, the development branch is then merged into the "master" branch before release. This can be done via the integrated terminal, but as VS Code's git implementation is so wizzy, it would be great to be able to replicate this workflow using the GUI.
I can't believe there aren't more for this... what are the current alternatives? An extension, or have you guys set up a task for this?
+1, I think that feature might be considered priority for the git extension, it's a really nice implementation and with merging, would be perfect. No news?
It'd be lovely to be able to trigger a merge from the command palette, e.g. cmd + shift + p Select a branch to merge from via search-dropdown Any opportunity to avoid having to dip back into the command line is lovely. Thanks in advance!
Weird it is still not implemented and even weirder since we can create and change branch. It spoils the git integration in Code as if the feature was unfinished. We can still rely on built-in terminal or extension but it is not a consistent Code workflow Same for git stash
I also would like to see a Git Merge implemented eventually without going in the console. you might be interested to know that there's an open PR to which will hopefully land soon. There's actually also a PR for but changes were asked over a month ago and it wasn't done yet, so it might not land.
Fixed in
Change:
collector.addRule(` .monaco-workbench:not(.reduce-motion) .interactive-input-part .monaco-action-bar .action-label.codicon-loading.codicon-modifier-spin:not(.disabled), .monaco-workbench:not(.reduce-motion) .inline-chat .monaco-action-bar .action-label.codicon-loading.codicon-modifier-spin:not(.disabled) { <del> color: ${activeRecordingColor}; outline: 1px solid ${activeRecordingColor}; outline-offset: -1px; animation: pulseAnimation 1s infinite; </del> <ins> outline: 2px solid ${activeRecordingColor}; </ins> border-radius: 50%; <del> } .monaco-workbench:not(.reduce-motion) .interactive-input-part .monaco-action-bar .action-label.codicon-loading.codicon-modifier-spin:not(.disabled)::before, .monaco-workbench:not(.reduce-motion) .inline-chat .monaco-action-bar .action-label.codicon-loading.codicon-modifier-spin:not(.disabled)::before { position: absolute; outline: 1px solid ${activeRecordingColor}; outline-offset: 2px; border-radius: 50%; width: 16px; height: 16px; } .monaco-workbench:not(.reduce-motion) .interactive-input-part .monaco-action-bar .action-label.codicon-loading.codicon-modifier-spin:not(.disabled)::after, .monaco-workbench:not(.reduce-motion) .inline-chat .monaco-action-bar .action-label.codicon-loading.codicon-modifier-spin:not(.disabled)::after { content: ''; position: absolute; outline: 1px solid ${activeRecordingDimmedColor}; outline-offset: 3px; animation: pulseAnimation 1s infinite; border-radius: 50%; width: 16px; height: 16px; </del> <ins> animation: pulseAnimation 1500ms ease-in-out infinite !important; padding-left: 4px; height: 17px; </ins> } @keyframes pulseAnimation { 0% { <del> outline-width: 1px; </del> <ins> outline-width: 2px; </ins> } 50% { <del> outline-width: 3px; </del> <ins> outline-width: 5px; </ins> outline-color: ${activeRecordingDimmedColor}; } 100% { <del> outline-width: 1px; </del> <ins> outline-width: 2px; </ins> } } `);

Discussion:
!
It seems the new animation changes the size of the element, as can be seen when used in inline chat: !
Change:
promptToSaveFilesBeforeCommit = 'never'; } <del> const enableSmartCommit = config.get<boolean>('enableSmartCommit') === true; </del> <ins> let enableSmartCommit = config.get<boolean>('enableSmartCommit') === true; </ins> const enableCommitSigning = config.get<boolean>('enableCommitSigning') === true; let noStagedChanges = repository.indexGroup.resourceStates.length === 0; let noUnstagedChanges = repository.workingTreeGroup.resourceStates.length === 0;

Discussion:
Type: <bBug</b- Make a change to a file in a directory with Git setup Without staging it manually, write a commit message and press the commit button A popup will show up. Confirm that you'd like to stage all files. Observe how you get an error message and no changes get staged VS Code version: Code - Insiders 1.92.0-insider (, 2024-07-05T00:00:00.000Z) OS version: Darwin arm64 23.5.0 <details<summarySystem Info</summary </details<details<summaryExtensions (22) - also tested with all extensions disabled and same result</summaryExtensionVersion ------ ruff2024.30.0 gitlens15.1.0 copilot1.211.0 copilot-chat0.17.0 discord-vscode5.8.0 debugpy2024.7. python2024.11. vscode-pylance2024.6.104 jupyter2024.6.0 jupyter-keymap1.1.2 remote-containers0.377.0 remote-ssh0.113. remote-ssh-edit0.86.0 remote-wsl0.88.2 remote-explorer0.5. material-icon-theme5.4.2 run-on-save1.9.0 developer-theme-dark5.0.0 svelte-vscode108.5.4 highlight-matching-tag0.11.0 intellicode-api-usage-examples0.2.8 vscodeintellicode1.3.1 (3 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Thank you very much for reporting this issue. Fix should be available in tomorrow's VS Code Insiders release.
Change:
AltArch := '32'; end; <del> if not Result then begin </del> <ins> if not Result and not WizardSilent() then begin </ins> MsgBox('Please uninstall the ' + AltArch + '-bit version of {#NameShort} before installing this ' + ThisArch + '-bit version.', mbInformation, MB_OK); end; end;

Discussion:
VSCode Version: 1.35.0 OS Version: Windows 10 Steps to Reproduce: With 64-bit VS Code installed, run run VSCodeSetup-ia32- with /SUPPRESSMSGBOXES /VERYSILENT You'll get a dialog that says "please uninstall the 64-version before attempting to install the 32-bit version.”
Hello. I can take this issue if you want, I have reproduced and identified the bug. I will open a PR when ready :+1:
Verification: 32 bit to install 64 bit, msg box should come up to install 64 bit from the command line with /VERYSILENT, msg box should not come up
or still displays the message box.
It appears that latest insider release was built using this commit: Commit fixing this is was hours later: Is it possible that insiders version doesn't include the fix yet ?
Oh yes. Normally I catch myself on this, but It's still early in the morning I guess. Thank you for pointing that out , I'll test it once insiders contains the fix.
Change:
override setVisible(visible: boolean): void { if (visible) { <ins> this.extensionService.activateByEvent('onView:timeline'); </ins> this.visibilityDisposables = new DisposableStore(); this.editorService.onDidActiveEditorChange(this.onActiveEditorChanged, this, this.visibilityDisposables);

Discussion:
Testing Why is not there a contribution point for timeline provider? Following are the advantages I am not sure how I have to activate my extension if I only contribute timeline provider. Having a timeline contribution point can allow me to activate my extension when user starts using the timeline my extension contributesAlso helps in displaying the feature contributions in extension editor view
and I talked about supporting this originally but felt that it was something that could be later.
Hm, not sure... Somehow timeline feels like master-detail, e.g you open an editor and the timeline shows its contents. With that usage-pattern it feels wrong to have an activation event. Then there is the 'Open timeline' command which is different... You could that command as activation event and all is good
On what event shall an extension contributing a timeline should be activated?
For instance these and
should we support an activation? Rather than a really specific point just for the timeline?
Yeah, that would make sense
To verify ensure that your extension that contributes a timeline can activate properly when the timeline is revealed via the activation
Change:
async run(accessor: ServicesAccessor) { that.shouldShowViewsContext.set(true); const viewsService = accessor.get(IViewsService); <del> await viewsService.openViewContainer(EDIT_SESSIONS_CONTAINER_ID); </del> <ins> await viewsService.openView(EDIT_SESSIONS_DATA_VIEW_ID); </ins> } })); }

Discussion:
Testing Store an edit session in for a GH repo Open desktop Insiders Use GH Repositories extension to open same remote GH repo Edit Sessions view is empty - since I'm logged into GH in both web and desktop, I anticipated seeing my 3 edit sessions from here: !
Duplicate of If you run the 'Focus on All Sessions View' command, do your edit sessions show up? In tomorrow's insiders that view container should only appear in the sidebar after you explicitly run the command to Show Edit Sessions.
These are the only edit session commands I see in desktop today: ! I see more options in than desktop - should I be seeing more of these options in desktop? ! Maybe this is a dupe of Edit: Yes, this seems to be When I stored an edit session in desktop, I was prompted to log into GH Repositories, and now I see more options: ! Except now I still don't see anything in the Edit Sessions view in desktop, although I'm working on the same GH repo through GH Repositories that I was working on in the web: !
Ah, I had to select the menu in the Edit Session view, and choose to "Show all sessions." Now I can see the session from I would've expected to see all my edit sessions by default.
that shouldn't happen, the 'Edit sessions' view container should be hidden unless the 'All sessions' view is also showing. Do you recall how you got the edit sessions container to show up without the sessions ?
I believe these were my steps: Make an edit and store a session in Open same repo via GH Repositories in desktop VS Code Make an edit and store a session in desktop Storing in desktop prompts me to log into GH Once logged in and the session is stored, run command to Confused because Edit Session view is empty I manually select menu in Edit Session view to and then I can see my sessions (I guess the web ones were hidden by default in desktop)
:+1: tracking as
I couldn't repro this yesterda on desktop, but just repro-ed this with a clean user data dir, this is a bug with the Show Edit Sessions action. It should focus the view, not the container.
<!-- 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!
I'm trying to test this again, but I don't see any edit session commands: ! Am I missing something?
/verified
Change:
return Promise.reject(new Error('Parent folder is readonly.')); } <del> const stat = new ExplorerItem("_URI, folder, true); </del> <ins> const stat = new NewExplorerItem(folder, true); </ins> return folder.fetchChildren(this.fileService, this.explorerService).then(() => { folder.addChild(stat);

Discussion:
Issue Type: <bBug</bExplorer asks to input file name for a new file on the wrong level after pressing <kbdEscape</kbdbutton. On the gif file below we have focus on directory, but input field created on the root level of the project. ! asks to create this issue. Related issue is Keyboard navigation: simple. Extension to switching keyboard context is installed. VS Code version: Code - Insiders 1.32.0-insider (, 2019-02-22T08:34:22.116Z) OS version: Darwin x64 18.2.0 <details<summarySystem Info</summary </details<details<summaryExtensions (1)</summaryExtensionVersion ------ atom-keybindings3.0.6 </details<!-- generated by issue reporter --
My understanding is that this is because keyboard navigation still attempts to select the nearest file beginning with when you press , and that the “create file” action is only triggered secondary to that, so the focus has already shifted when the file is created. Super annoying.
Change:
.scm-view .scm-input { height: 100%; padding-left: 11px; <ins> border-radius: 2px; } .scm-view .scm-input .margin { width: 6px !important; } .scm-input .monaco-scrollable-element { left: 6px !important; } .scm-view .scm-editor-container .monaco-editor { border-radius: 2px !important; </ins> } .scm-view .scm-editor {

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 relativeBadgeUrlRequiresHttpsRepository = l10n.t("Relative badge URLs require a repository with HTTPS protocol to be specified in this package.json."); const apiProposalNotListed = l10n.t("This proposal cannot be used because for this extension the product defines a fixed set of API proposals. You can test your extension but before publishing you MUST reach out to the VS Code team."); const implicitActivationEvent = l10n.t("This activation event cannot be explicitly listed by your extension."); <ins> const redundantImplicitActivationEvent = l10n.t("This activation event can be removed as VS Code generates these automatically from your package.json contribution declarations."); </ins> enum Context { ICON,

Discussion:
Following the addition of implicit activation events in the November release, we'd like to provide lint warnings via the extension-editing extension when an extension declares activation events which are already implied by its declared contributions.
cc as a heads up--we previously discussed this in and at the time agreed that a simple warning for the reserved/internal event was sufficient. We've since updated the docs and extension samples to mention that you don't need to explicitly list many events anymore. In discussion with Kai, the next step to round out this work and make extension authors aware of the new behavior is to provide lint warnings for all redundant events in the extension-editing extension. Let me know if you have any questions or concerns.
Change:
description: nls.localize('vscode.extension.contributes.terminal', 'Contributes terminal functionality.'), type: 'object', properties: { <del> types: { type: 'array', description: nls.localize('vscode.extension.contributes.terminal.types', "Defines additional terminal types that the user can create."), items: { type: 'object', required: ['command', 'title'], properties: { command: { description: nls.localize('vscode.extension.contributes.terminal.types.command', "Command to execute when the user creates this type of terminal."), type: 'string', }, title: { description: nls.localize('vscode.extension.contributes.terminal.types.title', "Title for this type of terminal."), type: 'string', }, icon: { description: nls.localize('vscode.extension.contributes.terminal.types.icon', "A codicon, URI, or light and dark URIs to associate with this terminal type."), anyOf: [{ type: 'string', }, { type: 'object', properties: { light: { description: nls.localize('vscode.extension.contributes.terminal.types.icon.light', 'Icon path when a light theme is used'), type: 'string' }, dark: { description: nls.localize('vscode.extension.contributes.terminal.types.icon.dark', 'Icon path when a dark theme is used'), type: 'string' } } }] }, }, }, }, </del> profiles: { type: 'array', description: nls.localize('vscode.extension.contributes.terminal.profiles', "Defines additional terminal profiles that the user can create."),

Discussion:
Type: <bBug</bI saw the schema prompt for 'types' under terminal contribute, but setting it does not take effect. After checking the vscode source code and issue, I found that this contribution point has been removed. VS Code version: Code 1.71.0 (Universal) (, 2022-09-01T07:25:38.437Z) OS version: Darwin x64 21.4.0 Modes: Sandboxed: No Remote OS version: Linux x64 5.10.3+ <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
!
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.71.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Related Links:
After upgrading to , it still remain.