jiebi/CodeConvo huggingface dataset:
Code change:
readonly type: string; readonly entrypoint: URI; readonly extensionLocation: URI; <ins> readonly localResourceRoots: readonly URI[]; </ins> constructor(descriptor: { readonly type: string; readonly entrypoint: string; <ins> readonly localResourceRoots: readonly string[]; </ins> readonly extension: IExtensionDescription; }) { this.type = descriptor.type; this.entrypoint = joinPath(descriptor.extension.extensionLocation, descriptor.entrypoint); this.extensionLocation = descriptor.extension.extensionLocation; <ins> this.localResourceRoots = descriptor.localResourceRoots.map(root => joinPath(descriptor.extension.extensionLocation, root)); </ins> } }

Related discussion:
text: select the above venv as a kernel) You might get prompted to enable CDN download, hit cancel for that The widget will not load, network tab in vscode will display a 401 error !
I'm still unable to reproduce this issue Are you running the jupyter out of sources by chance or have you patched VS Code/jupyter in some other way? The path to the resource we a trying to load looks weird: . This looks like an extension development path In normal installs, we should load resources from a path that looks more like: If you are able, you can also try and sharing the result of that function compared to the path of the js file we try loading in the webview
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
information was provided
lets you specific an additional set of localResourceRoots that should be allowed when loading the preload. Can you please try adding these for the python static preload contribution? Let me know if fixes the problem!
Thanks , seems to work,
Changes were made upstream in VS Code, marking as verified.
Code change:
const category = nls.localize('preferences', "Preferences"); const registry = Registry.as<IWorkbenchActionRegistry>(Extensions.WorkbenchActions); registry.registerWorkbenchAction(new SyncActionDescriptor(OpenRawDefaultSettingsAction, OpenRawDefaultSettingsAction.ID, OpenRawDefaultSettingsAction.LABEL), 'Preferences: Open Raw Default Settings', category); <ins> registry.registerWorkbenchAction(new SyncActionDescriptor(OpenRawUserSettingsAction, OpenRawUserSettingsAction.ID, OpenRawUserSettingsAction.LABEL), 'Preferences: Open Raw User Settings', category); </ins> registry.registerWorkbenchAction(new SyncActionDescriptor(OpenSettingsAction, OpenSettingsAction.ID, OpenSettingsAction.LABEL, { primary: KeyMod.CtrlCmd | KeyCode.US_COMMA }), 'Preferences: Open Settings', category); registry.registerWorkbenchAction(new SyncActionDescriptor(OpenSettings2Action, OpenSettings2Action.ID, OpenSettings2Action.LABEL), 'Preferences: Open Settings (Experimental)', category); registry.registerWorkbenchAction(new SyncActionDescriptor(OpenGlobalSettingsAction, OpenGlobalSettingsAction.ID, OpenGlobalSettingsAction.LABEL), 'Preferences: Open User Settings', category);

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:
disturl="https://electronjs.org/headers" <del> target="30.5.0" ms_build_id="10198947" </del> <ins> target="30.5.1" ms_build_id="10262041" </ins> runtime="electron" build_from_source="true" legacy-peer-deps="true"

Related discussion:
text: Testing Version: 1.90.0-insider Commit: Date: 2024-05-29T05:51:07.154Z Electron: 29.4.0 ElectronBuildId: Chromium: 122.0.6261.156 20.9.0 V8: 12.2.281.27-electron.0 OS: Linux x64 5.15.0-107-generic open a file in an editor run . This opens a file selection dialog initialized to the home folder
Same problem with open folder dialog
VS Code is awesome, but the open file dialog on Linux has been ridiculously buggy for years. More than two years to fix the problem of the dialog opening in the background. The fix, in the latest version, involves using a dialog inside a portal with no type-ahead support that opens in $HOME or recent files. The open/save file dialog is a crucial control in any application. There should be a way to use the native OS dialog. I'm going to downgrade to the previous version (1.89.1) and keep it as long as it takes.
cc
We hadn't patched the portal code to support most of the file dialogs options, it is being addressed via
This is now addressed in the runtime via , fix will be available once we adopt
Reopening since we have reverted the updated due to other regressions , will be revisited in August.
This issue is not resolved for me, here is for comparison how the file dialog opens in an older version of VS Code vs. now: Good behaviour: ! Bad behaviour: !
Filed
I'm on xfce on xubuntu 22.04. Version 1.89.1-1715060508_amd64 does not have the issue. Later versions do have it. The problem is that instead of forcing the "Open File" path, to that of the current file being edited, vscode delegates the path selection to the operating system, which resolves the "Recent Files" path. Since recent files is truly not useful in vscode, I can at least pilot the path to be that of the home folder with $gsettings set startup-mode 'cwd' from the previous value. Clearly this is very inconvenient. Is there any update about it?
The issue is not resolved for me either.
Code change:
disturl="https://electronjs.org/headers" <del> target="30.5.0" ms_build_id="10198947" </del> <ins> target="30.5.1" ms_build_id="10262041" </ins> runtime="electron" build_from_source="true" legacy-peer-deps="true"

Related discussion:
text: The file-open and directory-open dialogs still do not appear even though built on Electron 30.1.2. This is reproducible 100% of the time in openSUSE Tumbleweed and in Leap.
The file-open/directory-open or save dialog not being shown remains unresolved on Linux in release 1.93.1 built with electron 30.4.0.
Code change:
transform: rotate(-90deg); } <del> .monaco-workbench .part > .title > .title-actions .switch-terminal  { </del> <ins> .monaco-workbench .part.sidebar > .title > .title-actions .switch-terminal, .monaco-pane-view .pane > .pane-header .monaco-action-bar .switch-terminal { border-width: 1px; border-style: solid; } .part.panel > .title > .title-actions .switch-terminal > .monaco-select-box { border-width: 1px; border-style: solid; } .monaco-workbench .part.sidebar > .title > .title-actions .switch-terminal  { </ins> display: flex; align-items: center; font-size: 11px;

Related discussion:
text: The select box in the panel header should have a white background: ! This is similar to the recent breakage with the simple editor widget background color in SCM and extensions views.
To Verify: to an obvious color. that terminal and output select boxes are using these when they are in their default locations in panel.
Code change:
}], viewContainer); Registry.as<IWorkbenchContributionsRegistry>(WorkbenchExtensions.Workbench) <ins> .registerWorkbenchContribution(SCMActiveResourceContextKeyController, LifecyclePhase.Restored); Registry.as<IWorkbenchContributionsRegistry>(WorkbenchExtensions.Workbench) </ins> .registerWorkbenchContribution(SCMStatusController, LifecyclePhase.Restored); Registry.as<IConfigurationRegistry>(ConfigurationExtensions.Configuration).registerConfiguration({

Related discussion:
text: <!-- Do you have a question? Please ask it on --VSCode Version: 1.12.1 OS Version: OS X EI Capitan 10.11.3 Steps to Reproduce: some project from GitHub. a file A.cs which has no fresh changes at all. on the editor of A.cs, and notice the button of on the top right corner above the editor doesn't display as disbled! Clicking it has no effect of course, but it should display as disable in this case just like what in the old versions.
Can't fix without , closing for now.
since it connot be fixed without , should this be kept open and linked to then?
Sure.
To keep the number of issues in our inbox on a manageable level, we're closing issues that have been on the backlog for a long time but haven't gained traction: We look at the number of votes the issue has received and the number of duplicates issues filed. Thanks for your understanding. Happy coding!
Hoping to re-open this because I got this as a feedback item from a few CS educators. They notice their students clicking it accidentally and being confused when there is no apparent action.
I think this has regressed, I now miss this button when a file is staged.
Fixed regression with
There is another regression (), so I will be reverting this fix for this, and will refactor it.
Code change:
"cssnano": "^6.0.3", "debounce": "^1.0.0", "deemon": "^1.8.0", <del> "electron": "30.5.0", </del> <ins> "electron": "30.5.1", </ins> "eslint": "8.36.0", "eslint-plugin-header": "3.1.1", "eslint-plugin-jsdoc": "^46.5.0",

Related discussion:
text: Testing Version: 1.90.0-insider Commit: Date: 2024-05-29T05:51:07.154Z Electron: 29.4.0 ElectronBuildId: Chromium: 122.0.6261.156 20.9.0 V8: 12.2.281.27-electron.0 OS: Linux x64 5.15.0-107-generic open a file in an editor run . This opens a file selection dialog initialized to the home folder
Same problem with open folder dialog
VS Code is awesome, but the open file dialog on Linux has been ridiculously buggy for years. More than two years to fix the problem of the dialog opening in the background. The fix, in the latest version, involves using a dialog inside a portal with no type-ahead support that opens in $HOME or recent files. The open/save file dialog is a crucial control in any application. There should be a way to use the native OS dialog. I'm going to downgrade to the previous version (1.89.1) and keep it as long as it takes.
cc
We hadn't patched the portal code to support most of the file dialogs options, it is being addressed via
This is now addressed in the runtime via , fix will be available once we adopt
Reopening since we have reverted the updated due to other regressions , will be revisited in August.
This issue is not resolved for me, here is for comparison how the file dialog opens in an older version of VS Code vs. now: Good behaviour: ! Bad behaviour: !
Filed
I'm on xfce on xubuntu 22.04. Version 1.89.1-1715060508_amd64 does not have the issue. Later versions do have it. The problem is that instead of forcing the "Open File" path, to that of the current file being edited, vscode delegates the path selection to the operating system, which resolves the "Recent Files" path. Since recent files is truly not useful in vscode, I can at least pilot the path to be that of the home folder with $gsettings set startup-mode 'cwd' from the previous value. Clearly this is very inconvenient. Is there any update about it?
The issue is not resolved for me either.
Code change:
"cssnano": "^6.0.3", "debounce": "^1.0.0", "deemon": "^1.8.0", <del> "electron": "30.5.0", </del> <ins> "electron": "30.5.1", </ins> "eslint": "8.36.0", "eslint-plugin-header": "3.1.1", "eslint-plugin-jsdoc": "^46.5.0",

Related discussion:
text: The file-open and directory-open dialogs still do not appear even though built on Electron 30.1.2. This is reproducible 100% of the time in openSUSE Tumbleweed and in Leap.
The file-open/directory-open or save dialog not being shown remains unresolved on Linux in release 1.93.1 built with electron 30.4.0.
Code change:
if (this.profileContentHandlers.size === 1) { return this.profileContentHandlers.values().next().value; } <del> const linkHandlers: { id: string; label: string }[] = []; const fileHandlers: { id: string; label: string }[] = []; for (const [id, profileContentHandler] of this.profileContentHandlers) { if (profileContentHandler.extensionId) { linkHandlers.push({ id, label: profileContentHandler.name }); } else { fileHandlers.push({ id, label: profileContentHandler.name }); } } </del> const options: QuickPickItem[] = []; <del> if (linkHandlers.length) { options.push({ label: localize('link', "link"), type: 'separator' }); options.push(...linkHandlers); } if (fileHandlers.length) { options.push({ label: localize('file', "file"), type: 'separator' }); options.push(...fileHandlers); </del> <ins> for (const [id, profileContentHandler] of this.profileContentHandlers) { options.push({ id, label: profileContentHandler.name, description: profileContentHandler.description }); </ins> } <del> const result = await this.quickInputService.pick(options, </del> <ins> const result = await this.quickInputService.pick(options.reverse(), </ins> { title: localize('select profile content handler', "Export '{0}' profile as...", name), hideInput: true

Related discussion:
text: Testing In the export flow, there's the step to "Export as...". The options are "File" and "Github" <img width="615" alt="image" src="https://user-"I can make the educated guess that I'm not exporting the whole of Github from my VS Code window, but it'd be better to say "Github Gist" instead, or "Export to" instead of "Export as". I prefer the former since it's clear where it's going--otherwise people might assume it creates a repo on their account or something.
It was GitHub Gist before, after feedback I changed to GitHub. I will bring this to UX and see what other think too.
Good feedback. We will also do a user study next week so we will see how users react here. Alternative rendering: "GitHub" and then "gist" as the description a bit to the right - QuickPick should support this.
There was some confusion in the user study when exporting as GitHub. They were expecting that it will be part of a repository. So calling it GitHub Gist might be the way to go.
I think adding as description would be good
!
Lovely, tried it out. Verified.
Code change:
if (!document.equalLines(lines)) { return this._proxy.$onVirtualDocumentChange(uri, value); } <ins> }) .catch(onUnexpectedError) .finally(() => { if (lastEvent === thisEvent) { lastEvent = undefined; } }); </ins> <del> }, onUnexpectedError); } </del> <ins> lastEvent = thisEvent; </ins> }); } return new Disposable(() => {

Related discussion:
text: Does this issue occur when all extensions are disabled?: Yes VS Code Version: 1.77.2 OS Version: Windows 10 It seems that when refreshing () the in a short period, the second refresh is not actually performed. I have provided an example repo and a video demonstrating the issue. Basically we have a that shadows the active editor so whenever a user changes the active editor we update the read only document. However, if the user changes the editors quickly enough then the second change is dropped... Steps to Reproduce: the extension the command "Open Read Only Document" tabs quickly and see how it falls behind even though the content is up to date https://user- The content is actually set but it seems the second is dropped. Because if you refresh the document manually it shows the correct content (see the video above). The issue seems to happen more frequently if the content of the file(s) is large.
I found out why it happens and attempted a fix (with explanation) in
Pinging so it does not get lost
Code change:
﻿{ <del> "configuration.validate.enable": "Whether php validation is enabled or not.", "configuration.validate.executablePath": "Points to the php executable.", </del> <ins> "configuration.builtInCompletions.enable": "Enable/disable built-in PHP completions.", "configuration.validate.enable": "Enable/disable built-in PHP validation.", "configuration.validate.executablePath": "Points to the PHP executable.", </ins> "configuration.validate.run": "Whether the linter is run on save or on type.", "configuration.title": "PHP" }  No newline at end of file

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:
﻿{ <del> "configuration.validate.enable": "Whether php validation is enabled or not.", "configuration.validate.executablePath": "Points to the php executable.", </del> <ins> "configuration.builtInCompletions.enable": "Enable/disable built-in PHP completions.", "configuration.validate.enable": "Enable/disable built-in PHP validation.", "configuration.validate.executablePath": "Points to the PHP executable.", </ins> "configuration.validate.run": "Whether the linter is run on save or on type.", "configuration.title": "PHP" }  No newline at end of file

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:
const line = getVisibleLine(event.textEditor); if (typeof line === 'number') { this.updateLine(event.textEditor.document.uri, line); <del> this.setPreviousEditorLine({ uri: event.textEditor.document.uri, line: line }); </del> <ins> this.setPreviousTextEditorLine({ uri: event.textEditor.document.uri, line: line }); </ins> } } }));

Related discussion:
text: Issue Type: <bBug</bI have been using for a long time. Currently I end up with a LOT of inadvertant selections when working in two side-by-side editor groups and switching back and forth between them using the mouse. The reason is that the editor scrolls 5 lines every time I click into it. VS Code version: Code - Insiders 1.58.0-insider (, 2021-06-11T05:22:19.992Z) OS version: Darwin arm64 20.5.0 Restricted Mode: No Remote OS version: Linux x64 5.4.0-1046-azure <!-- generated by issue reporter --
I cannot reproduce. Does this reproduce for you when disabling all extensions? (The editor exposes a API to extensions). I have recently also got which seems incredibly similar, but I am having a hard time reproducing any of the jumping that is described. Here I am trying two side-by-side editor groups: https://user-
This reproduces only when the language mode of the files are set to markdown. I think this has to do with how the markdown extension is using the vscode API. But I think it should not use that API at all if no markdown preview is rendered. But it would also be interesting to test what the experience is when the preview is rendered. Given this doesn't reproduce with txt files, I'm optimistically giving this to you. Steps to reproduce: define open two md files side-by-side (preferably without word wrapping to see the top line number change) click on the editor tab of each one on every click, the editor scrolls up by 5 lines https://user-
Could you please take a look at this since you were looking into markdown syncing last iteration?
It seems like it's a bug coming from the scroll syncing between the static and text editor changes that I made a while ago. I'll try to make a PR to fix this soon.