jiebi/CodeConvo huggingface dataset:
Code change:
// De-prioritze auto-imports // https://github.com/microsoft/vscode/issues/40311 this.sortText = 'uffff' + tsEntry.sortText; <ins> // Render "fancy" when source is a workspace path const qualifierCandidate = vscode.workspace.asRelativePath(tsEntry.source); if (qualifierCandidate !== tsEntry.source) { this.label2 = { name: tsEntry.name, qualifier: qualifierCandidate }; } </ins> } else { this.sortText = tsEntry.sortText; }

Related discussion:
text: The autocomplete just got even more useless! Here are the options that I see (cycling using ctrl+space): <img width="735" alt="Screenshot 2020-06-25 at 10 54 43" src="https://user-"<img width="761" alt="Screenshot 2020-06-25 at 10 55 24" src="https://user-"Previously the detail screen showed details on the option, not details why this suggestion is being provided. What's the use of that to a developer? Have I unknowingly enabled some obscure autocomplete-debugging mode or something?
Yes. Press to toggle the suggest debug mode
does nothing. I couldn't find anything similar in the command palette either nor by googling.
Aha! To en/disable the suggest debug mode (on European keyboard): the suggestion dialog (i.e. the same hotkey as for (un)commenting a line) (I figured it out by seeing that on a US keyboard is .) So if you accidentally have the suggestions open when trying to comment out a line, you'll end up with a useless autocomplete system and no idea how to make it work again. May I suggest that a functionality that is useful to 0.01% of users and causes a lot of confusion for 99.99% if accidentally used would not have a default hotkey? It could be clearly labeled as "Toggle autocomplete suggest debug mode" or similar in the command palette, which would be just as easy for suggestion debugging cases but users would not accidentally trigger it.
Just a heads-up that for the suggest widget and its details parts are going to be resizable. See This issue will all about the specific TS case and how to improve the situation for auto-importing modules
There might be more to it and things I don't know esp. the doc for says it might not be human readable but it kinda looks nice already. <img width="584" alt="Screenshot 2020-11-02 at 12 37 51" src="https://user-"
Code change:
import { INotebookKernelService } from 'vs/workbench/contrib/notebook/common/notebookKernelService'; import { IEditorService } from 'vs/workbench/services/editor/common/editorService'; <del> export type contextMenuArg = { source?: string; type?: string; value?: string; expression?: string; language?: string; extensionId?: string }; </del> <ins> export type contextMenuArg = { source: string; name: string; type?: string; value?: string; expression?: string; language?: string; extensionId?: string }; </ins> export class NotebookVariablesView extends ViewPane {

Related discussion:
text: similar to the 'open in data viewer' command from the jupyter variables view, we should allow extensions to contribute a view for a variables for specific language/types on the built in tree view.
That would essentially be number 6 in this screenshot from the Julia extension , right?
Same idea, either with an icon like that or through the context menu on that item. In the jupyter extension's case, we are planning to allow contributions for data viewers from extensions that didn't necessarily provide the variables.
Cool. I think icon and context menu would be great ;) It might also make sense to think a bit ahead there: there are probably some kind of viewers that are relevant for a lot of languages (tabular data, plots) and others that are very language specific. From our end, we would love it if VS Code at some point gained a generic tabular viewer, and a plot viewer that we could utilize and get rid of our custom implementations as well :) So maybe some kind of API design where in the future one could hook into a as of yet not existing generic tabular/plot viewer.
Example implementation here The menu contribution point name will likely change names when we expand the usage beyond notebooks, but any needed migration will be pretty straight forward.
I created a sample extension and cannot see any variables showing up. Do I need to enable something in VS Code for this feature to work. I couldn't find any settings/experiments that had to be enabled for this.
Found that I needed to enable a VS Code experiment (I was looking for Jupyter experiments). Not sure the API is useful in its current form. Currently when i create a viewer for DataFrames, lists, objects, anything I do not get the name of the variable. Hence I have no idea what I'm looking at, all I get is a value, and thats basically a stringified version of the value. Thus its not really possible to create any viewer, unless of course I'm missing something here.
Moving to March for now. Feel free to move back to February if the issue has been verified or once steps are provided and the issue is verifiable in the latest Insiders. Edit: I confirmed using the sample extension that the viewer does not report the variable name.
Code change:
import { INotebookKernelService } from 'vs/workbench/contrib/notebook/common/notebookKernelService'; import { IEditorService } from 'vs/workbench/services/editor/common/editorService'; <del> export type contextMenuArg = { source?: string; type?: string; value?: string; expression?: string; language?: string; extensionId?: string }; </del> <ins> export type contextMenuArg = { source: string; name: string; type?: string; value?: string; expression?: string; language?: string; extensionId?: string }; </ins> export class NotebookVariablesView extends ViewPane {

Related discussion:
text: verification: sure you have jupyter and python extensions enabled the notebook variable view the or create your own some notebook cells that create variables and open the debug sidebar to see the notebook variable view that the command contributed to the menu is provided information about the variable ( should be the expression that would access that variable)
Code change:
const element = document.createElement('span'); element.classList.add('output-stream'); <ins> element.setAttribute('output-item-id', outputInfo.id); </ins> const text = outputInfo.text(); insertOutput(outputInfo.id, [text], ctx.settings.lineLimit, ctx.settings.outputScrolling, element);

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: Stable & Insiders OS Version: Any Steps to Reproduce: Jupyter extension the following cell against a Python kernel The expected output is fairly simple: ( can appear some where in the middle) However VS Codes output is incorrect We are missing the line breaks (looks like this PR seems to have broken that) (using blockinline-block` fixes this). We have duplicate entries (as you can see below, we have multiple times) i think this has to do with the fact that we're trying to re-use the previous output and append the new stuff into the previous output element Note: This can be repro'ed in stable as well, but if i were to remove the code that tries to append to the previous element, then it looks as expected. Not sure when this part of the code broken though. Didn't go through the change log to determine this, you might have a better idea.
note that this is from the test, so that could probably be modified to check for the fix
It looks like this was briefly solved (at least for me as I reported in ) but the problem is now reappearing.
I agree, I can replicate the same bug again, hence reopening this issue. Looks like subsequent change regressed the fix.
seems to be a worse regression now (only in insiders) and repros without needing to do anything with background threads (unless I just have some bad setting): !
I'm seeing something similar with the JavaScript/tslab notebook I use for teaching async and promises. Previously, the output was inconsistent across runs with sometimes missing or duplicated output.
Code change:
const element = document.createElement('span'); element.classList.add('output-stream'); <ins> element.setAttribute('output-item-id', outputInfo.id); </ins> const text = outputInfo.text(); insertOutput(outputInfo.id, [text], ctx.settings.lineLimit, ctx.settings.outputScrolling, element);

Related discussion:
text: Now all the expected output is present but with line breaks appearing only after some async code (e.g. ) is executed. <img width="661" alt="image" src="https://user-"
I reproduced output shown by above with missing new lines in code-insiders at ~14:00 UTC +1 (CET). In a code-insiders session that has been running last 24 hours. Restarting code-insiders approximately an hour later (15.00 UTC+1), the output is now shown with correct line breaks, see screenshot below. Version: 1.75.0-insider (user setup) Commit: Date: 2023-01-09T05:29:27.679Z Electron: 19.1.8 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Windows_NT x64 10.0. Sandboxed: Yes Output after code-insiders restart: !
confirmed that this no longer seems to reproduce on the latest.
Adding label as confirmed above.
Code change:
promises.push(this.uninstallInServer(server, extensions)); } <del> await Promise.allSettled(promises); </del> <ins> const result = await Promise.allSettled(promises); const errors = result.filter(r => r.status === 'rejected').map(r => r.reason); if (errors.length) { throw new Error(errors.map(e => e.message).join('n')); } </ins> } private async uninstallInServer(server: IExtensionManagementServer, extensions: UninstallExtensionInfo[]): Promise<void> {

Related discussion:
text: From ! It took me a while to be able to use Copilot again. Here are the steps I took (also captured in the attached video): Reloaded VS Code Clicked "Show Extension" from the toast above, I'm brought to Copilot Chat extension in Extensions view Clicked "Uninstall" for Chat extension, nothing would happen Decided to instead search Copilot in Extensions view (thought maybe I was having issues by trying to uninstall Chat without touching Completions, though I would've expected a toast telling me that) After searching, the Copilot extensions automatically start to update Need to restart just Copilot (not chat), so I click to restart I try to uninstall Copilot Chat again, but nothing happens again Reload VS Code again Search for Copilot again in the Extensions view I can now uninstall Copilot (though I initiated the uninstall from the Copilot extension rather than Chat)
Verification steps are in
Code change:
readonly executingCommandObject: ITerminalCommand | undefined; /** The current cwd at the cursor's position. */ readonly cwd: string | undefined; <ins> /** * Whether a command is currently being input. If the a command is current not being input or * the state cannot reliably be detected the fallback of undefined will be used. */ readonly hasInput: boolean | undefined; </ins> readonly onCommandStarted: Event<ITerminalCommand>; readonly onCommandFinished: Event<ITerminalCommand>; readonly onCommandInvalidated: Event<ITerminalCommand[]>;

Related discussion:
text: Repro: in a terminal and select something ! We should hit ctrl+c beforehand () which should work properly on all shells
We should also do this when is clicked in the decoration's context menu
I attempted this in but it was more complicated than I originally anticipated. Moving to backlog.
Code change:
import { DomEmitter } from 'vs/base/browser/event'; import { CommentContextKeys } from 'vs/workbench/contrib/comments/common/commentContextKeys'; import { FileAccess } from 'vs/base/common/network'; <ins> import { COMMENTS_SECTION, ICommentsConfiguration } from 'vs/workbench/contrib/comments/common/commentsConfiguration'; </ins> class CommentsActionRunner extends ActionRunner { protected override async runAction(action: IAction, context: any[]): Promise<void> {

Related discussion:
text: PR introduced a max-height on comments, which goes against my team's use case when using the . Since our tours have animated GIFs that support our hands-on coding labs, the reduced max-height makes it impossible for a user to see entire images in the comment frame at once, which imposes a negative learner experience. (See: for comparison across versions). Proposed feature is to allow a user to set a max-height rather than imposing a max-height.
I also think it should be settable through the API. My original on the PR has a comment exchange with about this at the place where I originally hardwired it.
Generally we try not to add API unless we see a clear case for having it. At the time suggested the max height I wasn't aware of a use case that would require a comment peek view to have a larger size. your case makes sense, and makes the case for having API for this. I would make this API rather than user configurable.
Yes, making the max-height configurable via the API makes perfect sense, since any extension can be configured with that functionality to set a max-height attribute that makes sense for the use case. Would the default behavior go back to expanding the height with the content?
I'm not sure yet which would be default. I will discuss with our UX folks and see what they prefer.
My humble preference would be to adopt the old behavior as the default. Though the CodeTour extension is open source, it’s only seen one update in the past year. My team has a stale PR from 2021 on the CodeTour repo that was never commented on, so I’m afraid that even if we opened a PR with a fix for the max-height problem, it might not ever get accepted and merged. On the other hand, my team has been discussing forking CodeTour so that we can control the addition of new functionality and bug fixes.
There wasn't enough interest in adding API for this, so I the user setting .
thanks! Is a boolean? If so, is the default (maintaining the as by default) or (no defined?
It is a boolean and the default is true, meaning the max height of a comment will be 20em.
<!-- 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.
Code change:
import { DomEmitter } from 'vs/base/browser/event'; import { CommentContextKeys } from 'vs/workbench/contrib/comments/common/commentContextKeys'; import { FileAccess } from 'vs/base/common/network'; <ins> import { COMMENTS_SECTION, ICommentsConfiguration } from 'vs/workbench/contrib/comments/common/commentsConfiguration'; </ins> class CommentsActionRunner extends ActionRunner { protected override async runAction(action: IAction, context: any[]): Promise<void> {

Related discussion:
text: 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 Works great! Thanks!
Thanks for verifying!
Code change:
import { TreeResourceNavigator, WorkbenchTree } from 'vs/platform/list/browser/listService'; import { INotificationService, Severity } from 'vs/platform/notification/common/notification'; import { IProgressService } from 'vs/platform/progress/common/progress'; <del> import { IPatternInfo, ISearchComplete, ISearchConfiguration, ISearchHistoryService, ISearchHistoryValues, ISearchProgressItem, ITextQuery, VIEW_ID, SearchErrorCode } from 'vs/platform/search/common/search'; </del> <ins> import { IPatternInfo, ISearchComplete, ISearchConfiguration, ISearchHistoryService, ISearchHistoryValues, ISearchProgressItem, ITextQuery, VIEW_ID, SearchErrorCode, ISearchConfigurationProperties } from 'vs/platform/search/common/search'; </ins> import { IStorageService, StorageScope } from 'vs/platform/storage/common/storage'; import { ITelemetryService } from 'vs/platform/telemetry/common/telemetry'; import { diffInserted, diffInsertedOutline, diffRemoved, diffRemovedOutline, editorFindMatchHighlight, editorFindMatchHighlightBorder, listActiveSelectionForeground } from 'vs/platform/theme/common/colorRegistry';

Related discussion:
text: Previously (September and numerous builds before) I was able to put mouse over X and just click (even without looking) several times to remove unnecessary lines. Now it takes more time/attention to do it with mouse, and if next line after dismissed has longer text - it is easy to open file instead of dismissing it. Open editors view (Close editor button), Source control (action buttons for files), Extensions (Manage button) - have static position of actions that are not changed with sidebar width. My cases are 23" monitor with 1920x1080 and Surface Pro 3. Never had problems when action were on the right side. Users with 4k 30+" will have to snipe for X too.
Yes it was broken for a few months, but this was the behavior from before it was broken I see your point but I will leave this open to think about it
thanks!
Putting the dismiss button to the right would also make it less likley that someone presses it by accident which I just did. The middle of a search result might be just above/below the end of another so that clicking just a bit above/below where you intended could lead you to remove the other search result.
Issue 1) The dismiss buttons are too close to the actual text of the search result making it very easy to accidentally dismiss something. Issue 2) The dismiss buttons are invisible until hover/focus. So if you had your focus on another panel or another window and then click on a search result to focus it, it's too easy to click on an invisible button and accidentally dismiss a search result because of issue 1.
Trying to decide whether we should just always right align... but it seems weird to me to have the X really far away from the row content in some cases. Anyway, if someone wants to add a setting to configure this, I would take that PR.
Code change:
taskPresentationGroup: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.taskPresentationGroup.d.ts', terminalDataWriteEvent: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.terminalDataWriteEvent.d.ts', terminalDimensions: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.terminalDimensions.d.ts', <ins> terminalDisablePersistence: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.terminalDisablePersistence.d.ts', </ins> terminalNameChangeEvent: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.terminalNameChangeEvent.d.ts', testCoverage: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.testCoverage.d.ts', testObserver: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.testObserver.d.ts',

Related discussion:
text: Currently we enable the persistent terminal/reconnect feature if a terminal is launched by an extension, unlike the env var relaunch where we disable outright because it can cause issues with the extension as it loses access to the terminal upon relaunch. Relaunching the PowerShell extension right now for example is a bit of a weird experience though because it creates the "PowerShell Integrated Console", and that reconnects upon reload but is no longer managed by the extension. Before reload: ! After reload it is restored, but no longer owned by the extension: ! Assigning to March for exploration. Thoughts
I think just allowing opt-out/opt-in on this behavior would be more than enough for PowerShell's case.
Has there been any progress on this? Now that persistent terminals are the default, this gets quite annoying and bothers users when extension-owned terminals come back but aren't actually connected.
No progress, we'll try get it in the next version
proposal:
Is this still ongoing and targeted for February?
Yes it is
Code change:
import { CancellationToken } from 'vs/base/common/cancellation'; import { IQuickPickItem, IPickOptions, IInputOptions, IQuickNavigateConfiguration, IQuickPick, IQuickInputButton, IInputBox, QuickPickInput } from 'vs/base/parts/quickinput/common/quickInput'; <del> export { IQuickPickItem, IPickOptions, IInputOptions, IQuickNavigateConfiguration, IQuickPick, IQuickInput, IQuickInputButton, IInputBox, IQuickPickItemButtonEvent, QuickPickInput, IQuickPickSeparator, IKeyMods } from 'vs/base/parts/quickinput/common/quickInput'; </del> <ins> export * from 'vs/base/parts/quickinput/common/quickInput'; </ins> export const IQuickInputService = createDecorator<IQuickInputService>('quickInputService');

Related discussion:
text: It would be nice to invoke current line codelens actions without moving hands of from keyboard to mouse. It could be done via context ctrl+. where codelens actions are or from ctrl+p, or even new shortcut key which opens context menu which contains only codelens actions. They are sometimes available if extension implements them that way that they are to menus/context etc but this probably could be handled more generic way in vscode itself?
Hi! I just opened a PR with the ability to trigger codelenses with the keyboard. Hope you find this helpful as I do :D I appreciate any suggestions and comments from people coming to this issue
Code change:
import { stripIcons } from 'vs/base/common/iconLabels'; import { defaultButtonStyles, defaultCheckboxStyles, defaultDialogStyles, defaultInputBoxStyles } from 'vs/platform/theme/browser/defaultStyles'; import { ResultKind } from 'vs/platform/keybinding/common/keybindingResolver'; <ins> import { IUserActivityService } from 'vs/workbench/services/userActivity/common/userActivityService'; </ins> export class ProgressService extends Disposable implements IProgressService {

Related discussion:
text: Testing Add a git pre-commit hook that sleeps for 120 seconds Make a change to a file, and commit the change Switch to another VS Code window Expected behaviour: Window should be active while the source control operation running Actual behaviour: Window becomes inactive even though the source control operation is still running
Can this be adopted in SCM? Holding an activity lock is fairly easy, just call this method
these commands are being contributed by the git extension. Should be wired into the so that in case there is an on-going progress indicator the window is considered active?
Yea, I think that's reasonable, thanks for the suggestion. Will take care of it