jiebi/CodeConvo huggingface dataset:
Code change:
"html.mirrorCursorOnMatchingTag": { "type": "boolean", "scope": "resource", <del> "default": true, </del> <ins> "default": false, </ins> "description": "%html.mirrorCursorOnMatchingTag%" }, "html.trace.server": {

Related discussion:
text: There are thousands of gadgets we can turn on with extensions, and it's awesome that such a facility is available for us. At the least, the very least, this should have been tested and re-tested for six or nine months, made available in an extension or an option, and then if there was an outpouring of requests perhaps a dialog that pops up after an update that says, "hey, you should really turn this on". If all goes well, and still no problems, you could turn it on for new installs. But instead you threw something together half-baked and forced it on existing installations! Are you starting to see how it this interesting idea was executed all wrong? Look, if you have all these extra coding cycles and want to implement something cool, why not go which is one of the huge remaining bugs that mar an otherwise fabulous editor. Congratulations on the editor in general, and good luck learning from this lesson and making it even better.
Since you can use Rename Symbol (F2 by default) on HTML tags, I think having automatic double cursors is unnecessary. In my experience, renaming HTML tags does not happen often enough to warrant the automatic double cursors - since I am already used to renaming symbols with F2, it's more intuitive to do it that way.
you the needsMoreInfo tag to this issue. Is there sufficient info now or is there something else you're still waiting on? ? Anything else you need?
We can consider disabling it by default, but that means this feature won't be discoverable at all. Some issues are hard to fix, others are impossible. We are working on an improvement. You can find more details in . This feature does what it says: Creating another cursor when you are on an open/close tag. Some actions, when two cursors are present, perform differently than one cursor. Like, if you press Enter when two cursors are there, it produces two newlines. We can't bend multi-cursor to work differently, just so when you press Enter it only creates one newline. I'm not sure how you can use VSVim in VS Code (isn't it only for Visual Studio)? During my testing it had some issues with VSCodeVim, because of the way VSCodeVim is implemented. But most of the time it works fine.
Code change:
"html.mirrorCursorOnMatchingTag": { "type": "boolean", "scope": "resource", <del> "default": true, </del> <ins> "default": false, </ins> "description": "%html.mirrorCursorOnMatchingTag%" }, "html.trace.server": {

Related discussion:
text: In short: we'll use this iteration to find workaround for some of the issues. If there's no easy workaround, we might take a more general approach in , and meanwhile disable this feature by default. If you have issues with concrete reproducible cases, please open new issues.
So you're saying then that this will be Microsoft's policy moving forward, that is, to make new and unpopular features enabled by default in order to make them 'discoverable', so that users then have to sacrifice their time and productivity with vetting processes like this? It would seem that it would be in the user's best interest to let users discover new features in the release notes and let those who wish to test the feature do so on their own time, rather than forcing new features on the general userbase who actually depend on reliable editors to meet deadlines and earn their daily bread. Thanks for informing us of this policy now so that users can let it inform their choice of editor in the future.
I can't dictate Microsoft policy. Please don't make extreme straw man statement to criticize it. We'll consider disabling it by default. That's why the issue is open and marked with .
Yep, sorry, I meant , totally messed up there. :manfacepalming: I think the issue here is that by enabling the feature by default, I had no idea what the feature "said" or that it even existed. All I knew was that multiple cursors kept popping up when my cursor was on an HTML tag. Yes, precisely. That's the problem. Some actions performed differently and I didn't know why. Nobody is asking for the multi-cursor feature to behave differently, we're saying that only the users who want_ multi-cursors should deal with those nuances. This GitHub issue is full of comments from people who were confused/frustrated by the change in default behavior, which is arguing for it to be disabled by default. I'm curious, what is the argument for enabling the feature by default? Is that discussion documented somewhere? I'd like to see why the feature was considered so useful as to warrant being enabled by default because as far as I can tell, the only benefit is in the case where you need to rename an HTML tag. And I agree with comment: Is there another use case that I'm missing?
Code change:
"html.mirrorCursorOnMatchingTag": { "type": "boolean", "scope": "resource", <del> "default": true, </del> <ins> "default": false, </ins> "description": "%html.mirrorCursorOnMatchingTag%" }, "html.trace.server": {

Related discussion:
text: With all due respect, it should be obvious that it's the decision to enable it by default that most people in this thread are objecting to. That's either a one-off decision that was made for this particular feature or it's a policy decision that will be made for other new features moving forward. I apologize if my comment came off wrong - Code is a great editor. What I'm saying is that I hope this is just a one-off, because if it were to become the default method of launching new features, it might affect users' willingness to use Code or to upgrade for fear of encountering unwanted new features that result in loss of productivity.
as noted, I run into this multiple times a day working in Angular. I had thought it was an extension gone rouge, as it seemed like a feature that an extension would add. So I spent my morning disabling them one by one, until I opted to search and see if this was a new vscode "feature" . For what it's worth, I also disagree with the notion that new features should be enabled by default to encourage "discovery". That's what the update and changelogs are for. If I was a new VSCode user coming in post-update and I ran into this not knowing it was a "feature", it would turn me off from the editor completely. It's not what I would consider typical behavior for what an editor should do, but that's just my two cents.
I specifically looked to find this issue/topic as I've been hit by it multiple times during a day of coding now and it did introduce bugs in my code. The worst case is when I reorganize HTML code and sometimes have to delete or edit the starting tag. Then the closing tag can get deleted too, but nothing is of course re- if I start typing in the new/changed starting tag because it has now no ending tag counterpart. Well, maybe it's immediately after my new starting tag, in the completely wrong place. This can introduce hard to immediately discover bugs in my HTML because of sometimes deep nesting in long blocks of code and removed or messed up closing tags (I've particularly discovered things like suddenly missing end brackets that I've only noticed early on thanks to syntax highlighting?).
Code change:
"html.mirrorCursorOnMatchingTag": { "type": "boolean", "scope": "resource", <del> "default": true, </del> <ins> "default": false, </ins> "description": "%html.mirrorCursorOnMatchingTag%" }, "html.trace.server": {

Related discussion:
text: It's especially frustrating because sometimes things happen and other times it doesn't seem to, and I have a hard time mentally getting around when and why it's doing things, so I end up having to baby sit the editor. I think that for me, it would be easier to have more predictable behavior back again. I'm very used to renaming both tags, no problem there. But sure, at least now I know what the setting is. I'm just offering this as feedback on "how does this impact me negatively".
This feature is a poor substitute for real code refactoring, and should never have been enabled by default (IMO it should never have been to the main application at all). If you were worried that users would not discover the feature, you could have a hint about it in the changelog. Or better yet; you could have made it as an extension, and advertised it in the extensions panel. Multiple cursors are really handy in certain scenarios, but it is vital that the user is fully aware and in control of where they are. One really essential problem with this feature is detecting when the user is actually modifying the tag name, and not just adjacent code. Another is that there are other ways of modifying the tag name than just adding or removing characters. I do not believe that these issues can be solved without proper code awareness, and if the editor has that then this feature is redundant anyway. Given this code example... ...I have three examples of how this feature breaks the code while I am editing: want to remove the extra whitespace preceding the class-attribute, so I place the cursor at the end of the tag name and hit <kbddel</kbd. Code is now broken because the end-tag has no closing angle bracket (). inadvertently typed in the attribute "component" without a space after the tag name "custom-angular", and I fix it quickly by placing the cursor between the two and hit <kbdspace</kbd. Code is now broken because the end-tag does not match the start-tag. want to remove the prefix "custom-" and I do so by placing the cursor at the end of the prefix and hitting <kbd<- Backspace</kbdrepeatedly.
Code change:
"html.mirrorCursorOnMatchingTag": { "type": "boolean", "scope": "resource", <del> "default": true, </del> <ins> "default": false, </ins> "description": "%html.mirrorCursorOnMatchingTag%" }, "html.trace.server": {

Related discussion:
text: Now if I go back too far, accidentally removing the opening angle bracket (<), and then re-type that character to fix my error, then the code is broken because the end-tag has been converted to a new start-tag. Now all of these are simple examples, and if you are aware of the feature and/or see the errors as they occur, it is super easy to fix the code again. Either manually or by using the undo-feature. But if the code is longer and more complex and the end-tag is out-of-view when the errors occur, it may be quite difficult both to discover the errors and to fix them.
Here is a use case where the default "on" of this new "feature" is incorrect. tl;dr - A proficient vim user can make a horrible mess very quickly with mirror cursor. I rarely use VSCode but at work I need to write up some documentation from time to time and I prefer to do so in html. So I fired up VSCode for the first time in a while and started typing up a doc. I use vim bindings and don't need to look at my editor too much especially when working in the way I was today. So I wasn't paying attention to my editor. About halfway through I opened my work in a browser to review how my old CSS settings were treating the work. It was a garbled mess of half paragraphs and repetition. Using '/', '?' and other regular vim navigators causes multi-cursor insertions EVERYWHERE. Change the default to "off" and test these features against different editing options like Vim and Emacs in the future.
This kind of falls into the same category as any setting that can help users reduce keystrokes (similar to ). When you've built up some muscle memory or expectation for how things behave, and that suddenly changes, it can take time to get used to. Personally I have many of these features disabled because of being used to unconsciously doing many of them manually, and the time investment in changing that and fixing mistakes that occur in-between hasn't seemed worth it. It can be especially frustrating when you are in the middle of something and a feature like this is introduced. Even more so if finding the name of the feature in order to disable it winds up taking more than a trivial amount of time.
Code change:
"html.mirrorCursorOnMatchingTag": { "type": "boolean", "scope": "resource", <del> "default": true, </del> <ins> "default": false, </ins> "description": "%html.mirrorCursorOnMatchingTag%" }, "html.trace.server": {

Related discussion:
text: The worst part is for those who are uninformed, which is everybody who didn't see the patch notes, the name of this feature would remain elusive until you either find the correct patch notes on stumble upon this thread. How can one disable a feature that has no name? Personally I thought it was a bug with multi-select / multi-cursor that got enabled on accident. Still do actually.
I'm also having issues when moving lines with alt-arrow . I want to move the starting tag higher to include block of code above, but ending tag also gets moved.
I also got hit with this today. I mangaged to edit the opening element but it did not auto select the closing element. When I then tried to edit the closing element it auto-selected the opening element parent to the first one. See picture for example. I also ran into the same issue as and by then my blood was boiling and I literaly screamed from frustration. Features like this should not be activated by default when it clearly messes with peoples personal coding behaviour/styles. !
Had four lines of elements. Selected the opening tags for all four as distinct selections, and then edited to add to each. Didn't realize it was corrupting content in the close tags. Uck. Too dangerous to use, let alone enable by default.
A use case that this feature completely corrupts is reordering HTML tags using the + key binding. It took me ages to realise that when I was refactoring some html, reordering things, why my html was all of a sudden being corrupted because the corresponding tag was being moved as well, and more often than not, incorrectly. This should definitely not be on by default. Thanks for reading.
Created a draft PR, seemed like a pretty trivial change, just need to hear if I have to do any other tests/etc for this
All the complains above explains well, and I just want to add my current brand new face to face experience, which I encountered numerous times and today I finally, "enough is enough"... ! Anyway, thanks for the hard works, to those who work with this feature... but please make it off as default... Thanks...........
I'll turn this off by default and work on , which will be an opt-in feature.
Great, it is nice to hear that it will be turned off by default
Code change:
return; } <del> await ensurePublished(gitRepo, uri); </del> <ins> if (shouldEnsurePublished) { await ensurePublished(gitRepo, uri); } </ins> let repo: { owner: string; repo: string } | undefined; gitRepo.state.remotes.find(remote => {

Related discussion:
text: Testing Steps: Open locally cloned vscode repo with any branch Welcome page Connect to... Continue Working in Nothing happens after this for me... but I do see the commands get run:
Code change:
id: ShowCurrentReleaseNotesActionId, title: { value: localize('showReleaseNotes', "Show Release Notes"), <del> mnemonicTitle: localize('mshowReleaseNotes', "Show &&Release Notes"), </del> <ins> mnemonicTitle: localize({ key: 'mshowReleaseNotes', comment: ['&& denotes a mnemonic'] }, "Show &&Release Notes"), </ins> original: 'Show Release Notes' }, category: { value: product.nameShort, original: product.nameShort },

Related discussion:
text: Issue Type: <bBug</bGo to menu affichage apparence afficher la barre latérale secondaire L'item indique ceci " afficher la bar&re latérale secondaire" Un petit And & se balade Have a nice day VS Code version: Code 1.67.1 (, 2022-05-06T12:37:03.389Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (3)</summaryExtensionVersion ------ copilot1.20.5902 vscode-pull-request-github0.42.0 vscode-language-pack-fr1.67.3 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
the translation lacks an extra ampersand to turn this into a mnemonic <img width="501" alt="image" src="https://user-"
can you ensure there's a comment that says "don't touch the ampersand"? Additionally, you can add another comment in the form of: to ensure that they do not get "translated". See this example:
I have the same comment in 275 places across the code base And this is the string
Best I can do is ask for the string to be updated manually to ensure is not translated... but that won't prevent this from happening in the future due to human error. better is using a locked comment like the one above... could also have the be a runtime string instead... but really we need language-aware mnemonics where the position of the changes based on the language but I'm not sure if there's a process for that. do you know?
so I add? what kind of enforcement does this do? does it just force that a mnemonic exists? its not really required that a translation contains a mnemonic even if the original does
I believe it forces that it exists, though or are experts here.
I know a little bit more... this does basically "fail the string" until it meets the criteria of "there should be a somewhere in the string and a translator looks at this. did you get the chance to add this to the comments?
Code change:
return; } <del> await result.repository.applyStash(result.stash.index); </del> await commands.executeCommand('workbench.action.closeActiveEditor'); <ins> await result.repository.applyStash(result.stash.index); </ins> } @command('git.stashDrop', { repository: true })

Related discussion:
text: a new file with the following content and commit it. the file to like as follows, save it, and create a stash with it the file to like as follows, and save it the "Git: View Stash..." command and pick the created stash diff in the stash should look as follows: <img width="921" alt="image" src=""
Code change:
<ins> /*--------------------------------------------------------------------------------------------- *  Copyright (c) Microsoft Corporation. All rights reserved. *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ import * as assert from 'assert'; import { Registry } from 'vs/platform/registry/common/platform'; import { IConfigurationRegistry, Extensions as ConfigurationExtensions } from 'vs/platform/configuration/common/configurationRegistry'; suite('ConfigurationRegistry', () => { const configurationRegistry = Registry.as<IConfigurationRegistry>(ConfigurationExtensions.Configuration); test('configuration override', async () => { configurationRegistry.registerConfiguration({ 'id': '_test_default', 'type': 'object', 'properties': { 'config': { 'type': 'object', } } }); configurationRegistry.registerDefaultConfigurations([{ 'config': { a: 1, b: 2 } }]); configurationRegistry.registerDefaultConfigurations([{ '[lang]': { a: 2, c: 3 } }]); assert.deepEqual(configurationRegistry.getConfigurationProperties()['config'].default, { a: 1, b: 2 }); assert.deepEqual(configurationRegistry.getConfigurationProperties()['[lang]'].default, { a: 2, c: 3 }); }); test('configuration override defaults - merges defaults', async () => { configurationRegistry.registerDefaultConfigurations([{ '[lang]': { a: 1, b: 2 } }]); configurationRegistry.registerDefaultConfigurations([{ '[lang]': { a: 2, c: 3 } }]); assert.deepEqual(configurationRegistry.getConfigurationProperties()['[lang]'].default, { a: 2, b: 2, c: 3 }); }); test('configuration defaults - overrides defaults', async () => { configurationRegistry.registerConfiguration({ 'id': '_test_default', 'type': 'object', 'properties': { 'config': { 'type': 'object', } } }); configurationRegistry.registerDefaultConfigurations([{ 'config': { a: 1, b: 2 } }]); configurationRegistry.registerDefaultConfigurations([{ 'config': { a: 2, c: 3 } }]); assert.deepEqual(configurationRegistry.getConfigurationProperties()['config'].default, { a: 2, c: 3 }); }); }); </ins>

Related discussion:
text: Reported originally by where GitLens seemed to be breaking JSON auto-complete behavior -- causing an extra being at the end. ! I tracked it down to this contribution causing the issue I was able to reproduce this with a clean vscode user-dir/extensions-dir and a simple extension with that contribution
That JSON extension has configurationDefault for the setting: That configurationDefault is lost when the gitlens extension also makes a configurationDefault The bug is that all default overrides for the same language need to be merged, not set.
Code change:
@IFileService private readonly fileService: IFileService ) { super(lifecycleMainService, configurationService, environmentService, requestService, logService); <ins> } initialize(): void { super.initialize(); </ins> if (getUpdateType() === UpdateType.Setup) { /* __GDPR__

Related discussion:
text: run you'll notice that in the main process before creating the renderer the update service takes its time (~5-10ms). while that's not much it seems unnecessary and "block" the renderer for no good reason <img width="1101" alt="Screenshot 2020-01-31 at 14 45 07" src="https://user-"
This is only problematic in macOS where calls into the native which blocks.
Thanks
Code change:
@ITextFileService private readonly textFileService: ITextFileService, @IExplorerService private readonly explorerService: IExplorerService, @IUriIdentityService private readonly uriIdentityService: IUriIdentityService, <del> @IPathService private readonly pathService: IPathService </del> <ins> @IPathService private readonly pathService: IPathService, @IConfigurationService private readonly configurationService: IConfigurationService </ins> ) { super(TextFileEditor.ID, telemetryService, instantiationService, storageService, textResourceConfigurationService, themeService, editorService, editorGroupService);

Related discussion:
text: We don't want to officially have the hex editor be recommended for non-textual files, but what about a setting like that can be used to open a binary file in a given editor instead of showing the "binary file" message? ! I would love it if I could have all non-text files automatically opened in the hex editor.
To verify ensure the setting works as expected. Setting it to a custom editor should automatically have that editor be opened when a file is detected as binary.
Code change:
for (const defaultConfiguration of defaultConfigurations) { for (const key in defaultConfiguration) { properties.push(key); <del> this.defaultValues[key] = defaultConfiguration[key]; </del> if (OVERRIDE_PROPERTY_PATTERN.test(key)) { <ins> this.defaultValues[key] = { ...(this.defaultValues[key] || {}), ...defaultConfiguration[key] }; </ins> const property: IConfigurationPropertySchema = { type: 'object', default: this.defaultValues[key],

Related discussion:
text: Reported originally by where GitLens seemed to be breaking JSON auto-complete behavior -- causing an extra being at the end. ! I tracked it down to this contribution causing the issue I was able to reproduce this with a clean vscode user-dir/extensions-dir and a simple extension with that contribution
That JSON extension has configurationDefault for the setting: That configurationDefault is lost when the gitlens extension also makes a configurationDefault The bug is that all default overrides for the same language need to be merged, not set.
Code change:
type: string - name: VSCODE_BUILD_MACOS type: boolean <ins> default: false </ins> - name: VSCODE_BUILD_MACOS_ARM64 type: boolean <ins> default: false </ins> - name: channel type: string default: stable

Related discussion:
text: The stage is now a bottleneck to having the platform specific stages run: ! Each job compiles each target serially. We could further parallelize all targets across different jobs. !