jiebi/CodeConvo huggingface dataset:
Code change:
return; } <del> commands.executeCommand('git.clone', cloneUri.toString(true)); </del> <ins> commands.executeCommand('git.clone', cloneUri.toString(true), undefined, { ref: ref }); </ins> } dispose(): void {

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. --vscode- a directory to clone your repo into cloned repo :bug: branch context is not preserved This impacts Continue Working On--branch context is preserved for Clone in Container and Create New Codespace. I propose adding a new optional query parameter to the uri handler here: and passing that to the command as an optional argument here Then after cloning here: and before opening the repo in a new window, we would perform the ref checkout:
will you create a test plan item/verification steps for this feature?
yes I will!
Code change:
accessibilityProvider: this.widgetAccessibilityProvider, horizontalScrolling: false, identityProvider: this.widgetIdentityProvider, <del> multipleSelectionSupport: false, </del> <ins> multipleSelectionSupport: true, </ins> selectionNavigation: true }, );

Related discussion:
text: Testing Not sure if this lack of functionality blocks anything truly useful, but at least in the treeview, you can multi-select problems and copy them to the clipboard. In the table view you can't.
This also has the side effect of losing a multi-select that you may have had in the treeview.
what was the thinking for enabling multi-select in the problems treeview? Was there a particular scenario or this is what the default behaviour is for a treeview? If there is a real scenario, than we should enable multi-select in the table as well.
You can copy multiple problems is the primary use case.
that makes sense. Thanks!
Code change:
"dev": true }, "node_modules/electron": { <del> "version": "30.5.0", "resolved": "https://registry.npmjs.org/electron/-/electron-30.5.0.tgz", "integrity": "sha512-20c774PEsCFRzIgpZIaY6t/wTYxam0MfxQt5t+wG8aStHsl81FchUyLbDo4a59goqE7mHjLOdBDlxmZk88IgRw==", </del> <ins> "version": "30.5.1", "resolved": "https://registry.npmjs.org/electron/-/electron-30.5.1.tgz", "integrity": "sha512-AhL7+mZ8Lg14iaNfoYTkXQ2qee8mmsQyllKdqxlpv/zrKgfxz6jNVtcRRbQtLxtF8yzcImWdfTQROpYiPumdbw==", </ins> "dev": true, "hasInstallScript": true, "license": "MIT",

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:
"dev": true }, "node_modules/electron": { <del> "version": "30.5.0", "resolved": "https://registry.npmjs.org/electron/-/electron-30.5.0.tgz", "integrity": "sha512-20c774PEsCFRzIgpZIaY6t/wTYxam0MfxQt5t+wG8aStHsl81FchUyLbDo4a59goqE7mHjLOdBDlxmZk88IgRw==", </del> <ins> "version": "30.5.1", "resolved": "https://registry.npmjs.org/electron/-/electron-30.5.1.tgz", "integrity": "sha512-AhL7+mZ8Lg14iaNfoYTkXQ2qee8mmsQyllKdqxlpv/zrKgfxz6jNVtcRRbQtLxtF8yzcImWdfTQROpYiPumdbw==", </ins> "dev": true, "hasInstallScript": true, "license": "MIT",

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:
const scrollTop = outputScrolling ? findScrolledHeight(outputElement) : undefined; // If the previous output item for the same cell was also a stream, append this output to the previous <del> const existingContentParent = getPreviousMatchingContentGroup(outputElement); </del> <ins> const existingContentParent = getPreviousMatchingContentGroup(outputElement) || outputElement.querySelector('div'); </ins> if (existingContentParent) { const existing = existingContentParent.querySelector(`[output-item-id="${outputInfo.id}"]`) as HTMLElement | null; if (existing) {

Related discussion:
text: a notebook and run a cell that will continuously update over time to drag the scrollbar while output is still being written :bug: scrollbar is not held and returns to the bottom
Streaming output items are all compressed into a single item in (?), so we would need to stop doing that unless needed (for editing previous lines) Also, the current method only allows passing a single output item, but the output renderer will need to be able to render the entire output as it currently does, or just append the new data. Current: Proposed method that would only be used for streaming outputs and if the chosen renderer contains the method: Another alternative would be adding info to the OutputItem itself, containing only the appended string if appending should happen.
Code change:
// We have a preserved ID. So the task didn't change. if (tTask._id !== undefined) { // Always get the task execution first to prevent timing issues when retrieving it later <del> const executionDTO = await this._proxy.$getTaskExecution(TaskHandleDTO.from(tTask)); </del> <ins> const handleDto = TaskHandleDTO.from(tTask); const executionDTO = await this._proxy.$getTaskExecution(handleDto); </ins> if (executionDTO.task === undefined) { throw new Error('Task from execution DTO is undefined'); } const execution = await this.getTaskExecution(executionDTO, task); <del> this._proxy.$executeTask(executionDTO.task).catch(() => { /* The error here isn't actionable. */ }); </del> <ins> this._proxy.$executeTask(handleDto).catch(() => { /* The error here isn't actionable. */ }); </ins> return execution; } else { const dto = TaskDTO.from(task, extension);

Related discussion:
text: Apologies, this is a bit hard to replicate, so I'll do my best. Open a python jupyter notebook and do some work. Cut some code in the middle of a line in a cell. Go to a different cell and paste. The pasted code will be duplicated. I was able to replicate after restarting VS Code multiple times. Downgrading to 1.46 fixed the issue for me.
/duplicate of
Code change:
// We have a preserved ID. So the task didn't change. if (tTask._id !== undefined) { // Always get the task execution first to prevent timing issues when retrieving it later <del> const executionDTO = await this._proxy.$getTaskExecution(TaskHandleDTO.from(tTask)); </del> <ins> const handleDto = TaskHandleDTO.from(tTask); const executionDTO = await this._proxy.$getTaskExecution(handleDto); </ins> if (executionDTO.task === undefined) { throw new Error('Task from execution DTO is undefined'); } const execution = await this.getTaskExecution(executionDTO, task); <del> this._proxy.$executeTask(executionDTO.task).catch(() => { /* The error here isn't actionable. */ }); </del> <ins> this._proxy.$executeTask(handleDto).catch(() => { /* The error here isn't actionable. */ }); </ins> return execution; } else { const dto = TaskDTO.from(task, extension);

Related discussion:
text: Issue Type: <bBug</bThis seems to be a regression on VS Code Insiders. It does not repro on stable. If I call , it will only execute that specific task, not the task it dependsOn as well. Here's an example Example code to execute the task: VS Code version: Code - Insiders 1.47.0-insider (, 2020-07-07T07:46:45.605Z) OS version: Darwin x64 19.5.0 <details<summarySystem Info</summary </details<details<summaryExtensions (17)</summaryExtensionVersion ------ vscode-pull-request-github0.17.0 vscode-azureappservice0.17.1-alpha vscode-azureresourcegroups0.2.0 vscode-azurestorage0.9.0 vscode-cosmosdb0.13.0 csharp1.22.1 python2020.6. remote-containers0.127.0 remote-ssh0.51.0 remote-ssh-edit0.51.0 azure-account0.8.11 powershell2020.6.0 vscode-typescript-tslint-plugin1.2.3 java0.64.0 vscode-didact0.1.15 sort-lines1.9.0 vscode-java-debug0.26.0 </details<!-- generated by issue reporter --
Caused by Because the task execution is first gotten, then passed to the extension host, the depends on is lost when passing to the extension host.
Works for me on the latest insiders, thanks!
Thank you for verifying!
Code change:
})); } <del> // this.getElement().classList.toggle('config', true); </del> this._contextMenuService.showContextMenu({ getAnchor: () => e, getActions: () => actions,

Related discussion:
text: I recently noticed an animation to indicate toolbar actions can be changed: ! This seems to be inspired by Safari toolbar when you edit it: ! I am seeing a few issues with our approach: we allow to change visibility of actions in a lot of places (activity bar, status bar) where currently there is no such animation in Safari to get into this mode, the user explicitly picks an action "Customize Toolbar" while for us it starts on right click already in Safari you can actually grab an action and move it, I even think they only animate the action to make that more obvious (not so much the fact that you can hide the action) I would vote for not having the animation until we can support what Safari does including to drag and reorder actions. I think the menu makes it already clear what the right click gesture allows you to do: <img width="299" alt="image" src="https://user-"
Yes, thanks, this feels very strange to me. I don't think animating the whole menubar make sense when you are only operating on a single item.
How about beginning a right-click menu with an inactive entry that acts as a header? Something like "Button Visibility". It would also act as a protection against accidental hiding, since I can imagine some folk inadvertently pressing right button down, moving the mouse a few pixels right, releasing the button and seeing vanish the button they intended to actuate. Especially on Linux where there's a longstanding issue about this happening on context menus at certain Zoom levels and certain places on the screen.
related/motivation
Well, strictly speaking you operate on the whole menu because you also have toggle actions for all its entries. I like that direction. We already do something similar to right click the overflow item. You cannot hide that but you get a disabled "Hide" entry for consistency. On the flip side it is bogus use of menu items as "headers" <img width="340" alt="Screenshot 2022-09-29 at 08 23 30" src="https://user-"Overall the motivation for same kind of animation is mostly the . Left and right click show a context menu which do very different things but look very similar
Any scope for changing the button icon when in this edit mode? Maybe to pencil or gearwheel.
Note that animations like this look pretty terrible on standard DPI monitors due to the blurriness.
Code change:
})); } <del> // this.getElement().classList.toggle('config', true); </del> this._contextMenuService.showContextMenu({ getAnchor: () => e, getActions: () => actions,

Related discussion:
text: It also removes sub-pixel anti-aliasing which makes it look even more different to non-animating. ! Regular: ! Animating: !
is that specific to this animation or something you notice with animations in general? Like the sync-spinner or the language status wiggle?
I also think the spinner looks pretty bad, though it's less noticeable than this I don't think I've noticed this, but any animation like these should have this problem. You can notice it when websites use animations as well, the shift from animated to non-animated is often jarring.
Or even spinning gearwheel
Can you please file a dedicated issue? There is a bunch of places that use CSS animations and if there is a flaw with that we should look at it holistically Created to disable the animation for now. Let's take time in October to revisit this. Lets discuss (1) if this is really needed and (2) if we should align other hide-able items (consistency is key)
created with a lot of details
Code change:
} } <ins> /* Create new file from anywhere */ export class GlobalNewFileAction extends BaseGlobalNewAction { public static ID = 'workbench.action.files.newFile'; public static LABEL = nls.localize('newFile', "New File"); protected getAction(): IConstructorSignature2<ITree, IFileStat, Action> { return NewFileAction; } } </ins> /* Create new folder from anywhere */ export class GlobalNewFolderAction extends BaseGlobalNewAction { public static ID = 'workbench.action.files.newFolder';

Related discussion:
text: VSCode Version: 1.0.0 OS Version: OSX 10.11.3 I noticed that we can set to a keybinding. Which creates a nice input field in the sidebar to create the directory at the current selected position. ! But there is no possibility to do this for a file. Yes you can bind but it does not do the same thing. It just creates a new and when pressing <kbdcmd</kbd+ <kbds</kbdyou have to choose the destination in a picker. So, is it possible to add something for a new file as well? It would really improve my speed because I don't have to touch my mouse anymore to create a new named file in a specific directory.
sounds like a good example for a PR?
Yes I looked into it but to be honest, I have to clue where to start :). So if you can point me in the right direction, I would be very happy to do one :).
I would start by fulltext search for the action id () and that brings you here: From there you can get a feeling how this global action works and maybe add the new one. You will also see the one on top for creating an untitled file (which is not what you want). When you find the references of that action you will see where it is being registered to the system:
Alright, awesome. Thank you very much Will see what I can do :).
Code change:
} }, { <ins> "c": "    ", "t": "text.html.markdown markup.list.numbered.markdown", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": ">", "t": "text.html.markdown markup.list.numbered.markdown markup.quote.markdown beginning.punctuation.definition.quote.markdown", "r": { "dark_plus": "beginning.punctuation.definition.quote.markdown: #608B4E", "light_plus": "beginning.punctuation.definition.quote.markdown: #0451A5", "dark_vs": "beginning.punctuation.definition.quote.markdown: #608B4E", "light_vs": "beginning.punctuation.definition.quote.markdown: #0451A5", "hc_black": "default: #FFFFFF" } }, { "c": " ", "t": "text.html.markdown markup.list.numbered.markdown markup.quote.markdown", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": "Block quotes in list", "t": "text.html.markdown markup.list.numbered.markdown markup.quote.markdown meta.paragraph.markdown", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { </ins> "c": "2.", "t": "text.html.markdown markup.list.numbered.markdown beginning.punctuation.definition.list.markdown", "r": {

Related discussion:
text: VSCode Version: Code 1.18.0 (, 2017-11-08T21:19:36.079Z) OS Version: Windows_NT ia32 6.1.7601 Lists shift the indentation by the level of depth in the list hierarchy. This is just a very minor thing, but the is no longer syntax highlighted when a quote is part of a list item and thus indented. ! Steps to Reproduce: markdown file. a list. a quote to one of the items by indenting the quote. Reproduces without extensions: Yes
Code change:
if [ -z "${RPROMPT-}" ]; then RPROMPT="" fi <del> if [ -z "${PREFIX-}" ]; then PREFIX="" fi </del> fi __vsc_update_prompt() { __vsc_prior_prompt="$PS1" __vsc_in_command_execution="" <del> PS1="%{$(__vsc_prompt_start)%}$PREFIX$PS1%{$(__vsc_prompt_end)%}" </del> <ins> PS1="%{$(__vsc_prompt_start)%}$PS1%{$(__vsc_prompt_end)%}" </ins> PS2="%{$(__vsc_continuation_start)%}$PS2%{$(__vsc_continuation_end)%}" if [ -n "$RPROMPT" ]; then __vsc_prior_rprompt="$RPROMPT"

Related discussion:
text: Type: <bBug</bIn the new shell integration options for Bash and Zsh, VS Code wraps the PS1 prompt variable to support new functionality. However, when it does this, it prefixes the PREFIX environment variable to the existing PS1 when creating the new PS1 prompt. See the picture below for an example. ! For Bash, the problem is at: For Zsh, see: Steps to reproduce: either Bash or Zsh, enable the integrated terminal a value to a variable named PREFIX in the integrated terminal that the value you assigned to PREFIX is prepended to the prompt The PREFIX environment variable is commonly used across a variety of projects in the Linux world for configuring and building applications (grepping for 'PREFIX during the build process and it makes the terminal hard to use. This issue is the cause of . I can submit a pull request for this if you'd like. VS Code version: Code 1.71.0 (, 2022-09-01T07:36:10.600Z) OS version: Windows_NT x64 10.0. Modes: Sandboxed: No Remote OS version: Linux x64 5.10.102.1-microsoft-standard-WSL2 <!-- generated by issue reporter --
thanks for the investigation and yes would appreciate a PR for this
I can't remember why PREFIX is there, we should blame history before doing the fix
Looks like PREFIX was only used in the initial commit to accomplish what is currently done with _vscpromptstart(), and it was safe to do so as PREFIX was declared as a local variable. Here are the original commits of the relevant files: Zsh: Bash: The second commit to modify these files () modified the updateprompt() function and removed the local PREFIX variable, but did not remove the variable from the PS1 assignment.
For Zsh specifically, in , extra references to PREFIX were to fix a separate issue.
Nice, looks like it's safe to switch to in bash. I'm guessing it's safe in zsh too, do you agree?
<!-- 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!
/verified
Code change:
} this._widget = <IBorrowValue<NotebookEditorWidget>>this._instantiationService.invokeFunction(this._notebookWidgetService.retrieveWidget, group, input); <ins> if (this._rootElement && this._widget.value!.getDomNode()) { this._rootElement.setAttribute('aria-flowto', this._widget.value!.getDomNode().id || ''); DOM.setParentFlowTo(this._widget.value!.getDomNode(), this._rootElement); } </ins> this._widgetDisposableStore.add(this._widget.value!.onDidChangeModel(() => this._onDidChangeModel.fire())); this._widgetDisposableStore.add(this._widget.value!.onDidChangeActiveCell(() => this._onDidChangeSelection.fire({ reason: EditorPaneSelectionChangeReason.USER })));

Related discussion:
text: Issue Type: <bBug</bSteps to Reproduce: a notebook. In my case, I have a Jupyter notebook (.ipynb). any of the "" or "" or "" or "". happens! These navigation commands work just fine in all other views/panels that I regularly use. VS Code version: Code 1.66.2 (Universal) (, 2022-04-11T07:49:20.994Z) OS version: Darwin arm64 21.4.0 Restricted Mode: No <details<summarySystem Info</summary </detailsExtensions disabled <!-- generated by issue reporter --
this sounds like a real bug to me, the issue is that notebooks do not seem to be rooted below the editor part in the DOM: ! That asks for trouble because we have lots of checks in code to figure out if the editor area has DOM focus or not, e.g.: What is the rationale? I checked with custom editors, and they manage to put the into the DOM hierarchy of the editor part. //cc
We render the notebook out of the grid view as it contains a webview, which can not be re-parented when users drag editors between groups. I basically followed what Custom Editor does did we change this recently? I wonder if it's already safe to do so.
Can confirm that I am also experiencing this. In the meantime, I've found that this kind of works for moving left and right: But there is no or , and this fails when attempting to move to panels. Looking forward to a fix, or if anyone has a workaround.
fyi we no longer use but only , so maybe that changed.
<img width="1918" alt="image" src="https://user-"I found that we are not putting custom editor webviews in the editor grid either.
oh ok, turns out we seem to have logic to still make that work via a special code, looks like notebooks should adopt it as well: And the relevant method using it:
Yes to my knowledge iframes still cannot be reparented. All webviews are rendered as top level elements with absolute positioning to work around this Let me know if you have any questions about using . It should help fix this issue as I believe I've already fixed a similar issue for webviews
This feels like a useful workaround.
Code change:
} this._widget = <IBorrowValue<NotebookEditorWidget>>this._instantiationService.invokeFunction(this._notebookWidgetService.retrieveWidget, group, input); <ins> if (this._rootElement && this._widget.value!.getDomNode()) { this._rootElement.setAttribute('aria-flowto', this._widget.value!.getDomNode().id || ''); DOM.setParentFlowTo(this._widget.value!.getDomNode(), this._rootElement); } </ins> this._widgetDisposableStore.add(this._widget.value!.onDidChangeModel(() => this._onDidChangeModel.fire())); this._widgetDisposableStore.add(this._widget.value!.onDidChangeActiveCell(() => this._onDidChangeSelection.fire({ reason: EditorPaneSelectionChangeReason.USER })));

Related discussion:
text: Concerning moving up and down, you can use the and actions ().
works great, it would be great if you can help review
This seems to be working for me now in insiders but feel free to speak up if it's not doing what you expect
Yep, this seems to be fixed in the insiders build. Looking forward to seeing it merged into stable! Thanks everyone!