jiebi/CodeConvo huggingface dataset:
Code change:
{ "open": "{", "close": "}" }, { "open": "(", "close": ")" }, { "open": "'", "close": "'", "notIn": ["string", "comment"] }, <del> { "open": """, "close": """, "notIn": ["string"] } </del> <ins> { "open": """, "close": """, "notIn": ["string"] }, { "open": "/*", "close": " */", "notIn": ["string", "comment"] } </ins> ], "surroundingPairs": [ ["{", "}"],

Related discussion:
text: VSCode Version: 1.36.0 OS Version: Windows 10 / Mac OS Steps to Reproduce: any c++ code inside of a .cpp/h/hpp etc file. "/" at the begging of of a line that has already been written "/" gets automatically afterwards, but before the code, so nothing actually gets commented out Simple example, where "|" denotes the cursor position: "/*" shouldn't auto-add the end symbol of the comment block by default, should be setting controlled, and should be able to recognize when it's been entered at the start of a line. Does this issue occur when all extensions are disabled?: Yes Originally reported here: They forwarded me to you folks, so I'm assuming this was to the "C/C++ Language Basics" built-in extension without a setting to control it. Please for the love of god fix this. It's super annoying.
Found a temporary workaround: to: (User Folder)AppDataLocalProgramsMicrosoft VS Coderesourcesappextensions "cpp" to (User Folder).vscodeextensions it something like "cpp.language-basics-custom" to avoid any later confusion. "language-" & comment out (or remove) this line: the trailing comma in the previous line (might not be necessary) VS Code. The custom version should take precedence over the built-in version. Comment blocks will no longer auto-close.
Also, of note: Neither javascript nor typescript contains that in their language- files, but uses the same style of block comments. I think it's safe to say it should just be removed from the cpp language-
It looks like C# and json use the as an auto closing pair, but java, javascript, php, and typescript use the . For C languages we whould use since it is more consistent.
Fix will be available in next insiders if you want it ASAP. It installs side by side with stable, so you can have both:
the C/C++ extension already registers a custom , including for . Please don't add autoClosingPairs for comments since there is no way to disable them in vscode. There are only settings for and . I seem to recall these all being controlled by a single setting at some point, but now there are only 2 out of 3 available.
Code change:
{ "open": "{", "close": "}" }, { "open": "(", "close": ")" }, { "open": "'", "close": "'", "notIn": ["string", "comment"] }, <del> { "open": """, "close": """, "notIn": ["string"] } </del> <ins> { "open": """, "close": """, "notIn": ["string"] }, { "open": "/*", "close": " */", "notIn": ["string", "comment"] } </ins> ], "surroundingPairs": [ ["{", "}"],

Related discussion:
text: Visual Studio Code lacks support for automatic comment-block ending in C and C++. If you were to start a comment-block with , an automatic will not be as it would be in the traditional Visual Studio. When I type , it should automatically be turned into and the text cursor should be between the two ``. It isn't that big of a deal but it would be really nice to have this feature in Visual Studio Code.
Ugh. I currently have the exact OPPOSITE problem: I want to DISABLE this feature. This is happening for me and I can't figure out how to turn it OFF. There are a large number of developers who just don't ever want their text editor to ever, under any circumstances, insert a character that did not correspond exactly 1:1 to a specific keystroke. I push "A", I get "A". And so on. "Surprises" break my flow worse than any other kind of interruption. Obviously, there are a lot of developers in the other camp. But the upshot is that the fact that both camps exist, and both camps are large, means that when features like this exist, it needs to be possible to disable them. I have encouraged many projects for years to consider adding a "dumb as a brick" switch that will just globally disable all of these. In the absence of a master switch, we at least need configuration switches that can shut these things off-- preferably arranged hierarchically, so that we can shut off entire branches. But the absolute lowest rung on the ladder is that individual switches must exist to disable these things.
Let's track in
Code change:
import { Codicon } from 'vs/base/common/codicons'; import { registerIcon } from 'vs/platform/theme/common/iconRegistry'; import { UntitledTextEditorInputSerializer, UntitledTextEditorWorkingCopyEditorHandler } from 'vs/workbench/services/untitled/common/untitledTextEditorHandler'; <del> import { DynamicEditorGroupAutoLockConfiguration } from 'vs/workbench/browser/parts/editor/editorConfiguration'; </del> <ins> import { DefaultBinaryEditorConfiguration, DynamicEditorGroupAutoLockConfiguration } from 'vs/workbench/browser/parts/editor/editorConfiguration'; </ins> //#region Editor Registrations

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:
export const InteractiveWindowSetting = { interactiveWindowAlwaysScrollOnNewCell: 'interactiveWindow.alwaysScrollOnNewCell', <del> interactiveWindowHotExit: 'interactiveWindow.hotExit' </del> <ins> interactiveWindowRestore: 'interactiveWindow.restore' </ins> };

Related discussion:
text: Testing microsoft/vscode-jupyter The setting description says that the 'interactive window session' is restored. But after a reload, it seems that the state has been forgotten e.g. Open the interactive window run run prints 9 reload the window the output is restored but running again will show Note that I had to retype print(x) as there was no way to rerun the previously shown cells What's restored seems to be the last output. Maybe the settings description can clarify that?
Code change:
export const InteractiveWindowSetting = { interactiveWindowAlwaysScrollOnNewCell: 'interactiveWindow.alwaysScrollOnNewCell', <del> interactiveWindowHotExit: 'interactiveWindow.hotExit' </del> <ins> interactiveWindowRestore: 'interactiveWindow.restore' </ins> };

Related discussion:
text: Testing microsoft/vscode-jupyter IMO is about restoring a editor with unsaved changes, but the interactiveWindow doesn't seem to have a dirty state. Maybe just call it 'interactiveWindow.restore`? It's actually not really a window ;-)
Good point Martin, I think calling it makes better sense. is a bit ambiguous, we can revisit the name for it in the core when we stabilize the API.
Code change:
model.dispose(); mode.dispose(); }); <ins> test('issue #45369: Select to Bracket with multicursor', () => { let mode = new BracketMode(); let model = TextModel.createFromString('{  }   {   }   { }', undefined, mode.getLanguageIdentifier()); withTestCodeEditor(null, { model: model }, (editor, cursor) => { let bracketMatchingController = editor.registerAndInstantiateContribution<BracketMatchingController>(BracketMatchingController); // cursors inside brackets become selections of the entire bracket contents editor.setSelections([ new Selection(1, 3, 1, 3), new Selection(1, 10, 1, 10), new Selection(1, 17, 1, 17) ]); bracketMatchingController.selectToBracket(); assert.deepEqual(editor.getSelections(), [ new Selection(1, 1, 1, 5), new Selection(1, 8, 1, 13), new Selection(1, 16, 1, 19) ]); // cursors to the left of bracket pairs become selections of the entire pair editor.setSelections([ new Selection(1, 1, 1, 1), new Selection(1, 6, 1, 6), new Selection(1, 14, 1, 14) ]); bracketMatchingController.selectToBracket(); assert.deepEqual(editor.getSelections(), [ new Selection(1, 1, 1, 5), new Selection(1, 8, 1, 13), new Selection(1, 16, 1, 19) ]); // cursors just right of a bracket pair become selections of the entire pair editor.setSelections([ new Selection(1, 5, 1, 5), new Selection(1, 13, 1, 13), new Selection(1, 19, 1, 19) ]); bracketMatchingController.selectToBracket(); assert.deepEqual(editor.getSelections(), [ new Selection(1, 1, 1, 5), new Selection(1, 8, 1, 13), new Selection(1, 16, 1, 19) ]); bracketMatchingController.dispose(); }); model.dispose(); mode.dispose(); }); </ins> });

Related discussion:
text: Issue Type: <bBug</bmultiple brackets "" Expected: All cursors at brackets become selections starting where the original cursor was and and ending at its matching bracket. Actual: Only the first cursor becomes a selection, the rest dissapear. VS Code version: Code 1.21.0 (, 2018-03-07T10:54:22.798Z) OS version: Darwin x64 17.3.0 </detailsReproduces without extensions <!-- generated by issue reporter --
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.531 --- <!-- score: 0.527 --- <!-- score: 0.498 --- <!-- score: 0.498 --<!-- potentialduplicatescomment --
Code change:
} get persistentProcessId(): number | undefined { return this._processManager.persistentProcessId; } <del> get shouldPersist(): boolean { return this._processManager.shouldPersist; } </del> <ins> get shouldPersist(): boolean { return this._processManager.shouldPersist && !this.shellLaunchConfig.disablePersistence; } </ins> /** * Create xterm.js instance and attach data listeners.

Related discussion:
text: Currently we enable the persistent terminal/reconnect feature if a terminal is launched by an extension, unlike the env var relaunch where we disable outright because it can cause issues with the extension as it loses access to the terminal upon relaunch. Relaunching the PowerShell extension right now for example is a bit of a weird experience though because it creates the "PowerShell Integrated Console", and that reconnects upon reload but is no longer managed by the extension. Before reload: ! After reload it is restored, but no longer owned by the extension: ! Assigning to March for exploration. Thoughts
I think just allowing opt-out/opt-in on this behavior would be more than enough for PowerShell's case.
Has there been any progress on this? Now that persistent terminals are the default, this gets quite annoying and bothers users when extension-owned terminals come back but aren't actually connected.
No progress, we'll try get it in the next version
proposal:
Is this still ongoing and targeted for February?
Yes it is
Code change:
} private onReady(container: HTMLElement, recentlyOpened: TPromise<{ files: URI[]; workspaces: (IWorkspaceIdentifier | ISingleFolderWorkspaceIdentifier)[]; }>, installedExtensions: TPromise<IExtensionStatus[]>): void { <del> const enabled = isWelcomePageEnabled(this.configurationService); </del> <ins> const enabled = isWelcomePageEnabled(this.configurationService, this.contextService); </ins> const showOnStartup = <HTMLInputElement>container.querySelector('#showOnStartup'); if (enabled) { showOnStartup.setAttribute('checked', 'checked');

Related discussion:
text: When you open a recent project from the welcome screen, the last one remains opened in a tab. VSCode Version: 1.9.1 OS Version: macOS Sierra 10.12.3 Steps to Reproduce: a new VSCode window. a recent project from the welcome screen. project is opened and the welcome screen remains opened.
The current behavior was chosen in the hope that this would help new users by staying in the same context.
I agree that the welcome screen should be closed after taking an action from it. Especially in my case, where I prefer to use the setting, having to close the otherwise empty welcome window after opening from the 'Recents' list or via FileOpen feels like a bug.
You can just not show it at all. Or do you need any of the actions on it? (I'm trying to preserve the new user experience here which relies much more on guidance.)
It's ok showing the welcome screen, but it should be closed after opening a project from there.
With we change the Welcome editor to open in preview mode, this way it will close when the next editor opens. (If preview mode is not disabled in settings.)
This could be an additional value for the setting.
Hey, I could look into this. Got any tips on where I should start ?
Great: Add an additional enum literal here: Check for that literal and the 'open folder' condition here:
Hey , I've ran into some questions which you might be able to help me with: should I name the enum literal? I can't seem to come up with the right name would I check for the 'open folder' condition?
You could use . Check for no folder being open: . You can get at the context service by adding it to the constructor of the calling class, similar to:
Hey everything seems to be working now, just one last question which is confusing me: isn't the objective of this issue to NOT show the Welcome Page when opening a new project? So why is your enum suggestion welcomePageInEmptyWorkbench? What is happening right now after my additions is: upon opening a new project, no Welcome Page is shown. Is this right?
Show it only in the empty workbench. :)
Hey Now I'm getting upon opening a new window (empty workbench). Any ideas? I did the comparison as you said for no folder being open.
Is the ?
Code change:
} private onReady(container: HTMLElement, recentlyOpened: TPromise<{ files: URI[]; workspaces: (IWorkspaceIdentifier | ISingleFolderWorkspaceIdentifier)[]; }>, installedExtensions: TPromise<IExtensionStatus[]>): void { <del> const enabled = isWelcomePageEnabled(this.configurationService); </del> <ins> const enabled = isWelcomePageEnabled(this.configurationService, this.contextService); </ins> const showOnStartup = <HTMLInputElement>container.querySelector('#showOnStartup'); if (enabled) { showOnStartup.setAttribute('checked', 'checked');

Related discussion:
text: You can debug it either in VS Code or in the Developer Tools (Help Toggle Developer Tools in the window running from source).
Upon opening a new window, it isn't undefined (verified by a console log) but then it turns undefined (verified by the same console log). Edit: and immediately after Edit2: Found it! Seems like isWelcomePageEnabled() is called twice, once in the class constructor and the other one in the onReady method. I'll make the PR in a bit
Code change:
Registry.as<IWorkbenchContributionsRegistry>(WorkbenchExtensions.Workbench).registerWorkbenchContribution(EditorStatus, LifecyclePhase.Ready); Registry.as<IWorkbenchContributionsRegistry>(WorkbenchExtensions.Workbench).registerWorkbenchContribution(UntitledTextEditorWorkingCopyEditorHandler, LifecyclePhase.Ready); Registry.as<IWorkbenchContributionsRegistry>(WorkbenchExtensions.Workbench).registerWorkbenchContribution(DynamicEditorGroupAutoLockConfiguration, LifecyclePhase.Ready); <ins> Registry.as<IWorkbenchContributionsRegistry>(WorkbenchExtensions.Workbench).registerWorkbenchContribution(DefaultBinaryEditorConfiguration, LifecyclePhase.Ready); </ins> registerEditorContribution(OpenWorkspaceButtonContribution.ID, OpenWorkspaceButtonContribution);

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:
MenuRegistry.appendMenuItem(MenuId.EditorTitle, { command: { id: TOGGLE_MAXIMIZE_EDITOR_GROUP, title: localize('maximizeGroup', "Maximize Group") }, group: '8_group_operations', order: 5, when: ContextKeyExpr.and(EditorPartMaximizedEditorGroupContext.negate(), EditorPartMultipleEditorGroupsContext) }); MenuRegistry.appendMenuItem(MenuId.EditorTitle, { command: { id: TOGGLE_MAXIMIZE_EDITOR_GROUP, title: localize('unmaximizeGroup', "Unmaximize Group") }, group: '8_group_operations', order: 5, when: EditorPartMaximizedEditorGroupContext }); MenuRegistry.appendMenuItem(MenuId.EditorTitle, { command: { id: TOGGLE_LOCK_GROUP_COMMAND_ID, title: localize('lockGroup', "Lock Group"), toggled: ActiveEditorGroupLockedContext }, group: '8_group_operations', order: 10, when: IsAuxiliaryEditorPartContext.toNegated() /* already a primary action for aux windows */ }); <ins> MenuRegistry.appendMenuItem(MenuId.EditorTitle, { command: { id: ConfigureEditorAction.ID, title: localize('configureEditor', "Configure Editor ...") }, group: '9_configure', order: 10 }); </ins> function appendEditorToolItem(primary: ICommandAction, when: ContextKeyExpression | undefined, order: number, alternative?: ICommandAction, precondition?: ContextKeyExpression | undefined): void { const item: IMenuItem = {

Related discussion:
text: ! is not very discoverable. If it would be a submenu of the context menu, it would be much easier to tweak this setting.
...
I'm for making these types of settings more discoverable, however, I do not want to add these types of settings to the contextmenu. We mainly use the context menu to change the visibility of elements/features but we don't really use it to configure them/change appearance. Also, the context menu is already pretty full and I don't want to overload it.
I'm open to other ideas to make them more discoverable. Maybe a "configure" entry in the overflow menu of the toolbar?
Yeah I like the idea of an action in the "..." menu to configure all things editor related by narrowing down a settings search in the settings editor.
verification steps: Right click on the tab bar (not on a tab) At the bottom of the context menu there is an action "Configure Tabs...", press it Settings editor should open with tabs related settings
Code change:
{ "name": "code-oss-dev", "version": "1.83.0", <del> "distro": "46e7bb69af9f06de037c3d7e8f61de4a679f9ef1", </del> <ins> "distro": "c13fa037c20b672a48c9e7990df10998974196f9", </ins> "author": { "name": "Microsoft Corporation" },

Related discussion:
text: Version 1.74.0, when I open the developer tools, it becomes a floating window, which is very unfriendly for extension developers, please add at least one option to use the old layout. !
Was caused by an upstream electron bug with WCO Believe there are plans to restore the docking feature in the near future now that the electron issue is resolved.
I found that if you toggle OFF the setting, Developer Tools docking functionality is restored AND you also still get the WCO experience (perhaps that's a separate bug?). Suggest docking at the bottom instead of to the right if there's any visual conflict due to the aforementioned electron bug.
It work, thanks!.
The setting will be removed at one point, keeping the issue open to provide and dock options when WCO is enabled.
I manged to get it to dock again with 's workaround but I noticed in the dev tool now it shows the HTML for the VS code app instead of the file I have open in the preview !
Related Stack Overflow question:
This makes working on Windows really awful for me, I think the upstream bug is fixed.
To give some context, with WCO chromium has a bug in orienting devtools window when docked to the position where the Window controls are, basically they overlap making it harder to use the close, minimize or maximize button. Chromium always pop out the devtools window in PWA for this scenario and Electron inherited this by default. The fix in does not address the aligning behavior but rather provides a workaround that calling would be respected even in the WCO scenario rather than forcing to always detach. Now, on our end to incorporate this fix we need to change all our callsite with a mode otherwise we will default to detach as seen in this logic Say we chose as default and user later reposition it to right or left then this new state will be persisted to json file under the user data directory, in non WCO cases this saved preference will be applied next time when calling or without a mode value from the application side, that is how user's preferred position is applied. But in the WCO case, this does not take effect so we need a logic on VSCode side to read the preference value and adjust the start mode with it. I didn't want to make this change yet in core hence this issue remains open, I will tackle it in debt week.
Code change:
{ "name": "code-oss-dev", "version": "1.83.0", <del> "distro": "46e7bb69af9f06de037c3d7e8f61de4a679f9ef1", </del> <ins> "distro": "c13fa037c20b672a48c9e7990df10998974196f9", </ins> "author": { "name": "Microsoft Corporation" },

Related discussion:
text: I see this as an issue when you dock the devtools to the right, but why is the ability to dock it at the bottom taken away? This seems to work just fine with WCO. But on Windows, a user is not able to reposition the devtools at all? This functionality seems to be truly gone, so a setting for Windows only would be a decent workaround and good improvement over what we have today. If we decide on a setting that forces the location, I can see to do such a change.
I am good with a setting to force the bottom position only on Windows. I will see if the runtime behavior can be improved to avoid docking the devtools to the position where the controls are present as part of this issue.
The dock options are back, though setting it to dock on the right looks funny with the WCO in the way. !
Yes that is the original bug in chromium which is not addressed.
In the new version, if the developer tools are on the right side, the close button will be blocked, which is not as good as the old version of . !
use a dock position that is not overlapping with the window controls, by default the devtools will not dock to the position were the window controls are to avoid the bug.
I know, but I always put the developer tools on the right, which is where I'm most productive.
Is it possible to revert "window.experimental.windowControlsOverlay.enabled" to a VS Code new version? In order for the developer tools to be correctly positioned on the right side, I now have to go back to VS Code version 1.81 and disable updates. !
is there an issue where we are tracking how the WCO is overlapping the devtools?
no we are not tracking it in the runtime, unless you have manually docked it to the overlapping position devtools by default would be undocked. The overlapping position in the runtime will not resolved anytime soon.
Code change:
* Given a stable rendered state, checks every rendered element whether it needs * to be probed for dynamic height. Adjusts scroll height and top if necessary. */ <del> private _rerender(renderTop: number, renderHeight: number): void { </del> <ins> private _rerender(renderTop: number, renderHeight: number, updateScrollTop: boolean = true): void { </ins> const previousRenderRange = this.getRenderRange(renderTop, renderHeight); // Let's remember the second element's position, this helps in scrolling up

Related discussion:
text: Issue Type: <bBug</bWhen : one mouse wheel scroll in extension view: moves 100px one mouse wheel scroll in settings editor: moves 100px When : one mouse wheel scroll in extension view: moves 100px, with slight animation one mouse wheel scroll in settings editor: moves 15~25px, without animation I'm using a Logitech G502 Lightspeed mouse, without any scrolling tweaking softwares. ! VS Code version: Code - Insiders 1.48.0-insider (, 2020-08-05T05:30:25.429Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </detailsExtensions: none <!-- generated by issue reporter --
I don't see this, any idea
I believe this setting is ignored for macOS. Duplicate of
Actually not a duplicate. Interesting. I need to get my hands on a mouse to see if I can repro.
Created a PR that fixes this: