jiebi/CodeConvo huggingface dataset:
Change:
} private registerViews(container: ViewContainer): void { <del> const viewId = 'workbench.views.editSessions.data'; </del> <ins> const viewId = EDIT_SESSIONS_DATA_VIEW_ID; </ins> const name = localize('edit sessions data', 'All Sessions'); const treeView = this.instantiationService.createInstance(TreeView, viewId, name); treeView.showCollapseAllAction = true;

Discussion:
Testing Store an edit session in for a GH repo Open desktop Insiders Use GH Repositories extension to open same remote GH repo Edit Sessions view is empty - since I'm logged into GH in both web and desktop, I anticipated seeing my 3 edit sessions from here: !
Duplicate of If you run the 'Focus on All Sessions View' command, do your edit sessions show up? In tomorrow's insiders that view container should only appear in the sidebar after you explicitly run the command to Show Edit Sessions.
These are the only edit session commands I see in desktop today: ! I see more options in than desktop - should I be seeing more of these options in desktop? ! Maybe this is a dupe of Edit: Yes, this seems to be When I stored an edit session in desktop, I was prompted to log into GH Repositories, and now I see more options: ! Except now I still don't see anything in the Edit Sessions view in desktop, although I'm working on the same GH repo through GH Repositories that I was working on in the web: !
Ah, I had to select the menu in the Edit Session view, and choose to "Show all sessions." Now I can see the session from I would've expected to see all my edit sessions by default.
that shouldn't happen, the 'Edit sessions' view container should be hidden unless the 'All sessions' view is also showing. Do you recall how you got the edit sessions container to show up without the sessions ?
I believe these were my steps: Make an edit and store a session in Open same repo via GH Repositories in desktop VS Code Make an edit and store a session in desktop Storing in desktop prompts me to log into GH Once logged in and the session is stored, run command to Confused because Edit Session view is empty I manually select menu in Edit Session view to and then I can see my sessions (I guess the web ones were hidden by default in desktop)
:+1: tracking as
I couldn't repro this yesterda on desktop, but just repro-ed this with a clean user data dir, this is a bug with the Show Edit Sessions action. It should focus the view, not the container.
<!-- 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!
I'm trying to test this again, but I don't see any edit session commands: ! Am I missing something?
/verified
Change:
) { } public execute() { <del> if (this.previewManager.activePreviewResource) { return vscode.workspace.openTextDocument(this.previewManager.activePreviewResource) .then(document => vscode.window.showTextDocument(document)); </del> <ins> const { activePreviewResource, activePreviewResourceColumn } = this.previewManager; if (activePreviewResource && activePreviewResourceColumn) { return vscode.workspace.openTextDocument(activePreviewResource).then(document => { vscode.window.showTextDocument(document, activePreviewResourceColumn); }); </ins> } return undefined; }

Discussion:
Issue Type: <bBug</b! When using the Markdown preview, the "Show Source" action should be smart enough to know that the source is open and go to that tab. Same applies to the preview tab, if there is already a preview tab open switch focus there. Otherwise you're in this endless loop of creating duplicate tabs. VS Code version: Code - Insiders 1.35.0-insider (, 2019-05-20T05:15:57.974Z) OS version: Darwin x64 18.2.0 <details<summarySystem Info</summary </details<details<summaryExtensions (30)</summaryExtensionVersion ------ vscode-browser-preview0.5.4 vscode-opennewinstance0.0.6 bracket-pair-colorizer1.0.61 vscode-svgviewer2.0.0 vscode-eslint1.9.0 gitlens9.7.4 vsc-material-theme2.8.2 prettier-vscode1.9.0 azure-virtual-machine-explorer0.0.2 vscode-pull-request-github-insiders1.137.0 vscode-colorize0.8.10 theme-monokai-pro-vscode1.1.13 vscode-azureappservice0.14.0 python2019.4. remote-containers0.53.0 remote-ssh0.37.0 remote-ssh-edit0.37.0 remote-ssh-explorer0.37.0 remote-wsl0.36.0 azure-account0.8.4 azurecli0.4.5 vscode-typescript-tslint-plugin1.0.0 debugger-for-chrome4.11.3 vetur0.21.0 vscode-docker0.6.2 vscode-yaml0.4.0 code-settings-sync3.2.9 ayu0.18.0 WebTemplateStudio-dev-nightly0.0. markdown-all-in-one2.3.1 (17 theme extensions excluded) </details<!-- generated by issue reporter --
I'd like to give this a try
Ok, I could use some help on this issue. I traced the click call to the function , but am not sure if I should be making any changes here since it will very likely affect other functionalities as well.

I also noticed that if I have the file already open in the same split window pane, it will open that instead of creating a new split pane, but it is even when it opens a new pane with a new tab. So I am confused how calling the same function with the same parameter exhibits different behaviors (opening a new pane with a new tab vs opening an already open tab in the same pane). ! Some pointers around this would be very helpful, thanks
sorry for tagging you, not sure if you got a chance to see my previous comment. Can you please help out?
The api you linked to is a good starting point but that is part of core VS Code. You want the caller of that api, which in the case is the markdown extension. How I think this feature should work: the markdown extension, we maintain a . These should track which column created the preview. This is likely already passed in with , we just don't store the resourceColumn anywhere as far as I remember. the is invoked, use the preview's column information to decide which column to show the preview in
Change:
"%configuration.markdown.preview.openMarkdownLinks.inEditor%" ] }, <ins> "markdown.editor.openMarkdownLinks": { "type": "string", "default": "currentGroup", "description": "%configuration.markdown.editor.openMarkdownLinks.description%", "scope": "resource", "enum": [ "currentGroup", "openToSide" ], "enumDescriptions": [ "%configuration.markdown.editor.openMarkdownLinks.inCurrentGroup%", "%configuration.markdown.editor.openMarkdownLinks.openToSide%" ] }, </ins> "markdown.trace": { "type": "string", "enum": [

Discussion:
Scenario: Markdown file is open in left editor group. This file has a lot of links to other .md files that I want to preview in the right editor group. But Markdown links can currently only be opened into the same editor. Please consider. Thanks!
Adding per our discussion about this one
Do you mean that you would like an option to make the command to open the preview to the left instead of to the right of the current editor?
No, sorry, I should have been more specific. Here's what I mean: -click to open a .md file in a persistent editor in Code, preferably a file with many links to other local .md files. the file, Ctrl+click a link to another .md file. other file opens in a new editor, in the same editor group. Desired: open the link as a raw .md file in a new or existing (separate) editor group. Then, when I go back to the original file and ctrl+click another .md link, open that raw .md into the same editor group the previous one opened into. So I can quickly ctrl+click through a bunch of links and see the raw .md while my original file (the one with all the links) stays in view.
Ok, thanks for explaining the expected behavior in more detail. Marking as help wanted if anyone wants to investigate this. To get started, look at: This is where we map markdown links to command links This is where we convert the command into an editor action. Instead of opening in the current editor, we would want to open in a new editor group here
For verification: new setting was called are two options: (the default) and links in md text files (not the preview) should respect this option default behavior should be to open links in the current group
Can't verify because of
I can verify this on Mac.
Thanks for adding this!
Change:
fi __vsc_command_complete "$__vsc_status" <ins> __vsc_current_command="" </ins> # in command execution if [ -n "$__vsc_in_command_execution" ]; then

Discussion:
This is a follow up from which worked around the majority case of an issue. See the workaround: The proper fix will involve sending both the exit code and the history ID over to VS Code which will then do what's happening now but also have the correct exit code to set, instead of assuming it's the last command's exit code. We should write a little script as part of this that alternates exit codes by setting/unsetting an environment variable so it's easier to test and verify.
The issue being worked around is actually caused by or being included in .
Good test case from
To verify: some commands , they should all show up in current session ctrl+c in between some commands, including typing out a command and hitting ctrl+c to abandon it , the lines with ctrl+c shouldn't show up several times, failed and success should match whether the exception was thrown.
Change:
'use strict'; <del> import { spawn, exec } from 'child_process'; import * as path from 'path'; import * as nls from 'vs/nls'; import URI from 'vs/base/common/uri'; </del> <ins> import { exec } from 'child_process'; </ins> export interface ProcessItem { name: string;

Discussion:
After updating the module to support getting memory, cpu, and command line for each process on windows (), the module can be used in more places within VSCode [x] Update existing version of the module that's being used in the terminal [x] Use the module in place of the PowerShell script in
Change:
import { CellKind, CellStatusbarAlignment, INotebookCellStatusBarItem, INotebookCellStatusBarItemList, INotebookCellStatusBarItemProvider } from 'vs/workbench/contrib/notebook/common/notebookCommon'; import { INotebookKernelService } from 'vs/workbench/contrib/notebook/common/notebookKernelService'; import { INotebookService } from 'vs/workbench/contrib/notebook/common/notebookService'; <del> import { ILanguageDetectionService } from 'vs/workbench/services/languageDetection/common/languageDetectionWorkerService'; </del> <ins> import { ILanguageDetectionService, LanguageDetectionHintConfig } from 'vs/workbench/services/languageDetection/common/languageDetectionWorkerService'; </ins> import { LifecyclePhase } from 'vs/workbench/services/lifecycle/common/lifecycle'; class CellStatusBarLanguagePickerProvider implements INotebookCellStatusBarItemProvider {

Discussion:
The candidate fix for was to just disable language detection in notebooks by default. With a bit more time to work on it, a better solution should be derived.
is this fix insider released?
is it now :)
Change:
static updateKernelStatusAction(notebook: NotebookTextModel, action: IAction, notebookKernelService: INotebookKernelService) { const detectionTasks = notebookKernelService.getKernelDetectionTasks(notebook); if (detectionTasks.length) { <ins> const info = notebookKernelService.getMatchingKernel(notebook); </ins> action.enabled = true; <del> action.label = localize('kernels.detecting', "Detecting Kernels"); </del> action.class = ThemeIcon.asClassName(ThemeIcon.modify(executingStateIcon, 'spin')); <ins> if (info.selected) { action.label = info.selected.label; const kernelInfo = info.selected.description ?? info.selected.detail; action.tooltip = kernelInfo ? localize('kernels.selectedKernelAndKernelDetectionRunning', "Selected Kernel: {0} (Kernel Detection Tasks Running)", kernelInfo) : localize('kernels.detecting', "Detecting Kernels"); } else { action.label = localize('kernels.detecting', "Detecting Kernels"); } </ins> return; }

Discussion:
My impression of the slowness that mentioned In stable and insiders, I think the run button shows up at about the same time. Around 7-9s from "reload window" to the run button appearing, hard to tell whether stable is slightly faster. But after it appears, and the preferred kernel has been discovered, I see "Discovering Kernels" for another 5s or more, which could lead to an impression of slowness if the user doesn't realize they can go ahead and run a cell at this point. Originally posted by in
<img width="183" alt="image" src="https://user-"When there is already a selected kernel, we should show the kernel name and a spinner if there are pending detection tasks.
Change:
args = stripAppPath(args) || []; } <ins> // Ignore empty path arg stripEmptyPath(args); </ins> return validate(parseArgs(args)); }

Discussion:
VSCode Version: 1.26.0 OS Version: macOS Steps to Reproduce: in command line. Code seems opened a workspace of current directory folder, like Does this issue occur when all extensions are disabled?: Yes When I run some command like (e.g. in Linux), if the inner command failed, it return empty string as argument. VSCode shouldn't open current directory and replace the workspace (which is annoying), but should just open or focus the application instead.
Note: Neither Notepad++ or Sublime Text will open a folder wrongly with empty string argument.
what would you expect to happen, open an empty window?
Yes. Or focus existing window only. Just like running .
Wrong press "close"
Can I be assigned to this? I'd like to take a stab at it.
I've code that should do the trick. I've tested that it removes an empty argument. I wasn't able to test the actual functionality though because both and change the current directory. I couldn't figure out how to mimic production without hacking the startup scripts.
I just edited the main description to add an example usage - - which open a script file in environment PATH by VS Code to edit it. If the argument "$1" (for the script name) have typo, VS Code open a big slow workspace folder annoyingly. The existing behavior has no use, and it put the burden to user to write extra lines of if-else to avoid it, resulting in a big command & more typings.
Change:
readonly contextKeyService: IContextKeyService; private listSupportsMultiSelect: IContextKey<boolean>; <ins> private listSupportFindWidget: IContextKey<boolean>; </ins> private hasSelectionOrFocus: IContextKey<boolean>; private hasDoubleSelection: IContextKey<boolean>; private hasMultiSelection: IContextKey<boolean>;

Discussion:
I think this came up during the standup today, why is the context key called and not ? //cc
This context key came in quite late via a fix -- . I noticed this standing out because of the default keybindings which seem to mix things up: Giving this a candidate in case we want to align the context key before shipping stable
From
Change:
.scm-view .button-container .monaco-description-button > .monaco-button-label, .scm-view .button-container .monaco-description-button > .monaco-button-description { <ins> font-weight: normal; </ins> font-style: inherit; padding: 4px 0; }

Discussion:
Testing Is the commit button supposed to be bold for the Commit & Sync option when the button isn't wide enough? !
nice catch!
Change:
// arguments                    result [[['/var/lib', '../', 'file/'], '/var/file'], [['/var/lib', '/../', 'file/'], '/file'], <del> [['a/b/c/', '../../..'], process.cwd()], [['.'], process.cwd()], </del> [['/some/dir', '.', '/absolute/'], '/absolute'], [['/foo/tmp.3/', '../tmp.3/cycles/root.js'], '/foo/tmp.3/cycles/root.js'] ] <ins> ], [(isWeb ? path.posix.resolve : path.resolve), // arguments						result [[['.'], process.cwd()], [['a/b/c', '../../..'], process.cwd()] </ins> ] <ins> ], </ins> ]; resolveTests.forEach((test) => { const resolve = test[0];

Discussion:
We will ship Electron with to stable soon so we should also look into bringing our copy of library to the same version. Checking for the diff, it seems to be a few commits after and up until //cc
Hm, the first change is already pretty bad for us: Because it seems to depend on a new thing which is maybe defined globally and probably optimised / cached / snapshotted. Maybe we should rather look out for actual bug fixes and focus on those... Changes: I think only the 2 fix commits stand out from the others
I assume you skipped over right?
Reopening given unit test failures, I had to revert the change for now.
yes I skipped the primordials. I didn't dig into why they do this, but it seemed easy enough to just call the string functions instead. As for the test failures, new PR
Primordials are only meant for Nodejs internal code usage, external users should just replace them with corresponding JavaScript builtins. You can read more about why Nodejs does it
Change:
glob-to-regexp "^0.4.1" graceful-fs "^4.1.2" <del> web-tree-sitter@^0.20.7: version "0.20.7" resolved "https://registry.yarnpkg.com/web-tree-sitter/-/web-tree-sitter-0.20.7.tgz#b0ddb78e8244221a3100f432c7e162516cd9cd09" integrity sha512-flC9JJmTII9uAeeYpWF8hxDJ7bfY+leldQryetll8Nv4WgI+MXc6h7TiyAZASWl9uC9TvmfdgOjZn1DAQecb3A== </del> <ins> web-tree-sitter@^0.20.8: version "0.20.8" resolved "https://registry.yarnpkg.com/web-tree-sitter/-/web-tree-sitter-0.20.8.tgz#1e371cb577584789cadd75cb49c7ddfbc99d04c8" integrity sha512-weOVgZ3aAARgdnb220GqYuh7+rZU0Ka9k9yfKtGAzEYMa6GgiCzW9JjQRJyCJakvibQW+dfjJdihjInKuuCAUQ== </ins> webidl-conversions@^3.0.0: version "3.0.1"

Discussion:
<img width="415" alt="image" src=""Looks localized here though, and hasn't changed in 13 months
language pack looks ok too... Looking into this some more... it seems that the new lines aren't being handled properly.
This still repros :/ is the loc pipeline maybe not running?
it is the newlines... which I thought I fixed... sigh... They are being escaped in the language pack: if I manually delete these extra slashes locally, the problem goes away.
Update... the text has change: Now it's using when it should use and I think I know why. So exporting looks find: is turned in to (we do this manually and it's the XML way to say ) but what we get from the translators... they replace with actual new lines That's not what I was expecting. I would expect them to use the encoded characters but they're not. hacky quick fix that fixes likely most of the scenarios: more accurate longer fix: now that I think about it, this is probably the correct workaround for extensions as well
<img alt="image" src=""Looks like it works now
Change:
toGitUri(uri: Uri, ref: string): Uri; getRepository(uri: Uri): Repository | null; <del> init(root: Uri): Promise<Repository | null>; </del> <ins> init(root: Uri, options?: InitOptions): Promise<Repository | null>; </ins> openRepository(root: Uri): Promise<Repository | null> registerRemoteSourcePublisher(publisher: RemoteSourcePublisher): Disposable;

Discussion:
I would have expected that the command creates a repository with a branch 'main'. I was using the latest insider: This is the repository created using 'Publish to Github'
Related to
In this particular scenario we should honor the default branch setting on GitHub rather than the VS Code setting.
Change:
if (this.ui.inputBox.password !== this.password) { this.ui.inputBox.password = this.password; } } }

Discussion:
When creating a new profile, the input has no margins: ! Compare that with the rename one: !
I am using the quick pick in the same way for both and I do not know how they are rendered differently. So moving to for his insights.
Ah so the difference seems to be that the first one isn't the first quickpick that is shown... first we see: ! Then we see the first input box you've shared. So I'm thinking theres some CSS class bleeding through
Change:
return; } <del> const useLogicalLine = (args && args.logicalLine === true); </del> <ins> let useLogicalLine = true; if (args && args.logicalLine === false) { useLogicalLine = false; } </ins> const viewModel = editor._getViewModel(); if (viewModel.cursorConfig.readOnly) {

Discussion:
The current behaviour in VSCode with is like this: ! But I would prefer an option for this ! Note I used the gif from which I found while looking for a solution.
Since this would operate on the model (not the view model), this can be implemented from an extension.
Is anybody intending to do anything about this, extension or otherwise? seems to imply that the current behavior is by design, but I believe it is literally useless. Additional cursors positioned in parts of the same wrapped line are placed "randomly" (depending on the view width) - I can't see how this behavior could be compatible with any legitimate use case of multiple cursor editing. I suggest this issue should be called a bug, unless a use case can be demonstrated that benefits from the current behavior.
I would say the current implementation is not just useless like points out, but outright dangerous: I have many times accidentally some garbage in the wrapped lines which I have had to hunt for later on. It just happened for me again, which prompted to finally find out why this glaring bug hasn't been fixed already. So even if there would be a use case for the current behavior, I would prefer it to be disabled by default to avoid hard-to-notice accidental edits. I love the multi-cursor support in VS Code (I find new uses for ctrl+d all the time), but this wrapping behavior has caused me to a bit afraid to use it as much as before. I guess this doesn't bite all users frequently, but I have my editor on a vertical monitor and have enabled wrapping and frequently edit code with too long lines, so I'm dealing with the wrapping hazard daily.
Agreed, this behavior is unexpected and often results in deletions or additions mid-line which I discover later during compiles.
Would also like to see the default behaviour reversed.
Since I couldn’t find an extension that provided this behavior, and implied that it could be done through an extension, I implemented one. I hope this is also useful to others:
Even if there is an extension that provides bindings for this now, I believe this is still a missing core feature. If this is the intended default behavior, so be it, but at least give us an option to change it, please? Multi-cursor editing would be so much better if we could actually select the lines we want to!
Do the reassigned labels mean, you want a contribution for this issue?

If so, I would like to grab it. Should the behavior replace the old behavior, or should it be an option?
I think it makes sense to change the default behavior, but I would need to discuss that with the team. It should be easy to come up with a PR though.
The workaround today is to define the following keybindings: This issue would be very easy to implement, as it would involve just changing the default of from to here:
Change:
for (const match of text.matchAll(autoLinkPattern)) { const link = match[1]; <del> const linkTarget = parseLink(document, link); </del> <ins> const linkTarget = resolveLink(document, link); </ins> if (linkTarget) { const offset = (match.index ?? 0) + 1; const linkStart = document.positionAt(offset);

Discussion:
while testing a markdown file with a header a notebook with a markdown cell and link to that header the link in the rendered markdown result: vscode attempts to navigate to a file named note that both auto-complete and find references for the header work correctly for that link.