jiebi/CodeConvo huggingface dataset:
Change:
[localize('workspace.cancel', 'Cancel'), ConfirmResult.CANCEL], ]; <del> const { choice } = await this._dialogService.show(Severity.Info, message, actions.map(a => a[0]), { ...options, cancelId: actions.length - 1 }); </del> <ins> const { choice, checkboxChecked } = await this._dialogService.show(Severity.Info, message, actions.map(a => a[0]), { ...options, cancelId: actions.length - 1, checkbox: { label: localize('noMoreWarn', "Don't ask again") } }); if (checkboxChecked) { this._storageService.store(StorageCloseWithConflicts, true, StorageScope.PROFILE, StorageTarget.USER); } </ins> return actions[choice][1]; } else { // This shouldn't do anything

Discussion:
a conflict file in 3 way merge the 3 way merge editor Notice dialog ! I do not think we have a need for this dialog any more since we are no longer removing the conflict markers. Thus the user can just close this dialog, there is no data loss? Similarly when the user closes the old editor with conflict markers we do not prompt. fyi
I don't have an opinion about this.
I would leave it for the clarity it creates, however I am open for a "don't ask again" option
"Don't ask again" works for me, especially since I just noticed that when some conflicts get resolved the dialog is "smarter". Would don't ask again write in storage or a setting? I am fine going loco and writing to storage (so users can not revert). Though if all the other "don't ask again" write in settings then I guess I am fine with that.
+1 for "Don't ask again"
Fyi there is a very practical use case for the dialog: if you run with and use VSCode as Git merge editor, you may actually want to resolve the conflicts before closing the editor because Git somewhat expects you to do so. On top of that, given , we currently cannot pass back an exit code to Git, so it helps showing a dialog to avoid returning back to Git with merge conflicts still in the file. Besides, we show a similar dialog when you try to stage a file that has merge conflicts from the SCM view: !
thanks for providing more info, I missed that case. Though I think it does not conflict with our idea to add "Don't Ask Again".
Can we tell the merge editor if it was opened in a modal context (like with --wait)?
Currently not, an editor has no knowledge that it is being utilised for . There is plumbing around the editor where we observe the opened editor for being closed and then delete the wait marker file. Can we get more user feedback on this before jumping onto a conclusion?
Verify that there is an option to not be asked again there is a "Reset Choice for Close with Conflicts" commands in the F1 list <img width="1405" alt="Screenshot 2022-11-25 at 15 24 27" src="https://user-"
Adding verified since this works as expected. Noticed one minor "glitch".

"Don't ask again" Cancel The "Don't ask again" choice will be preserved. It should probably be only preserved if I click on "Close with Conflicts". I am not supper passionate about this, but let me know if you would like me to file an issue
Change:
const always = l10n.t('Always'); const never = l10n.t('Never'); <del> const choice = await window.showWarningMessage(message, yes, always, never); </del> <ins> const choice = await window.showInformationMessage(message, yes, always, never); </ins> if (choice === yes) { // Open Parent Repositories commands.executeCommand('git.openRepositoriesInParentFolders');

Discussion:
Testing <img width="574" alt="image" src="https://user-"
Change:
} while (Object.keys(UntitledEditorService.CACHE).indexOf(resource.toString()) >= 0); } <ins> const configuration = this.configurationService.getConfiguration<IFilesConfiguration>(); if (!modeId && configuration.files && configuration.files.defaultLanguage) { modeId = configuration.files.defaultLanguage; } </ins> const input = this.instantiationService.createInstance(UntitledEditorInput, resource, hasAssociatedFilePath, modeId, initialValue); const contentListener = input.onDidModelChangeContent(() => {

Discussion:
VSCode Version: 1.2.1 OS Version: Windows 10 64x Steps to Reproduce: create new file, before save file with '.js' extension and the manual language selection, need to have option to default language e.g. JavaScript, not plaintext as default
We would need to introduce a workbench configuration such that there is a default language mode for new files opened. Such that it is being picked up before a user manuly chooses a mode or sets the file extension.
I would think this could also be done nicely from an extension.
This is one of my key uses from PowerShell ISE that is hard to convert over to VS Code. I use the Untitled page often to construct commands and scripts rather than doing it in terminal because its much easier to edit and I'm not wanting to save it just yet. The trick though is this is Visual Studio Code and versatile so sometimes I will want the default to be different based on the language I'm focusing on in a given period. The two ways to handle this would be: Command Line option to select default language on startup. File New --Language menu options The first option allows me to create a shortcut focused on my language. VS Code PowerShell and VS Code C#. It would also make it easier for extensions to configure the environment more for their use if they knew someone was starting it up as their language. The second option should not be defaults, but rather configurations for me to add my own list to the File menu. I like both approaches but if I had to choose one, the first I think could be more useful.
I just looked into making an extension for this but there doesn't seem to be an API to change the language ID of a TextDocument. I tried passing the language ID as a parameter to but it always displays the quick pick dialog. Any ideas?
I think this can be done via a new command using the new API:
That doesn't work for new files that the user creates using "File -New", "Files: New File" or double-clicking in the tab area. Though maybe I should just send a PR to VS Code to add an official setting for default language mode :)
Oh yeah, but I would start with an extension first to see how it works. You can easily map it to Ctrl+N for "New File" by default.

All in all, also not opposed to seeing a PR on this, e.g. could be something like editor.defaultLanguage or file.defaultMode.
maybe? Not sure that most users know what a "mode" is.
I'm going to work on this today!
Verify: a new setting allows to configure the default language mode a new untitled file should get you can still change the mode from the picker and the untitled file will keep this association even between restarts
Change:
const messages = (result.hasLoadingMessage ? this._addLoadingMessage(result.value) : result.value); this._withResult(new HoverResult(this._computer.anchor, messages, result.isComplete)); })); <del> this._register(this._editor.onDidChangeModelDecorations(() => { if (this._isChangingDecorations) { return; } this._onModelDecorationsChanged(); })); </del> this._register(dom.addStandardDisposableListener(this._widget.getDomNode(), 'keydown', (e) => { if (e.equals(KeyCode.Escape)) { this.hide();

Discussion:
I was trying to copying a new setting in the problems hover and it was extremely painful to do so: https://user-
This is editor hover and hence assigning to
FWIW this works fine for me on Windows.
Change:
resolved "https://registry.yarnpkg.com/xterm-addon-webgl/-/xterm-addon-webgl-0.16.0-beta.2.tgz#30489ef235405255ee54077002c90553531870d8" integrity sha512-DAt4E/QI1w34ToBhcDj0vaZOAHOO+ffwMt2HGDAB7amPXRcMb0LBIjLpyZhB9sD4tbIgsE0vuqZi1R9vKxZwbg== <del> xterm@5.3.0-beta.3: version "5.3.0-beta.3" resolved "https://registry.yarnpkg.com/xterm/-/xterm-5.3.0-beta.3.tgz#1a1aaf9a57afe4dcf86e87d8dc85e80a41d68644" integrity sha512-NGxpV25U2W/KKk6M5V2OXuLgrKY+w05ABi66ZEYuCTi7ux1Qv0z+jm7bkgzk1pGGiTVLG+90OGr2nrhbFr5Y4w== </del> <ins> xterm@5.3.0-beta.7: version "5.3.0-beta.7" resolved "https://registry.yarnpkg.com/xterm/-/xterm-5.3.0-beta.7.tgz#ee638fe60382e6b13f36dec2355c3530ff1c4c34" integrity sha512-wd+QHHfCVSZMSH7ah8WSeCu7VAqZcAD5pEAOiQxCg4VfXu+L//QOycqlWecgr0SFui2X9LshfD+cI9J3FcHRNA== </ins>

Discussion:
On the latest insiders I can't click and drag the terminal scroll bar: !
Same here - but at least the terminal can actually be resized now!
I the same problem. In my case, all scrollbars (editor, explorer, ...) were. I tried and it was the same. Not sure if this is related, but Google Chrome and Slack App do not have this issue.
Same issue here, cannot scroll the terminal window. The cursor changes to text selector and is unable to scroll for the entire life of the terminal window. !
I completely shut down macOS and restarted it and it fixed it. It's strange.
Restarting vscode fixes it for me. It only happens when my cursor either hovers over a link in the terminal or I select some text from the terminal, it gets forever stuck in text selection/link click mode.
This is because of the image addon: ! cc
Upstream:
Saw that you released v1.80. In there is still 0.4.1 mentioned as version for xterm-addon-image. The patch version fixing this issue at hand is 0.4.2 - did that not work for you? Note that I was not able to repro the issue with vscode 1.79, so there is a chance that my attempt did not address it. Or did just the package update slip through?
I'm seeing this in Insiders. Restarting VSCode doesn't fix it and it only happens when I have multiple terminals open and the terminal tab sidebar is showing. Version: 1.81.0-insider (Universal) Commit: Date: 2023-07-07T19:50:58.701Z Electron: 22.3.14 ElectronBuildId: Chromium: 108.0.5359.215 16.17.1 V8: 10.8.168.25-electron.0 OS: Darwin x64 22.5.0
it came in a bit late for the release and didn't think it met the bar. I'll be updating soon
Change:
import Severity from 'vs/base/common/severity'; import * as Types from 'vs/base/common/types'; import * as nls from 'vs/nls'; <del> import { asArray } from 'vs/base/common/arrays'; </del> import { IModelService } from 'vs/editor/common/services/model'; import { IFileService } from 'vs/platform/files/common/files';

Discussion:
Type: <bBug</b"" on VS Code this task and save: this task ([Terminal] [Run Task] [Throw my error]) Enter The integrated terminal shows an error because of . Pressing Enter closes it because of .The integrated terminal shows an error because of . Pressing Enter inserts a line break into the current opened "", or at least leaves the terminal open. Terminal display: I use Git Bash of Git for Windows as my default terminal (), but I've tried and PowerShell and got the same result. Of cause, if the command is , the terminal doesn't appear because of . "Reload With Extensions Disabled" has no effect. TBH, I know this is a duplicate of . It has already been closed as a "feature-request" that didn't receive enough upvotes. It may be impolite to reopen a closed issue in this way, and I'm very hesitant to do so, but for the life of me, I can't believe that fixing this counter-intuitive behavior is within the scope of feature requests. The current behavior is surprising, not convincing. I'm sorry if there are already other ways to achieve the expected behavior. VS Code version: Code 1.79.2 (, 2023-06-14T08:57:04.379Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (23)</summaryExtensionVersion ------ Bookmarks13.3.1 project-manager12.7.0 laravel-extra-intellisense0.6.3 markdown-preview-github-styles2.0.2 insert-unicode0.14.0 laravel-blade1.1.2 vscode-eslint2.4.0 vscode-deno3.19.1 EditorConfig0.16.4 gc-excelviewer4.2.57 code-eol1.0.12 haml1.4.1 live-stylus-compiler0.0.4 zenkaku0.0.3 vscode-language-pack-ja1.79.

remote-containers0.295.0 live-server0.4.8 laravel-blade1.34.0 laravel5-snippets1.17.0 LiveServer5.7.9 language-stylus1.16.0 vscode-input-sequence0.2.0 markdown-all-in-one3.5.1 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
<!-- -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!
So you mean it isn't a bug? The "focus" option doesn't make focus. Is this intended behavior?
You're right - it is a bug
I'll fix that
Change:
</dict> <dict> <key>include</key> <ins> <string>#fenced_code_block_php</string> </dict> <dict> <key>include</key> </ins> <string>#fenced_code_block_sql</string> </dict> <dict>

Discussion:
VSCode Version:1.1.0-alpha OS Version: Windows 10 Steps to Reproduce: a markdown file and add a code block. a function, string, etc that has an opening bracket or string Regardless of the language specified for the code block, bracket completion is not supported.
Verified that this still does not work with the new markdown extension.
Fixed via
cool! would it not make more sense to push your changes directly to master given that we pushed vscode-markdown into VSCode?
I'll send out my PR real quick (I'd like to have the push privilege after my onboard).
Change:
import { IActionViewItemOptions, ActionViewItem } from 'vs/base/browser/ui/actionbar/actionViewItems'; import { EXTENSIONS_CONFIG, IExtensionsConfigContent } from 'vs/workbench/services/extensionRecommendations/common/workspaceExtensionsConfig'; import { getErrorMessage, isCancellationError } from 'vs/base/common/errors'; <del> import { IUserDataSyncEnablementService, SyncResource } from 'vs/platform/userDataSync/common/userDataSync'; </del> <ins> import { IUserDataSyncEnablementService } from 'vs/platform/userDataSync/common/userDataSync'; </ins> import { ActionWithDropdownActionViewItem, IActionWithDropdownActionViewItemOptions } from 'vs/base/browser/ui/dropdown/dropdownActionViewItem'; import { IContextMenuProvider } from 'vs/base/browser/contextmenu'; import { ILogService } from 'vs/platform/log/common/log';

Discussion:
Look at telemetry and if not a lot of users are using the Install and Do not Sync extension action remove the action to simplify the Extension Install flow. is the action name. fyi
Ok was run on 59K distinct machines. For comparison extensionGallery:install was executed on 10.4M machines. So Do not Sync is used in 0.5% of cases. I think it is fine if we remove it - we keep it somewhere but not so prominent. what do you think?
Any suggestions?
We already have the "Sync Extension" check in the Extension context menu when it is installed - this is great. ! And we already have the "Sync Extension" check in the same context menu when it is not installed. Just currently if I click this, there is no effect. So ideally the experience would be that I can uncheck this before installing the extension. And thus we need no new actions. !
Lets try this in insiders already and see if we get any hit back.
Awesome - thanks!
Change:
return null; } <ins> // TODO: Consider removing this check </ins> if (camelCaseWord.length > 60) { <del> return null; </del> <ins> camelCaseWord = camelCaseWord.substring(0, 60); </ins> } const analysis = analyzeCamelCaseWord(camelCaseWord);

Discussion:
Type: <bBug</bI am not sure if this a feature request or a bug. When I create Python snippets with a name longer than 60 characters, fuzzy search is disabled for these snippets. Steps to reproduce to Python snippets JSON file a snippet with name: "a very long name which has more than sixty chars to trigger the problem" to "Insert snippet" in a python file snippet can only be found when the search string matches the snippet name exactly, i.e. "a very long" will narrow the search result down to the snippet, while "avelo" will exclude the snippet from the search results. In case this is the current behavior, I would like to make the case that in fields like data science, many people have large collections of snippets for generating different plots etc. Even in the age of Copilot, these remain useful :) To distinguish between many snippets, longer and descriptive titles are often very useful. Thank you for considering this issue! VS Code version: Code - Insiders 1.87.0-insider (, 2024-02-05T05:46:48.601Z) OS version: Linux x64 6.5.0-15-generic Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (19)</summaryExtensionVersion ------ vscode-neovim1.6.0 vscode-eslint2.4.4 copilot1.159.0 copilot-chat0.12.0 fuzzy-search0.0.3 black-formatter2024.1. debugpy2024.1. python2024.1. vscode-pylance2023.12.1 jupyter2024.2. jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 remote-ssh0.109. remote-ssh-edit0.86.0 remote-explorer0.5. remote-server1.6. my-vscode-utils0.0.2 pyexec0.0.1 </details<!-- generated by issue reporter --
this seems to be an issue with QP and its default search/filtering
For the time being you could use completions for this <img width="632" alt="Screenshot 2024-02-09 at 15 19 46" src=""
Thanks for the very quick response!

Including the snippets in the intellisense suggestions is in principle a good idea! Personally, I prefer having this turned off to avoid having too many distracting items in my completions. So if this same sort of fuzzy matching could be allowed in the Quick Pick, that would be awesome :)
Looks intentional... though that was 7 years ago! Let's move cautiously here as this code is used in a lot of places... first step, I'll go ahead and just trim the string to 60. This shouldn't impact perf much because we already said 60 is our limit. In the future we can consider removing that check.
Change:
/** * Value-object describing what options formatting should use. */ <del> export interface SortingOptions { /** * Size of a tab in spaces. */ tabSize: number; /** * Prefer spaces over tabs. */ insertSpaces: boolean; /** * Signature for further properties. */ [key: string]: boolean | number | string; } /** * Value-object describing what options formatting should use. */ </del> export interface FormattingOptions { /**

Discussion:
With new API type was but that type isn't used anywhere and looks like a leftover. We should remove it before releasing stable.
fyi
My bad, I must have it and forgot to remove it.
Thanks for the quick turnaround
Change:
// Only add previous session item if it's not in this session and it matches the remote authority for (const [label, info] of history.entries) { if ((info === null || info.remoteAuthority === this.remoteAuthority) && !cwds.includes(label)) { <del> previousSessionItems.push({ </del> <ins> previousSessionItems.unshift({ </ins> label, buttons: [removeFromCommandHistoryButton] });

Discussion:
Testing Session where commands got to the history: ! Later session: ! The command was run in two different locations and was last run. But in the previous session list it does not have it at the top. The order is not the same.
Previous session missing cwd is by design, we may choose to add it later when looking into autocomplete but for now it's meant to act more like an alternative to ctrl+r which doesn't track cwd on any shell. Additionally, if we tracked it we'd need to worry about keeping track of every cwd we track as only tracking the last cwd for a command feels a bit odd. Will look into the order.
To verifier: a shell integration enabled terminal , , echo commands should show up in the section, in order of most recently run a new window and the same terminal type as in echo commands should show up in the section, in order of most recently run
Step 7 fails for me. For step 5, I tried both opening a completely new window, and simply creating a new tab: !
I can repro but only if I open run recent very quickly, too quickly for the terminal to get classified as a pwsh which is a prerequisite to pulling in the history as it's segregated by shell type. Making as verified again, remove if I misunderstood.
Change:
{ type: 'object', properties: { <del> isExecutable: { type: 'boolean', markdownDeprecationMessage: 'This property is deprecated. Instead use `scope` property and set it to `machine` value.' }, </del> scope: { type: 'string', enum: ['application', 'machine', 'window', 'resource', 'language-overridable', 'machine-overridable'],

Discussion:
Create UI extension with a 'machine' scoped setting Load that UI extension in a remote window See a message in local settings that this setting can only be set on the remote If I understand correctly, since the extension is local, the setting should be set locally, right?
Irrespective of where extension is running, machine scoped settings are always ignored from local settings and can be applied only from remote settings. Closing this as designed. If there is a reason or use case to allow in local settings, let me know.
Ok, the scope description needs to be fixed then: I guess it should say "in a remote/local window" instead of referencing where the extension is running. My use case was that there are remote resolver settings which should not be synced because they reference local paths, and I don't think there is a way to do that.
Yup, you are right. Description needs to be fixed.
Should this be a feature request?
I see.. you cannot tag them as machine settings because in the remote window they are not respected. I will reopen this as a feature request for this use case.
You can already do this by setting property on the setting. This is not shown in the intellisense though - it.
<!-- 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!
Change:
-moz-user-select: none; -ms-user-select: none; user-select: none; <del> color: var(--vscode-list-inactiveSelectionBackground) !important; </del> <ins> color: var(--vscode-disabledForeground) !important; </ins> } .codeActionMenuWidget .monaco-list .separator {

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/No <!-- 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: OS Version: Type: Bug Using editor.experimental.useCustomCodeActionMenu, the menu doesn't match up with the colors of enabled/disabled options or the background of the other context menus

Type: <bBug</bmenu the window Bug The widget ends up being incorrectly positioned: <img width="672" alt="Screen Shot 2022-07-21 at 1 24 17 PM" src="https://user-"VS Code version: Code - Insiders 1.70.0-insider (Universal) (, 2022-07-21T05:17:20.056Z) OS version: Darwin x64 21.5.0 Modes: <details<summarySystem Info</summary </details<!-- generated by issue reporter --
Change:
color: var(--vscode-commandCenter-foreground); background-color: var(--vscode-commandCenter-background); border: 1px solid var(--vscode-commandCenter-border); <del> border-radius: 5px; height: 20px; line-height: 18px; width: 38vw; max-width: 600px; min-width: 32px; margin: 0 4px; </del> flex-direction: row; justify-content: center; overflow: hidden;

Discussion:
hitting tab and shift tab to get to the "command center group" and then arrow keys once in that group. !