jiebi/CodeConvo huggingface dataset:
Code change:
return TerminalInstance._lastKnownCanvasDimensions; } <del> set shutdownPersistentProcessId(shutdownPersistentProcessId: number | undefined) { this._shutdownPersistentProcessId = shutdownPersistentProcessId; } get persistentProcessId(): number | undefined { return this._processManager.persistentProcessId ?? this._shutdownPersistentProcessId; } get shouldPersist(): boolean { return (this._processManager.shouldPersist || this._shutdownPersistentProcessId !== undefined) && !this.shellLaunchConfig.isTransient && (!this.reconnectionProperties || this._configurationService.getValue(TaskSettingId.Reconnection) === true); } </del> <ins> get persistentProcessId(): number | undefined { return this._processManager.persistentProcessId; } get shouldPersist(): boolean { return this._processManager.shouldPersist && !this.shellLaunchConfig.isTransient && (!this.reconnectionProperties || this._configurationService.getValue(TaskSettingId.Reconnection) === true); } </ins> /** * Create xterm.js instance and attach data listeners.

Related discussion:
text: /duplicate
Reviving editor-area terminals was working great in 1.73.x. This was marked as a duplicate of a feature request. Is it not a regression?
Created a PR with a possible fix
VSCode v1.74.2 occurs the same problem, does the fix takes effect or I need to config some settings?
The fix will be available in 1.75 release or you can try it in insiders
Code change:
configHelper: ITerminalConfigHelper, shellLaunchConfig: IShellLaunchConfig ): ITerminalInstance { <ins> const newTerminalSize = ((this._panelPosition === Position.BOTTOM ? this._container.clientWidth : this._container.clientHeight) / (this._terminalInstances.length + 1)); if (newTerminalSize < TERMINAL_MIN_USEFUL_SIZE) { return undefined; } </ins> const instance = this._terminalService.createInstance( terminalFocusContextKey, configHelper,

Related discussion:
text: With latest release (1.21) you can split terminal infinitely. This breaks badly the terminal area. Probably the IDE should limit this to a defined maximum or something?
I considered adding a max value but you would always be able to break it then by sizing down. As a mitigation we could disallow creating terminals if the desired room isn't there but the real fix is proper overflow behavior.
Thanks , I would agree that proper overflow behaviour is the way to go. Thanks!
I think the easiest way to improve this is to only allow terminals to be created if there's a reasonable amount of room. This can exist with our current lack of overflow behavior as it's an improvement on the current and will prevent 100 terminals from being created..
Some terminal can be resized to a small size if they are not important. In some case, showing multiple terminals is just to notify the user whether they are running. Currently the minimum size of terminal is too large.
I suggest the minimum size of a terminal should be an option in Settings.
Code change:
*--------------------------------------------------------------------------------------------*/ .accessible-view { <del> position: relative; </del> <ins> position: absolute; </ins> background-color: var(--vscode-editorWidget-background); color: var(--vscode-editorWidget-foreground); box-shadow: 0 2px 8px var(--vscode-widget-shadow); <del> border: 2px solid var(--vscode-contrastActiveBorder); </del> <ins> border: 2px solid var(--vscode-focusBorder); </ins> }

Related discussion:
text: When resizing the windows while the accessible help menu is visible, the help menu slides diagonally: !
Code change:
*--------------------------------------------------------------------------------------------*/ .accessible-view { <del> position: relative; </del> <ins> position: absolute; </ins> background-color: var(--vscode-editorWidget-background); color: var(--vscode-editorWidget-foreground); box-shadow: 0 2px 8px var(--vscode-widget-shadow); <del> border: 2px solid var(--vscode-contrastActiveBorder); </del> <ins> border: 2px solid var(--vscode-focusBorder); </ins> }

Related discussion:
text: Repro: Alt+F1 ! If should be in the center as that's the most obvious location Version: 1.80.0-insider (user setup) Commit: Date: 2023-06-28T08:01:04.380Z Electron: 22.3.14 ElectronBuildId: Chromium: 108.0.5359.215 16.17.1 V8: 10.8.168.25-electron.0 OS: Windows_NT x64 10.0.
Putting it here makes the most sense to me because that's where we put other components - like the quick pick. I want to get feedback from low vision users
That's fine, but if you're styling like the command palette we should position it in a similar way ! So below the title bar and not quite and maybe a little less wide
Re , we should also size the height similar to quick pick
But shouldn't the height be determined by the contents?
yes, but have a similar height cap to the quick pick
We should also use the same font as the quick pick
I think you've convinced me - this should be in the center.
Personally I preferred the top position, I'd just render it as the quick pick: Same position and same style. VS Code does not have many vertically centered dialogs. If you want to make it vertically centered, I'd suggest to align it with other vertically centered dialogs, like the trust dialog (notice the background shadow): ! ! Generally, I think, if there is no particular reason to be different, we should try to have a consistent UI throughout the entire product. I'm still in favor of the top position, as the workspace trust dialog is the only vertically centered dialog I know of and it is strongly modal (you have to click one of the buttons to make it disappear). FYI
Fading the background like the trust dialog is good imo, I like centered as it's a very special mode and it's modal as in clicking outside will always dismiss it, unlike the quick pick which may not dismiss when clicking outside. In the end the visual appearance isn't that important really, I just want it to be very obvious when the accessible view is up.
I agree that we should try to align with existing design. My personal preference is to have it positioned like the quick pick.
Code change:
*--------------------------------------------------------------------------------------------*/ .accessible-view { <del> position: relative; </del> <ins> position: absolute; </ins> background-color: var(--vscode-editorWidget-background); color: var(--vscode-editorWidget-foreground); box-shadow: 0 2px 8px var(--vscode-widget-shadow); <del> border: 2px solid var(--vscode-contrastActiveBorder); </del> <ins> border: 2px solid var(--vscode-focusBorder); </ins> }

Related discussion:
text: But in the end, it is not super important as pointed out.
One issue with doing it as the quick pick is it would look wrong being so narrow, and making is narrow would make it less accessible, say if a low vision user was using it.
Not sure it needs to be as narrow as quick pick. I just think the positioning of the quick pick is fitting. So the top and center. It could be wider or longer.
Now that we have the focus border, it is more obvious, so fine to be at the top IMO.
This is still not fixed imo, it should follow quick pick and look like this (native title bar): ! Not this (custom title bar): !
Verified off main :+1:
Code change:
// Use the repository real path const repoPathRealPath = await fs.promises.realpath(repoPath, { encoding: 'utf8' }); const openRepositoryRealPath = this.openRepositories <del> .find(r => pathEquals(r.repository.rootRealPath ?? '', repoPathRealPath)); </del> <ins> .find(r => pathEquals(r.repository.rootRealPath ?? r.repository.root, repoPathRealPath)); </ins> return openRepositoryRealPath?.repository; } catch (err) {

Related discussion:
text: Type: <bBug</ba git repository on a UNC path the folder in VS Code the repository as safe ! repositories will be shown instead of one. ! The issue is ephemeral and only one repo shows after reloading the window. ! VS Code version: Code 1.84.2 (, 2023-11-09T10:51:52.184Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (17)</summaryExtensionVersion ------ 2sxc0.0.1 vscode-tailwindcss0.10.3 dart-code3.76.1 flutter3.76.0 xml2.5.1 batch-rename-extension0.0.6 csdevkit1.0.14 csharp2.10.28 vscode-dotnet-runtime2.0.0 vscodeintellicode-csharp0.1.26 python2023.20.0 vscode-pylance2023.11.10 remote-ssh0.107.0 remote-ssh-edit0.86.0 remote-explorer0.4.1 sqltools0.28.0 postman-for-vscode0.13.1 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
are you able to reproduce the issue with the latest ? I went through the steps, but in my case only one repository is being shown. If you are able to reproduce with the latest VS Code Insiders release, could you please go through the steps up until the point where two repositories are shown and share the contents of ? Thanks!
<!-- 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!
Code change:
createPreferencesEditorModel<T>(uri: URI): TPromise<IPreferencesEditorModel<T>>; openRawDefaultSettings(): TPromise<void>; <ins> openRawUserSettings(): TPromise<void>; </ins> openSettings(): TPromise<IEditor>; openSettings2(): TPromise<IEditor>; openGlobalSettings(options?: IEditorOptions, position?: Position): TPromise<IEditor>;

Related discussion:
text: We have a setting to disable the settings split view, but it might be useful to have a command to open the user outside of the split view for a one-off. From
I am reverting the PR, it actually doesn't work. We intercept the editor open here:
Damn, it's already a part of my workflow . What's wrong with it?
So it opens the raw outside of the split view for you? For me, it actually just acts the same as the normal open settings command and opens the settings split view.
And you don't have ?
I don't have . The command itself works for me. Does it break some other functionality? ! OS version: Windows_NT x64 10.0.
I see now. Opens a split view on linux VM. Was it ever working before on non-Windows environments?
Yeah it only works on Windows, because the == check with fspath can fail due to drive letters being different. I guess that's a separate bug... I'll revert this tomorrow.
We got a good bug out of this:
Now that the settings UI exists, I don't plan on investigating much more on the JSON editor. The split JSON UI will probably go away at some point (the JSON files themselves will always remain)
BUT I CAN'T OPEN SETTINGS FILE (WITHOUT SPLIT) NOW AT ALL BECAUSE IT'S NOT LETTING ME. Are you planning to allow users to see plain json file or to forbid it completely?
We will always allow users to see the json file. Hopefully you can still open the raw json file with .
I know about that option, it's not great.
I'll close this just because I am cleaning up issues that are specific to the JSON split editor. But to be clear, editing the JSON file will never go away :)
Code change:
import { webFrame } from 'electron'; import { assign } from 'vs/base/common/objects'; import { IWorkbenchIssueService } from 'vs/workbench/contrib/issue/electron-browser/issue'; <del> import { ExtensionType } from 'vs/platform/extensions/common/extensions'; </del> import { IWorkbenchEnvironmentService } from 'vs/workbench/services/environment/common/environmentService'; import { INativeWorkbenchEnvironmentService } from 'vs/workbench/services/environment/electron-browser/environmentService'; <ins> import { ExtensionType } from 'vs/platform/extensions/common/extensions'; </ins> export class WorkbenchIssueService implements IWorkbenchIssueService { _serviceBrand: undefined;

Related discussion:
text: Feature Request The command takes an extension argument so that extensions can open an issue reporter for that extension. I'd like to use this for the built-in JS/TS extension as well but cannot at the moment: It'd be nice if for VS Code builtin extensions, we automatically changed the field to
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to upvote 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!
Code change:
box-sizing: border-box; height: 100%; width: 100%; <ins> padding-right: 22px; </ins> } .monaco-editor .suggest-widget .details > .monaco-scrollable-element > .body > .header > .type {

Related discussion:
text: <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --Steps to Reproduce: a vscode extension repository (e.g. ) to contributes commands (e.g. ). "command" and observe the tooltip <img width="857" alt="Screen Shot 2020-09-05 at 21 07 16" src="https://user-"<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes Does this issue occur on Insider?: Yes
Code change:
'editor.trimAutoWhitespace', 'editor.folding', 'workbench.editor.enablePreviewFromQuickOpen', <ins> 'php.builtInCompletions.enable', </ins> 'php.validate.enable', <ins> 'php.validate.run', </ins> 'editor.parameterHints', ];

Related discussion:
text: There is now a better Intellisense plugins for Vscode PHP: and . In it's known issues it says "There may be duplicate suggestions for functions or variables. This is because VS Code has it's own (very limited) code-completion support for PHP, and there is currently no way to turn this off." This indeed is annoying, the vscode suggestions are too broad and are just noise compared to accurate entries by crane.
It should be possible to uninstall the VS Code php extension.
fyi
I think crane still uses vscode's syntax highlighter for PHP. So if one were to remove VSCode's internal PHP extension, would it also remove the syntax highlighter? P.S. I think simple options would suffice, e.g. "", so it could be turned off.
Yes - but we can also think about splitting our extension into one part that does highlighting and bracket config and another that does completions. That would allow for more freedom.
This is now annoying the testing of proper language server in here : Quote: P.S. I think the option would be a simplest thing to implement for now.
Related
Any update on this?
I have been holding back the PHP IntelliSense release with intelligent completion for over a month now because it is useless if VS Code just spams the completion list with countless functions that do not make sense in the context. When will we get the option to disable or uninstall the built-in PHP completion?
I agree it makes sense to provide a temporary option to disable this. Just submitted a PR here:
Also just checking - at this point in time, is there anything else about the built-in support that is interfering with the experience? (hover, signature help, etc.?)
thanks for looking into this. Signature help is being implemented right now, iirc there is no built-in hover. It would be great if all of them could be disabled (everything except syntax highlighting).
I pushed the PR and changes the setting name for the code completion to "". If disabled, hover and signature help are also disabled.
I don't think the setting achieves the desired result. Setting to I no longer get completion suggestions even from PHP Intellisense extension. If have to use to trigger the completion suggestions list.
I don't think this is related, this only removes the built-in completion provider.
Code change:
'editor.trimAutoWhitespace', 'editor.folding', 'workbench.editor.enablePreviewFromQuickOpen', <ins> 'php.builtInCompletions.enable', </ins> 'php.validate.enable', <ins> 'php.validate.run', </ins> 'editor.parameterHints', ];

Related discussion:
text: So something else which controls the display of suggestions list from extensions like php intellisense is broken?
Part of the January build. Add to your settings to disable all completions from the built-in PHP extension.
Code change:
italic: register('italic', 0xeb0d), jersey: register('jersey', 0xeb0e), json: register('json', 0xeb0f), <ins> bracket: register('bracket', 0xeb0f), </ins> kebabVertical: register('kebab-vertical', 0xeb10), key: register('key', 0xeb11), law: register('law', 0xeb12),

Related discussion:
text: Type: <bBug</ba TS file at the language status item in the status bar Bug The bracket icon is instead rendered as a pie chart icon <img width="222" alt="Screenshot 2023-01-18 at 1 28 37 PM" src="https://user-"VS Code version: Code - Insiders 1.75.0-insider (Universal) (, 2023-01-18T08:53:10.224Z) OS version: Darwin x64 22.2.0 Modes: Sandboxed: Yes <details<summarySystem Info</summary </details<!-- generated by issue reporter --
Looks like the id for got duplicated:
Code change:
if (editorGutterModifiedBackgroundColor) { collector.addRule(` .monaco-editor .dirty-diff-modified { <del> background-size: 3px 4.5px; </del> background-repeat-x: no-repeat; background-image: linear-gradient(${linearGradient}); transition: opacity 0.5s;

Related discussion:
text: <!-- Do Not Delete This! bugreporttemplate --Version: 1.66.0 (system setup) Commit: Date: 2022-03-30T05:50:14.623Z Electron: 17.2.0 Chromium: 98.0.4758.109 16.13.0 V8: 9.8.177.11-electron.0 OS: Windows_NT x64 10.0. New "striped" gutter decorations were in . These decorations do not respect the existing SCM: Diff Decorations Gutter Width setting: Changing the above setting has no effect on the new decorations.
I think this was an oversight and have a PR that can help address this. Thanks!
Code change:
result = result || MouseTargetFactory._hitTestMargin(ctx, resolvedRequest); result = result || MouseTargetFactory._hitTestViewCursor(ctx, resolvedRequest); result = result || MouseTargetFactory._hitTestTextArea(ctx, resolvedRequest); <del> result = result || MouseTargetFactory._hitTestViewLines(ctx, resolvedRequest, domHitTestExecuted); </del> <ins> result = result || MouseTargetFactory._hitTestViewLines(ctx, resolvedRequest); </ins> result = result || MouseTargetFactory._hitTestScrollbar(ctx, resolvedRequest); return (result || request.fulfillUnknown());

Related discussion:
text: <!-- 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: 1.88.0-insider in Safari OS Version: macOS Steps to Reproduce: Safari open a file with: to the right of any the cursor goes to the beginning of the line not the end This does not repro in stable
I didn't do any changes the last couple of milestones that could (easily) explain this. Can you reproduce this in the monaco editor? If so, can you do a bisect?
I bisected it to this commit: (the commit before it) does not repro the issue. This wasn't in Monaco editor, I just used run code web:
This commit is just a rename refactoring. It is very unlikely it causes this... This does not reproduce in chrome, right?
The bug does not reproduce in Edge on macOS, but it repros in Safari.
Unfortunately, I don't have access to Safari. Can you double check that this is caused by that commit? Can you locally rename the class back to the original name and see if it still happens? It does not make any sense that this commit would cause this behavior only on Safari.
Ok and I paired a bit on this and are really stumped. Bad news: That commit I called out seems to be a red herring. Good news: we can repro in the Monaco Editor Playground.
Code change:
result = result || MouseTargetFactory._hitTestMargin(ctx, resolvedRequest); result = result || MouseTargetFactory._hitTestViewCursor(ctx, resolvedRequest); result = result || MouseTargetFactory._hitTestTextArea(ctx, resolvedRequest); <del> result = result || MouseTargetFactory._hitTestViewLines(ctx, resolvedRequest, domHitTestExecuted); </del> <ins> result = result || MouseTargetFactory._hitTestViewLines(ctx, resolvedRequest); </ins> result = result || MouseTargetFactory._hitTestScrollbar(ctx, resolvedRequest); return (result || request.fulfillUnknown());

Related discussion:
text: Here's a side by side of two versions of the dev build: <img width="1680" alt="image" src=""You can see when I click to the right of a line, the older (working) build has the correct position here, while the newer broken build has column 1. Here are the links to these versions: Working: Broken: I believe this is out of both of our depths at this point so I'm passing to you This is a regression so I think it should be fixed before we release (assuming I'm not the only one to repro)
Did a bisect using and it points to
In that case, it is most likely .
Code change:
/** * An optional validation message indicating a problem with the current input value. */ <del> validationMessage: string | undefined; </del> <ins> validationMessage: string | InputBoxValidationMessage | undefined; </ins> } /**

Related discussion:
text: <!-- 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. --We already have this feature in Core: where you can return where . Truth be told, this already works in API today though it's not officially a part of the API today (so it could change at any moment). For example, I can do: <img width="738" alt="image" src="https://user-"with it goes from: to it goes from: to
ref
Created a TPI so moving this to April for Finalization.
Code change:
store.add(this.registerDefaultParticipantView(providerDescriptor)); } <del> if (providerDescriptor.when && !isProposedApiEnabled(extension.description, 'chatParticipantAdditions')) { this.logService.error(`Extension '${extension.description.identifier.value}' CANNOT use API proposal: chatParticipantAdditions.`); continue; } </del> store.add(this._chatAgentService.registerAgent( providerDescriptor.id, {

Related discussion:
text: The static "when" clause on chat participants should be moved to the set of things that are finalized.
what would happen when a participant becomes "disabled" after having been interacted with? Evaluating going from to and to again
It would just stop showing up in the suggest widget and you wouldn't be able to invoke it. But it can still show up in your conversation thread. Same as if you uninstall a chat extension.
Verify that can be set and used on the chat participant contribution in without api proposal needed. Easiest to use the .