jiebi/CodeConvo huggingface dataset:
Code change:
return undefined; } let targetPlatform = this.extension.gallery.properties.targetPlatform; <del> if (this.extensionManagementServerService.remoteExtensionManagementServer) { </del> <ins> if (targetPlatform !== TargetPlatform.UNIVERSAL && targetPlatform !== TargetPlatform.UNDEFINED && this.extensionManagementServerService.remoteExtensionManagementServer) { </ins> try { const manifest = await this.galleryService.getManifest(this.extension.gallery, CancellationToken.None); if (manifest && this.extensionManifestPropertiesService.prefersExecuteOnWorkspace(manifest)) {

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?: It requires at least the remote SSH extension to be enabled due to the nature of the bug, all other extensions can be disabled/uninstalled. <!-- 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.75.0 OS Version: Local Windows 10 21H2 / Remote Fedora 29 Steps to Reproduce: -up VS Code with Remote SSH Python Extension in to Remote SSH error message and get asked to download manually opens link: the following error text: it's because the extension hasn't been published for 2023.2.0 for Linux yet so try installing older version same error and browser instead opens this link: very similar error text: I have had to revert to 1.74.3 where I am not getting this error so can I continue to work, but if you need me to test things again I can install 1.75.0 again and retest.
I am having the same issue since upgrading to VSCode 1.75.0. When trying to update the Python extension on the remote server I get an with the log Trying to download manually brings me to the as reported above. I am getting the same errors for the Jupyter extension. I could successfully update the extensions locally. VSCode: 1.75.0 OS: local openSUSE Tumbleweed / remote Red Hat Enterprise Linux 8.5 (Ootpa)
I have the same problem.
Same issue. Downgraded VSCode to 1.74.3 to restore functionality.
Code change:
return undefined; } let targetPlatform = this.extension.gallery.properties.targetPlatform; <del> if (this.extensionManagementServerService.remoteExtensionManagementServer) { </del> <ins> if (targetPlatform !== TargetPlatform.UNIVERSAL && targetPlatform !== TargetPlatform.UNDEFINED && this.extensionManagementServerService.remoteExtensionManagementServer) { </ins> try { const manifest = await this.galleryService.getManifest(this.extension.gallery, CancellationToken.None); if (manifest && this.extensionManifestPropertiesService.prefersExecuteOnWorkspace(manifest)) {

Related discussion:
text: VS Code Version: 1.75.0 OS Version: Local: macOS Monterey 12.6.3 Remote: Amazon Linux 2 w/ Kernel 5.4
Triaging this issue I am unsure if the initial post with the error message of is the same as the error with the message . Therefore all conversation on the issue should be moved to this other issue: Thanks
This issue is related to target platform and not related to sign verification.
Yes, I am initial poster, I also get the signature untrusted error. I assumed the two errors had the same underlying cause, i.e. when VS Code made the web request it got the above error which does not have the signature of the extension and therefore throws a red herring of "Untrusted: Signature", then when VS Code prompts you to download it manually you can see the actual underlying error. This is why I posted the latter error and not the former error. But if you are convinced they are two separate errors then it makes sense to track them separately. But be aware I got both errors, and everyone else who has posted seems to have also got both errors.
Thanks for the info It seems that the root cause is signature error for you too. Being said that the manual download shall work. Can you please share the link you are using to download the VSIX?
From the marketplace web page. Version History -2023.3. -Download Manual download and install work for me.
As per my original post the link that VS Code to manually download the extension is: Which gives this error:
It seems VS Code is generating an invalid download link. Updating this issue for fixing the update link. For signing related, please refer to
I'm not sure how to get this, are there repro steps?
To verify Open extensions view Browse for eslint extension (any non platform specific extension) Disable network connection Click on install, you shall see a prompt to Download Manually Enable network connection and click on that Download Manually button Make sure the VSIX is downloaded/
Code change:
// Diff navigator this.diffNavigator = new DiffNavigator(control, { <del> alwaysRevealFirst: !optionsGotApplied && !hasPreviousViewState // only reveal first change if we had no options or viewstate </del> <ins> alwaysRevealFirst: !optionsGotApplied && !hasPreviousViewState, // only reveal first change if we had no options or viewstate findResultLoop: this.getMainControl()?.getOption(EditorOption.find).loop </ins> }); this.diffNavigatorDisposables.add(this.diffNavigator);

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. --Setting to stop at the bottom (or top) when navigating in the diff view through the changes with "next change" and reaching the last change. Like did in
Can I provide a PR for this feature
Go ahead.
Thanks a lot for implementing this. But what is the setting to enable this?
Looks like this behavior got to the "" setting
No, does not affect this unfortunately.
Code change:
export interface IFileCellEdit { readonly _type: FileEditType.Cell; readonly uri: URI; <del> readonly edit?: ICellPartialMetadataEdit | IDocumentMetadataEdit; </del> <ins> readonly edit?: ICellMetadataEdit | IDocumentMetadataEdit; </ins> readonly notebookMetadata?: Record<string, any>; readonly metadata?: vscode.WorkspaceEditEntryMetadata; }

Related discussion:
text: When updating cell metadata for a cell, users call which provides a function to alter the metadata of a cell. This uses defined in . When is called, the CellEditType is marked as , resulting in the metadata of the cell only being updated with the passed in data, rather than fully replaced. This makes it difficult to determine how to remove fields from a cell's metadata, a change needed for fixing . This can be worked around in this situation by setting the field to null. However, if a user calls , it appears that the functionality is a full replacement of initial metadata. There is a slight inconsistency here between the functionality of the two functions. Couple initial ideas: better document to reflect the behavior of . Add in a line stating that this is an iterative change, only altering the fields passed into this function - revise the functionality of either updateCell or updateNotebook metadata functions to align their behavior. This seems dangerous as it could likely break features leveraging this api. deprecate these functions, and rewrite two new ones with clearer functionality and documentation, based on updated needs from the notebook and jupyter teams
Analyzed all extensions using this API and most of them are already doing the right thing: clone the existing metadata, apply the change, and then call the API to update. However there are a few extensions didn't do so: there is one place where the metadata is not updated properly: PR . cc
<!-- 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!
what is the best way to verify this?
It's a bit complex I would love either or to help verify.
Code change:
workspacesToOpen: IWorkspacePathToOpen[], foldersToOpen: ISingleFolderWorkspacePathToOpen[], emptyToRestore: IEmptyWindowBackupInfo[], <del> emptyToOpen: number, </del> <ins> openOneEmptyWindow: boolean, </ins> filesToOpen: IFilesToOpen | undefined, foldersToAdd: ISingleFolderWorkspacePathToOpen[] ): Promise<{ windows: ICodeWindow[]; filesOpenedInWindow: ICodeWindow | undefined }> {

Related discussion:
text: Steps to Reproduce: to 1 window on a folder open the command line run = only the folder opens, but not an empty window I would expect here 2 windows to open, one is the folder and one the empty window since no argument was given to open any folder or file.
Code change:
@INativeHostService private readonly nativeHostService: INativeHostService ) { super(ReportExtensionIssueAction._id, ReportExtensionIssueAction._label, 'extension-action report-issue'); <del> this.enabled = !!extension.description.repository && !!extension.description.repository.url; </del> <ins> this.enabled = extension.description.isBuiltin || (!!extension.description.repository && !!extension.description.repository.url); </ins> } async run(): Promise<void> {

Related discussion:
text: Running Extensions context menu -in extensions have disabled menu for !
I don't remember creating the "Report Issue" action, so I don't think I own it. Maybe you did this?
Yeah I did this. Code pointer The issue here is that the JavaScript Debugger does not seem to provide the repository URI in the Thus the action gets disabled here can you maybe provide the repository information of the JavaScript debugger so this button gets enabled here?
There are multiple built-in extensions with disabled menu item, like, , , ... (Not only js debugger).
Yeah none of them have a seperate repository. So you shuold just file in vscode repository However for js-debug we have a sepearte repository so it makes sense to have that action enabled.
I have an repository in the js-debug I think the issue is actually the line above that exclude built-in extensions: I don't think this line is necessary. Deleting it will just have people who open issues on extensions in the vscode repo open them here, which is desirable.
Yeah, agree.
Report Issue on opens this repository . Some other built-in extensions still have disabled menu item.
This action is available only for few builtin extensions (jsdebug, emmet) and this action reports issues in VS Code repository. IMO it shall be consistent and show this action for all builtin extensions. If repo is not found and extension is builtin we shall enable the action and create issue in VS Code repo. Let me know if you agree, if so shall I reopen this issue?
Works for me and let's reopen. I am opening this for community contributions and adding help wanted
I think there are two ways to do it. attributes need to be to the of each built-in extension In the , judge the extension type. If it is a built-in extension, set the base url to I think 2 is better
Yeah let's go with 2. Sounds like a good approach to me
I have submitted a PR, please help CR
thanks to your PR this is now fixed.
Fixed for built-in extensions, though just a note that it's still disabled for the github.codespaces extension.
Code change:
description: nls.localize('peekWidgetDefaultFocus', "Controls whether to focus the inline editor or the tree in the peek widget.") } )), <ins> definitionLinkOpensInPeek: register(new EditorBooleanOption( EditorOption.definitionLinkOpensInPeek, 'definitionLinkOpensInPeek', false, { description: nls.localize('definitionLinkOpensInPeek', "Controls whether the definition link opens element in the peek widget.") } )), </ins> quickSuggestions: register(new EditorQuickSuggestions()), quickSuggestionsDelay: register(new EditorIntOption( EditorOption.quickSuggestionsDelay, 'quickSuggestionsDelay',

Related discussion:
text: <!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --When we use to jump to definition, would open the definition in a new window, which is inconvenient for me. It would be better if we can choose where to open definition, like in . !
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.492 --- <!-- score: 0.467 --<!-- potentialduplicatescomment --
Nice suggestion. If you agree with this, I'll create a setting so one can choose if 'ctrl+click' always opens the peek view.
Normally, ctrl+click runs and cmd+ctrl+click opens . With this setting enabled, they both run . I don't think that's expected. Possibly change to ?
you can reopen verification-found issues
Uhm, I'll take a look on that. Thanks for your feedback!
Please file a bug and don't reopen feature requests
I created
Code change:
staleBackupWorkspaces.forEach(staleBackupWorkspace => { const {backupPath, workspaceIdentifier, isEmptyWorkspace} = staleBackupWorkspace; <del> extfs.delSync(backupPath); </del> <ins> try { extfs.delSync(backupPath); } catch (ex) { console.error(`Backup: Could not delete stale backup: ${ex.toString()}`); } </ins> this.removeBackupPathSync(workspaceIdentifier, isEmptyWorkspace); }); }

Related discussion:
text: Moving this over from After the backups are not restored if the workspace directory doesn't exist anymore. The workspace is no longer tracked but the backups are kept around in the backup directory should they be needed later.
Tricky.... I would expect an empty window to open with those files dirty. This might require some work on the area of restoring on empty workspaces. Have not thought about this longer yet.
Marking as important because this means data loss if the folder is deleted on disk.
maybe this should be done on the main side on startup similarly to If a folder no longer exists, convert it into an empty workspace backup and let it open as empty window.
On test plan:
Code change:
export const IS_WORKSPACE_SHELL_ALLOWED_STORAGE_KEY = 'terminal.integrated.isWorkspaceShellAllowed'; export const NEVER_SUGGEST_SELECT_WINDOWS_SHELL_STORAGE_KEY = 'terminal.integrated.neverSuggestSelectWindowsShell'; <ins> export const NEVER_MEASURE_RENDER_TIME_STORAGE_KEY = 'terminal.integrated.neverMeasureRenderTime'; </ins> export const ITerminalService = createDecorator<ITerminalService>(TERMINAL_SERVICE_ID);

Related discussion:
text: Upstream:
It's not true that it takes very long. It does not get visible at all. I have to downsize the terminal pane to a certain size to make it visible again. In my case it's about 5-10 lines. Seems to me that the canvas is not resized properly. There are no problems if I disable GPU rendering (code --disable-gpu). Also without any noticeable performance issues. Would be nice to have a flag in the preferences to disable GPU rendering as a quick workaround. One of the reasons for using code (instead of Atom or Sublime) was the integrated terminal which seems to be broken since the new canvas rendering was introduced. My System Config: OS X 10.11.6, GPU: NVidia 8800, 4GB RAM
that will probably get fixed as part of this as well, it's probably something to do with your GPU/Chromium not liking the texture sizes above a certain size.
Code change:
return data; } else { const result = new _URI(data); <del> result._fsPath = (<UriState>data).fsPath; </del> result._formatted = (<UriState>data).external; <ins> result._fsPath = (<UriState>data)._sep === _pathSepMarker ? (<UriState>data).fsPath : null; </ins> return result; } }

Related discussion:
text: The cache is preserved throughout URI serialization. We should invalidate it when the URI crosses platform boundaries. Related to
Code change:
$('div').append($('a').attr('target', '_blank').attr('href', this.requestFeatureLink).text(nls.localize("request a missing feature", "Request a missing feature")).attr('tabindex', '0')) .appendTo($contactUsContainer); <del> let $charCounter = $('span.char-counter').text('(' + FeedbackDropdown.MAX_FEEDBACK_CHARS + ' ' + nls.localize("characters left", "characters left") + ')'); </del> <ins> let $charCounter = $('span.char-counter').text(this.getCharCountText(0)); </ins> $('h3').text(nls.localize("tell us why?", "Tell us why?")) .append($charCounter)

Related discussion:
text: To reproduce. click smiley in the bottom right of editor window. The feedback form should appear enter several characters, press "Enter" (the new line should appear) continue entering characters while you can You should stop at "1 characters left" (declensions?) After that you will not be able to enter anything On the screenshot. There's a newline after "1". I reached the end of input and unable to enter more characters. But counter still says "1 characters left": <img width="468" alt="" src=""Mac OS 10.10.5 Yosemite
This is interesting. I created this to reproduce the behavior. do you have any thoughts on this? Here are a couple ideas we've talked about before. 1 - Remove the text area completely and replace with just the tweet button. This makes sense because we're submitting to twitter anyways. 2 - Hack the text area element to get better behavior. This would involve looking for new line characters based on the batter described by OP. I'm not a fan of this as it seems error prone. If we go with option 1, I'll work with Brad and get some design love on the form. any thoughts? I created PR to fix the "s" on singular count issue.
Thanks for your amazing job and thanks for asking! :blush: If the "Tweet" button will not require having a Twitter account, then it's a solution, I guess. I feel a bit weird reporting those super-tiny issues that still require developers time. Is the related (then we should star it)? Probably even disabling line breaks (like turning into line input) could be a solution.
Yes that is the exact issue. Starred it! I thought about disabling line breaks, but I think it would be a good thing for the user to do, considering Twitter supports line breaks. The Tweet button wouldn't require a Twitter account, but once the Tweet button takes them to twitter they would need to login.
Well, the need to login on Twitter is a requirement to have a Twitter account :blush: I wouldn't think it's a good UX :relaxed:
Right. Unfortunately Twitter doesn't support anonymous tweets.
After some internal discussion we decided to go with a dialog redesign. Will work with our UX designer to get some help.
Closing as it will be fixed with .
Code change:
import { MutableDisposable } from 'vs/base/common/lifecycle'; import { IPaneCompositePartService } from 'vs/workbench/services/panecomposite/browser/panecomposite'; import { ViewContainerLocation } from 'vs/workbench/common/views'; <ins> import { IConfigurationService } from 'vs/platform/configuration/common/configuration'; </ins> /** * An implementation of editor for file system resources.

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:
this._cursorBlinking = options.get(EditorOption.cursorBlinking); this._cursorStyle = options.get(EditorOption.cursorStyle); this._cursorSmoothCaretAnimation = options.get(EditorOption.cursorSmoothCaretAnimation); <ins> this._experimentalEditContextEnabled = options.get(EditorOption.experimentalEditContextEnabled); </ins> this._updateBlinking(); this._updateDomClassName();

Related discussion:
text: Version: 1.94.0-insider Commit: Date: 2024-09-20T05:03:57.400Z Electron: 30.5.0 ElectronBuildId: Chromium: 124.0.6367.243 20.16.0 V8: 12.4.254.20-electron.0 OS: Darwin arm64 22.6.0 Steps to Reproduce: Set Google IME for Japanese. The cursor is not visible during typing. On almost all the platforms and all the applications, the cursor is usually visible during composition.
Hi yes thank you for opening this issue. This is caused by some code that is related to the current edit context implementation which hides the blinking cursor because there is already a blinking cursor in the visible text area shown during composition. A PR has been made to fix this.
Code change:
if (completion.snippetInfo || completion.filterText !== completion.insertText) { // not in WYSIWYG mode, partial commit might change completion, thus it is not supported <del> this.accept(editor); </del> <ins> await this.accept(editor); </ins> return; }

Related discussion:
text: One desired behavior of writing a custom is that when the user accepts a given suggestion, the provider is immediately triggered again for another suggestion. We need to track when users accept (or reject) suggestions so that we can measure improvements that we make. Without using the experimental API, the best way to track if a completion is accepted is to provide a value for the field in . When supplying a command, the retriggering behavior is disabled [1]. As a workaround, I tried to indirectly trigger an inline completion via the command , however, it does not work (not sure why, this does work with my unit tests but not when I try to call it from a command I supply via ). [1] I believe this is the code block that retriggers automatically, one can see that the retrigger only happens if the command is the default command:
Note is related.
Note that [1] points to the autocomplete source code, not the inline suggestion feature. I'm not aware of any disablements.
Ok, that's incorrect -- however, adding a 'command' to disables the automatic retrigger.
Place the cursor after and press enter. Then accept. Notice that is not suggested.
That monaco repro / editor is really cool
Thanks! The best thing is that you can use the "Monaco Editor Playground" launch config in the VS Code repo to debug the playground example :)
<!-- 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!