jiebi/CodeConvo huggingface dataset:
Code change:
const NotebookPreloadContribution = Object.freeze({ type: 'type', entrypoint: 'entrypoint', <ins> localResourceRoots: 'localResourceRoots', </ins> }); interface INotebookPreloadContribution { readonly [NotebookPreloadContribution.type]: string; readonly [NotebookPreloadContribution.entrypoint]: string; <ins> readonly [NotebookPreloadContribution.localResourceRoots]: readonly string[]; </ins> } const notebookProviderContribution: IJSONSchema = {

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:
}); } run(accessor: ServicesAccessor, ...args: unknown[]): void { <del> accessor.get(IAccessibleViewService).next(); </del> <ins> accessor.get(IAccessibleViewService).previous(); </ins> } } <ins> registerAction2(AccessibleViewPreviousAction); </ins> function registerCommand<T extends Command>(command: T): T { command.register();

Related discussion:
text: One way of resolving this would be repeating the position information when I press any of the commands, even if there is no change. Another possibility would be to prevent the widget from refocusing when I am in the first / last element, and I try to move beyond that element. In that way pressing the next command will not produce any feedback if I am in the last one, and the previous will not produce any feedback if I am in the first one. Does it make sense? In any case, this would be a refinement, not something that would prevent someone from using the feature. Originally posted by in
Something else to consider when fine tuning the responses. Right now, position information is announced using an alert in macOS, and a status message in Windows. This is a situation where it makes sense to use an alert in all platforms so that screen readers prioritize this over other events. For example, right now JAWS is announcing position information after reannouncing the widget.
Huh, I'm using for all platforms here which appears to be platform agnostic I think it might just be a JAWS issue - does this repro when using NVDA?
It doesn't, but NVDA handles aria-live differently. You may be right dough. I'll debug NVDA on Monday and we'll know for sure which event it is seeing. JAWS may be simply prioritizing the focus event.
Friendly ping! Looks like this issue requires some further steps to be verified. Please provide us with the steps necessary to verify this issue.
Focus an accessible view for which there are several elements (like chat responses or notifications). Verify that if you are on the first or last element, pressing next or previous does not result in repeated alerts. it should not notify the screen reader user as nothing has changed.
Note to verifier there's an issue to disable these actions when they cannot be taken, which is the better fix.
Verified. With NVDA, if I press enter on the Next button while on the last chat response, the focus goes back to the response text instead of staying on the button, though that might be by design.
Code change:
}); }); <ins> test('openTextDocument, with selection', function () { return createRandomFile('foonbarnbar').then(file => { return vscode.workspace.openTextDocument(file).then(doc => { return vscode.window.showTextDocument(doc, { selection: new vscode.Range(new vscode.Position(1, 1), new vscode.Position(1, 2)) }).then(editor => { assert.equal(editor.selection.start.line, 1); assert.equal(editor.selection.start.character, 1); assert.equal(editor.selection.end.line, 1); assert.equal(editor.selection.end.character, 2); }); }); }); }); </ins> test('registerTextDocumentContentProvider, simple', function () { let registration = vscode.workspace.registerTextDocumentContentProvider('foo', {

Related discussion:
text: For
Verify: write an extension that exercises the following APIs by passing in a selection as option and verify the selection is revealed and showing up in the opened editor: command API Provide a property of type to get it. !
Code change:
this.searchResultModel?.updateChildren(); if (this.settingsTreeModel) { <del> this.settingsTreeModel.update(resolvedSettingsRoot); </del> <ins> this.refreshModels(resolvedSettingsRoot); </ins> if (schemaChange && !!this.searchResultModel) { // If an extension's settings were just loaded and a search is active, retrigger the search so it shows up

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?: Unknown- repro uses a virtual workspace <!-- 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: OS Version: Version: 1.80.0 Commit: Date: 2023-07-04T15:06:02.407Z Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Code/1.80.0 Chrome/108.0.5359.215 Electron/22.3.14 Safari/537.36 Steps to Reproduce: a Github repository using "GitHub Repositories" extension, eg microsoft/vscode "Settings (JSON)" and add all tabs except Getting Started Extensions panel, search for " typescript" the Typescript and JavaScript Language Features extension and Reload Window "Settings (UI)" and search for typescript- no settings appear. Close "Settings (UI)" Extensions panel, search for " typescript" and re-enable the extension. Note, the extension activates immediately, the panel doesn't recommend Reload Window. "Settings (UI)" and search for typescript- Actual: no settings appear. Expected: settings appear
Code change:
__vsc_prompt_cmd_original() { __vsc_status="$?" <del> if [[ ${IFS+set} ]]; then __vsc_original_ifs="$IFS" fi if [[ "$__vsc_original_prompt_command" =~ .+;.+ ]]; then IFS=';' </del> <ins> # Evaluate the original PROMPT_COMMAND similarly to how bash would normally # See https://unix.stackexchange.com/a/672843 for technique if [[ ${#__vsc_original_prompt_command[@]} -gt 1 ]]; then for cmd in "${__vsc_original_prompt_command[@]}"; do __vsc_status="$?" eval "${cmd:-}" done </ins> else <del> IFS=' ' </del> <ins> eval "${__vsc_original_prompt_command:-}" </ins> fi <del> builtin read -ra ADDR <<<"$__vsc_original_prompt_command" if [[ ${__vsc_original_ifs+set} ]]; then IFS="$__vsc_original_ifs" unset __vsc_original_ifs else unset IFS fi for ((i = 0; i < ${#ADDR[@]}; i++)); do (exit ${__vsc_status}) builtin eval ${ADDR[i]} done </del> __vsc_precmd }

Related discussion:
text: Issue Type: <bBug</bSet the variable to something like this: You should see something similar to the following: I'm assuming it's associated with . If I'm reading correctly, it checks for semicolons but not things like , , , etc. I understand this is probably an edge case. I was able to workaround by: creating a new function to wrap the others set to the new function VS Code version: Code 1.69.0 (, 2022-07-07T05:28:46.408Z) OS version: Darwin arm64 21.5.0 Restricted Mode: No <!-- generated by issue reporter --
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.69.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
I can confirm this bug still exists in 1.69.1, and is probably less of an edge case than you might think , as I found this issue when the terminal wouldn't start because I had powerline installed.
O
My bash (GNU bash, version 5.1.16(1)-release (x86_64-apple-darwin21.1.0)) didn't want to work with empty functions, this reproduces the problem though:
Code change:
__vsc_prompt_cmd_original() { __vsc_status="$?" <del> if [[ ${IFS+set} ]]; then __vsc_original_ifs="$IFS" fi if [[ "$__vsc_original_prompt_command" =~ .+;.+ ]]; then IFS=';' </del> <ins> # Evaluate the original PROMPT_COMMAND similarly to how bash would normally # See https://unix.stackexchange.com/a/672843 for technique if [[ ${#__vsc_original_prompt_command[@]} -gt 1 ]]; then for cmd in "${__vsc_original_prompt_command[@]}"; do __vsc_status="$?" eval "${cmd:-}" done </ins> else <del> IFS=' ' </del> <ins> eval "${__vsc_original_prompt_command:-}" </ins> fi <del> builtin read -ra ADDR <<<"$__vsc_original_prompt_command" if [[ ${__vsc_original_ifs+set} ]]; then IFS="$__vsc_original_ifs" unset __vsc_original_ifs else unset IFS fi for ((i = 0; i < ${#ADDR[@]}; i++)); do (exit ${__vsc_status}) builtin eval ${ADDR[i]} done </del> __vsc_precmd }

Related discussion:
text: Issue Type: <bBug</bwhen i enable shell integration, i get an error: my contains: VS Code version: Code - Insiders 1.66.0-insider (, 2022-03-28T07:49:37.594Z) OS version: WindowsNT x64 10.0. Restricted Mode: No Remote OS version: Linux x64 5.10.60.1-microsoft-standard-WSL2 <details<summarySystem Info</summary </details<details<summaryExtensions (11)</summaryExtensionVersion ------ better-cpp-syntax1.15.13 remote-containers0.230.0 remote-ssh0.77. remote-ssh-edit0.77. remote-wsl0.66.0 doxdocgen1.4.0 better-cpp-syntax1.15.13 cmake-tools1.10.5 cpptools1.9.7 cpptools-extension-pack1.1.0 cmake0.0.17 (2 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
looks like you set somewhere which re-writes your . Right now if we detect possible problems with unsupported formats we bail out and disable shell integration by design. To workaround this you could point your at a function and run inside the function instead, for example
Assigning to April to see if we can improve our handling here.
no. i'm not setting . ugh. testing this is a nightmare. vscode seems to keep some persistent state on the server affecting shell startup. anyway, i'd recommend testing with my exact client/server OS combo. is set by the OS to the value above, but weirdly that's not actually what's used to echo my prompt. my prompt, as set in my file is .
It might be set in your or ? VS Code sources a shell environment on startup and that gets used as the base environment for terminals. For WSL you'd need the vscode server to shutdown fully.
no, this also happens when connecting (via ssh) to a fresh CentOS7 install.
Code change:
__vsc_prompt_cmd_original() { __vsc_status="$?" <del> if [[ ${IFS+set} ]]; then __vsc_original_ifs="$IFS" fi if [[ "$__vsc_original_prompt_command" =~ .+;.+ ]]; then IFS=';' </del> <ins> # Evaluate the original PROMPT_COMMAND similarly to how bash would normally # See https://unix.stackexchange.com/a/672843 for technique if [[ ${#__vsc_original_prompt_command[@]} -gt 1 ]]; then for cmd in "${__vsc_original_prompt_command[@]}"; do __vsc_status="$?" eval "${cmd:-}" done </ins> else <del> IFS=' ' </del> <ins> eval "${__vsc_original_prompt_command:-}" </ins> fi <del> builtin read -ra ADDR <<<"$__vsc_original_prompt_command" if [[ ${__vsc_original_ifs+set} ]]; then IFS="$__vsc_original_ifs" unset __vsc_original_ifs else unset IFS fi for ((i = 0; i < ${#ADDR[@]}; i++)); do (exit ${__vsc_status}) builtin eval ${ADDR[i]} done </del> __vsc_precmd }

Related discussion:
text: <img width="965" alt="image" src="https://user-"
<img width="888" alt="Screen Shot 2022-03-31 at 17 04 04" src="https://user-"
It seems that works right on Manjaro X86_64 <img width="822" alt="image" src="https://user-"
Same here, with Arch and default As workaround I blanked the $PROMPT_COMMAND on my
Thanks for finding the , should make it easy to test against
the shell integration feature also breaks long line-wrapping in bash (happens on Ubuntu, too). the terminal wraps the line before reaching the right edge of the terminal window, and it wraps to the same line overwriting the existing ontents of that line. scrolling through line commands in the bash command history is completely broken.
Tentatively assigning to July as this gets hit with Arch's default
Code change:
import { ContextSubMenu } from 'vs/base/browser/contextmenu'; import { memoize } from 'vs/base/common/decorators'; import { IDialogService } from 'vs/platform/dialogs/common/dialogs'; <ins> import { getHover } from 'vs/editor/contrib/hover/getHover'; </ins> const HOVER_DELAY = 300; const LAUNCH_JSON_REGEX = /launch.json$/;

Related discussion:
text: To be verified with: : : set the new config options start debugging The hover provider should be invoked.
Code change:
if (isWeb()) { // On web, treat absolute paths as pointing to standard lib files if (filepath.startsWith('/')) { <del> return vscode.Uri.joinPath(this.context.extensionUri, 'node_modules', 'typescript', 'lib', filepath.slice(1)); </del> <ins> return vscode.Uri.joinPath(this.context.extensionUri, 'dist', 'browser', 'typescript', filepath.slice(1)); </ins> } }

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.56.2 OS Version: MacOS Catalina 10.15.6 Steps to Reproduce: VSCode Version any typescript file (for example in ) /Ctrl + Click on any native dom method, for example , there should be a error message popups ! I thinks this is caused by the wrong type definition file path in below code:
Code change:
// use the evil-edit as these models show in readonly-editor only model.applyEdits(edits.map(edit => EditOperation.replace(Range.lift(edit.range), edit.text))); } <del> }).catch(onUnexpectedError); </del> <ins> } catch (error) { onUnexpectedError(error); } </ins> } }

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:
throw new ExtensionManagementError(localize('notFoundCompatibleDependency', "Can't install '{0}' extension because it is not compatible with the current version of {1} (version {2}).", extension.identifier.id, this.productService.nameLong, this.productService.version), ExtensionManagementErrorCode.Incompatible); } <del> return compatible; </del> <ins> return compatibleExtension; </ins> } private async installUIDependenciesAndPackedExtensions(local: ILocalExtension): Promise<void> {

Related discussion:
text: VSCode Version: Version: 1.67.0-insider (Universal) Commit: Date: 2022-04-06T05:15:27.397Z (8 hrs ago) Local OS Version: macOs 12.3.1 / arm Remote OS Version: Centos 7 Remote Extension/Connection Type: SSH Logs: Steps to Reproduce: SSH Session the popup, hey Python and Jupyter extensions have pre-release versions or install / switch to pre-release on the extension page Error (but the extensions shows the pre-release state), but afaik that's not the case Note: I removed the vs code server on the remote host and did a new installation (starting from locally with the remote extensions versions), but it actually just installs the stable version on the remote and then the switch is not possible. It should actually consider and install the same version that is used locally, shouldn't it? Can't install pre-release version of 'ms-toolsai.jupyter' extension because it is not compatible with the current version of Visual Studio Code - Insiders (version 1.67.0-insider). Does this issue occur when you try this locally?: No Does this issue occur when you try this locally and all extensions are disabled?:No logs: [2022-04-06 15:51:45.599] [renderer1] [info] Downloading the 'ms-toolsai.jupyter' extension locally and install [2022-04-06 15:51:45.626] [renderer1] [error] Can't install pre-release version of 'ms-toolsai.jupyter' extension because it is not compatible with the current version of Visual Studio Code - Insiders (version 1.67.0-insider).: IncompatiblePreRelease: Can't install pre-release version of 'ms-toolsai.jupyter' extension because it is not compatible with the current version of Visual Studio Code - Insiders (version 1.67.0-insider).
Code change:
throw new ExtensionManagementError(localize('notFoundCompatibleDependency', "Can't install '{0}' extension because it is not compatible with the current version of {1} (version {2}).", extension.identifier.id, this.productService.nameLong, this.productService.version), ExtensionManagementErrorCode.Incompatible); } <del> return compatible; </del> <ins> return compatibleExtension; </ins> } private async installUIDependenciesAndPackedExtensions(local: ILocalExtension): Promise<void> {

Related discussion:
text: at l.checkAndGetCompatible (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-) at async l.downloadAndInstall (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-) at async l.installFromGallery (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-) at async (index 0) at async Object.j [as settled] (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-) at async Ms.installFromGallery (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-)
Would you mind sharing your Remote SSH logs as well? And if you have any gifs or videos of what you're seeing?
! ! And this - but it's just a "refresh" problem, once I switch between extensions it shows the old and unfortunately correct version again: ! And logs...
Your SSH connection looks successful. I'll transfer this issue to the Python extension team to see if they have ideas why this state is happening
This is an error thrown by VS Code, not sure what an extension can do about this as installing extensions is completely managed by VS Code. I'm transferring this back to VS Code.
Same issue happends to me.
I was able to install this manually (remote) by downloading the new extension that I got from this link: By this, you'll switch to the pre-release version. After installing it once manually, all updates work as usual.
Can you please try our latest insiders and see if you can reproduce this issue still?
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
Sorry, I had it already solved and thought it wouldn't occur again + I moved away from using Remote SSH whenever I could. I am now on the latest 1.68 insiders and for whatever reason the jupyter extension reverted to "non pre-release" and the same issue still exists - same error. Same workaround as above fixed the issue for me.
Were you using any remote set up when this happened again? Are you still able to repro it?
Yeah, it's exactly the same setup, just updated (yesterday's) insider build.
Code change:
throw new ExtensionManagementError(localize('notFoundCompatibleDependency', "Can't install '{0}' extension because it is not compatible with the current version of {1} (version {2}).", extension.identifier.id, this.productService.nameLong, this.productService.version), ExtensionManagementErrorCode.Incompatible); } <del> return compatible; </del> <ins> return compatibleExtension; </ins> } private async installUIDependenciesAndPackedExtensions(local: ILocalExtension): Promise<void> {

Related discussion:
text: And yes, if I uninstall the extension, install release, try to switch, the same happens over and over again. I discovered another bug: switch back to stable is not possible [2022-05-24 12:03:11.208] [remoteagent] [warning] Overwriting user extension with It always pushes me back to the pre-release. I think this may be related to keep local/remote on the same version/track. EDIT: Okay, actually this blocks everyone using insiders with the jupyter and/or other plugins in combination with remote ssh. Since insiders are updated daily, the "vs code server" is updated daily and the plugin is revert/installed again in the non preview version. So my hotfix has to applied daily which is really annoying. EDIT 2: I realised that the current (release today) stable "jupyter" version also has the latest insiders api implemented. So for now and for me that is solved - but the actual bug is still there, I can't switch to pre-release versions in a remote ssh setup.
Sorry that you are having this annoying issue and glad that you are able to reproduce it so that we can investigate. If you don't mind, can you please summarise your repro steps?
So, I now understand why it's a bit complex to reproduce this - I guess... I was even confused myself. So, currently the only way to reproduce it was for me: 1) deinstall the server (rm -rf .vscode-insiders-server) 2) connect/install + install jupyter extensions (local: pre-release) -pre-release installation successful 3) switch to release on remote 4) reload window -I am then on release try to switch to pre-release -issue appears. And now the important part: I realised that I still had the setting because within our company we had restrictions before... setting this to false also fixes the issue - even when it appeared before.
Thanks for the steps. I can reproduce it now and fixed. To verify: Open a remote window and set setting Install pre-release of ESLint extension Reload window Switch to release version of ESLint extension Reload window Switch to pre-release version of ESLint extension Make sure switch happens