jiebi/CodeConvo huggingface dataset:
Code change:
.search-view .monaco-tree .monaco-tree-row:hover:not(.highlighted) .monaco-action-bar, .search-view .monaco-tree .monaco-tree-row.focused .monaco-action-bar { <del> display: inline-block; } .search-view:not(.wide) .monaco-tree .monaco-tree-row .linematch .actionBarContainer { flex: 1; </del> <ins> display: block; </ins> } .search-view:not(.wide) .monaco-tree .monaco-tree-row .monaco-action-bar { <del> float: right; </del> <ins> flex: 1 0 auto; </ins> } .search-view .monaco-tree .monaco-tree-row .monaco-action-bar .action-label {

Related discussion:
text: <!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.29-insider OS Version: Windows 10 Version 1809 (OS Build .1000) Steps to Reproduce: Find in files and search for something that will return results over different result lines Badge and Action button (Dismiss) are on the left (aligned to the end of result text) I'm expecting that Dismiss action will have fixed horizontal position (on the right side) that will allow me to easily dismiss several results entries. With current position at the end of result text I have to constantly move mouse to hit Dismiss button. In stable version both count badge (for file) and Dismiss action were aligned at the right side of the viewlet which was convenient. At this moment it is hard to filter out result entries because texts have different length and button shifts for each line. I've found which says that button should always stay on the right side, however this isn't case in v1.28.2 independently from viewlet width (both badge and actions are on the right side). <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <details<summaryScreenshot</summary<div! </div</details
I guess this only applies to the search panel?
Yes, I observe issue in Search panel. UPD. Checked - same behavior when Search: Location is set to sidebar.
You should see the actions on the right when search is narrow, and on the left when it's somewhat wide. The reason is that when the actions are on the right and the text is aligned to the left, it can be hard to associate the two, so it seems more user-friendly to put the actions closer to the actual result. Maybe the threshold could be tweaked, but it doesn't feel good to click an action on the opposite side of the monitor from the actual text. Does this match what you see?
Yes, that match what I see, but makes it harder to use Dismiss action with mouse. For badge with results count - it is good position, since it is visible without hover. On the other hands actions are only visible on hover, when background can clearly indicate what line will be dismissed.
Code change:
.search-view .monaco-tree .monaco-tree-row:hover:not(.highlighted) .monaco-action-bar, .search-view .monaco-tree .monaco-tree-row.focused .monaco-action-bar { <del> display: inline-block; } .search-view:not(.wide) .monaco-tree .monaco-tree-row .linematch .actionBarContainer { flex: 1; </del> <ins> display: block; </ins> } .search-view:not(.wide) .monaco-tree .monaco-tree-row .monaco-action-bar { <del> float: right; </del> <ins> flex: 1 0 auto; </ins> } .search-view .monaco-tree .monaco-tree-row .monaco-action-bar .action-label {

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:
* Provide results that match the given text pattern. * @param query The parameters for this query. * @param options A set of options to consider while searching. <del> * @param progress A progress callback that must be invoked for all results. </del> <ins> * @param progress A progress callback that must be invoked for all {@link TextSearchResultNew results}. * These results can be direct matches, or context that surrounds matches. </ins> * @param token A cancellation token. */ provideTextSearchResults(query: TextSearchQueryNew, options: TextSearchProviderOptions, progress: Progress<TextSearchResultNew>, token: CancellationToken): ProviderResult<TextSearchCompleteNew>;

Related discussion:
text: Testing I can see that the of can be . When should I expect each of these types? I'm not sure I understand what the purpose of is.
is like the surrounding context lines that you see in the search editor. ! For example, here, lines 1791 and 1793 are context lines because they come directly before and after line 1792. I can try to explain this better in the docs, though!
Code change:
* Provide results that match the given text pattern. * @param query The parameters for this query. * @param options A set of options to consider while searching. <del> * @param progress A progress callback that must be invoked for all results. </del> <ins> * @param progress A progress callback that must be invoked for all {@link TextSearchResultNew results}. * These results can be direct matches, or context that surrounds matches. </ins> * @param token A cancellation token. */ provideTextSearchResults(query: TextSearchQueryNew, options: TextSearchProviderOptions, progress: Progress<TextSearchResultNew>, token: CancellationToken): ProviderResult<TextSearchCompleteNew>;

Related discussion:
text: Testing From the API: What is the behavior supposed to be in the following cases: The pattern contains . The pattern contains and is false. The pattern is a regex and is false. The pattern contains whitespace and is true.
If regex is not on, it just looks for literally. I believe that this actually acts as if is true (if I'm interpreting code correctly). Any time that you have regex enabled and explicitly match a newline, it will be multi-line. I should probably document this. Any characters in the regex will also match the other case. ie: should also match all characters, not just lowercase letters. It will look for the whitespace, and will look for line boundaries on either side of the search string.
I can also add extra examples for corner cases so that this is more clear.
Code change:
const replace = DOM.append(parent, DOM.$('span.replaceMatch')); const after = DOM.append(parent, DOM.$('span')); const lineNumber = DOM.append(container, DOM.$('span.matchLineNum')); <del> const actionBarContainer = DOM.append(container, DOM.$('span.actionBarContainer')); const actions = new ActionBar(actionBarContainer, { animated: false }); </del> <ins> const actions = new ActionBar(container, { animated: false }); </ins> return { parent,

Related discussion:
text: <!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.29-insider OS Version: Windows 10 Version 1809 (OS Build .1000) Steps to Reproduce: Find in files and search for something that will return results over different result lines Badge and Action button (Dismiss) are on the left (aligned to the end of result text) I'm expecting that Dismiss action will have fixed horizontal position (on the right side) that will allow me to easily dismiss several results entries. With current position at the end of result text I have to constantly move mouse to hit Dismiss button. In stable version both count badge (for file) and Dismiss action were aligned at the right side of the viewlet which was convenient. At this moment it is hard to filter out result entries because texts have different length and button shifts for each line. I've found which says that button should always stay on the right side, however this isn't case in v1.28.2 independently from viewlet width (both badge and actions are on the right side). <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <details<summaryScreenshot</summary<div! </div</details
I guess this only applies to the search panel?
Yes, I observe issue in Search panel. UPD. Checked - same behavior when Search: Location is set to sidebar.
You should see the actions on the right when search is narrow, and on the left when it's somewhat wide. The reason is that when the actions are on the right and the text is aligned to the left, it can be hard to associate the two, so it seems more user-friendly to put the actions closer to the actual result. Maybe the threshold could be tweaked, but it doesn't feel good to click an action on the opposite side of the monitor from the actual text. Does this match what you see?
Yes, that match what I see, but makes it harder to use Dismiss action with mouse. For badge with results count - it is good position, since it is visible without hover. On the other hands actions are only visible on hover, when background can clearly indicate what line will be dismissed.
Code change:
const replace = DOM.append(parent, DOM.$('span.replaceMatch')); const after = DOM.append(parent, DOM.$('span')); const lineNumber = DOM.append(container, DOM.$('span.matchLineNum')); <del> const actionBarContainer = DOM.append(container, DOM.$('span.actionBarContainer')); const actions = new ActionBar(actionBarContainer, { animated: false }); </del> <ins> const actions = new ActionBar(container, { animated: false }); </ins> return { parent,

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:
export const INotebookCellOutlineProviderFactory = createDecorator<INotebookCellOutlineProviderFactory>('INotebookCellOutlineProviderFactory'); export interface INotebookCellOutlineProviderFactory { <del> getOrCreate(editor: INotebookEditor, target: OutlineTarget): IReference<NotebookCellOutlineProvider> </del> <ins> getOrCreate(editor: INotebookEditor, target: OutlineTarget): IReference<NotebookCellOutlineProvider>; </ins> } export class NotebookCellOutlineProviderFactory implements INotebookCellOutlineProviderFactory {

Related discussion:
text: Open notebook with a header, code cell, and symbols in the code cell: # 1: symbols appear as a child of the header md cell, and the code cell is not present in the outline. # 2: changing the filter settings to remove code cells or symbols does not recompute the outline. Fixes: For # 1: an outline provider was being created with the incorrect target (sticky scroll was created with a QuickPick target), and this was being retrieved for the outline pane incorrectly. For # 2: one of the locations an outline change event is fired was shifted and subsequently removed, meaning that the outline did not recompute to reflect the filtered-out cells.
Code change:
} function renderText(outputInfo: OutputItem, container: HTMLElement, ctx: RendererContext<void> & { readonly settings: { readonly lineLimit: number } }): void { <ins> clearContainer(container); </ins> const contentNode = document.createElement('div'); contentNode.classList.add('output-plaintext'); const text = outputInfo.text();

Related discussion:
text: Hi ! I am running into an issue issue when using vscode 1.66 : when running pymc models there is a progress bar output which was working fine before the update and now the progress bar simply prints down :( See pic below ! This is how it prints in Jupyter notebooks (anaconda) and it was looking so in vscode 1.65.2 ! Here is the info about my session
Update It actually works when I am not looking ie, I am not in that specific cell of the notebook ¯()/¯ !
Here is a reproducible example: Code: Output: !
I'm having a similar issue using enlighten progressbar. This likely started after a recent vscode update. A new progressbar is printed everytime it updates/redraws. I'm guessing this is the same issue. (This works/prints fine when run using jupyter-notebook on a web browser) !
Thank you for working so fast on this one! Looking forward for the next update/release !
I couldn't verify this fix, using : !
thanks, it's not being picked to the release branch yet.
Works for me too. !
Code change:
for (const panel of this.getPanels()) { this.compositeBar.addComposite(panel, false); } <ins> this.activePanelContextKey = ActivePanelContext.bindTo(contextKeyService); this.onDidPanelOpen(this._onDidPanelOpen, this, this.disposables); this.onDidPanelClose(this._onDidPanelClose, this, this.disposables); </ins> this.registerListeners(); }

Related discussion:
text: I wanted to customize my keybindings depending on the OutputPanel state, but it looks there's no clause to set in the stanza for it.
There is a context , please try that
Ok that works when if focused (but needs to be documented), what about when it's visible?
We accept PRs that update our docs. Checkout the vscode-docs repo. No this is not currently supported, we accept PRs that add this. Code pointers Similar to the viewlet service here The panelPart would add a context key
works but how does a user learn the panel ID?
good point. However we already had that issue with the viewlets, since we already have a "activeViewlet" conext key. We should document this properly
Code change:
import * as nls from 'vs/nls'; import { IDisposable, dispose } from 'vs/base/common/lifecycle'; import Event, { Emitter, chain } from 'vs/base/common/event'; <del> import { KeyCode } from 'vs/base/common/keyCodes'; </del> <ins> import { KeyCode, KeyCodeUtils } from 'vs/base/common/keyCodes'; </ins> import { StandardKeyboardEvent } from 'vs/base/browser/keyboardEvent'; import * as dom from 'vs/base/browser/dom'; import * as arrays from 'vs/base/common/arrays';

Related discussion:
text: Including all who have commented : New SelectBox implementation: Standard native select allows navigation to an item using the first character. This can be done both on a unexpanded or expanded select. Should this behavior be implemented in the new custom SelectBox ?
yeah good catch I think it should. If the control has focus at least. Please do not assign the "candidate" label to issues. It is reserved for issues we plan to fix in a stable recovery release.
though assigning milestones is usualy a good idea, if you plan to fix this until the end of january just assign to December / January milestone.
Noted on the labeling issues (verified, candidate, milestones), sorry don't know all the workflows :-( Sorry to pepper you with a few more questions: I saw you wrote a draft test plan, would you like me to add some more specificity on keyboard support so people know exactly what to look for? If I have small tweaks/cleanup should I create an issue(s) or is using notes in a pull request sufficient? Essentially when is it appropriate Not to do an issue for work in progress? I will fix all issues posted for the December/January milestone assuming they are known in time.
yeah feel free to make tweaks to the test plan item: I also published some release notes on it here: The advantage of having an issue is that it will get verified in the endgame if it is a bug. If the thing you are changing cannot be verified or is not a bug, doing just a PR is fine.
You chose selectBoxCustom for the filename, do you prefer that I re- factor the delegate class and symbols to use custom instead of list?
no I think its fine
Fixed with:
Code change:
private updateEnabled() { const settingEnabled = this.configurationService.getValue(NotebookSetting.cellFailureDiagnostics); <del> if (this.enabled && (!settingEnabled || Iterable.isEmpty(this.inlineChatService.getAllProvider()))) { </del> <ins> if (this.enabled && (!settingEnabled || Iterable.isEmpty(this.chatAgentService.getAgents()))) { </ins> this.enabled = false; this.clearAll(); <del> } else if (!this.enabled && settingEnabled && !Iterable.isEmpty(this.inlineChatService.getAllProvider())) { </del> <ins> } else if (!this.enabled && settingEnabled && !Iterable.isEmpty(this.chatAgentService.getAgents())) { </ins> this.enabled = true; if (!this.listening) { this.listening = true;

Related discussion:
text: There are some parts in notebook land that depend on . This service and its provider are deprecated and should be removed. As of today the following dependencies must be cleaned up first: , , The should be used instead, it will allow you to know if a agent per location exists or not
Code change:
private _usedShellIntegrationInjection: boolean = false; get usedShellIntegrationInjection(): boolean { return this._usedShellIntegrationInjection; } private _lineDataEventAddon: LineDataEventAddon | undefined; <ins> private readonly _scopedContextKeyService: IContextKeyService; </ins> readonly capabilities = new TerminalCapabilityStoreMultiplexer(); readonly statusList: ITerminalStatusList;

Related discussion:
text: Type: <bBug</bPinning a terminal editor does not set some of the context variables that are normally set when pining a text editor. Here are the ones I've noticed: activeEditorIsDirty activeEditorIsFirstInGroup activeEditorIsLastInGroup activeEditorIsNotPreview activeEditorIsPinned In the case of activeEditorIsPinned this makes it impossible to detect if the current terminal editor is pinned. Since there is no command to toggle the pin on an editor this means it's not possible to create a single keybinding that can intelligently pin and unpin the current terminal editor. In the case of activeEditorIsLastInGroup it means it's not possible to create a keybinding to move a terminal editor out of the "pinned section" of editors in the current group. When editors are pinned they are moved to the left side of the current editor group. When moving an editor to the previous position in the current group if it happens to cross into the pinned section it will become pinned. But the inverse is not possible: you cannot move a pinned editor out of the pinned section unless there happens to be something else unpinned to the right of it. So I have a keybinding to unpin the current editor if it's the last editor in the current group. Since terminal editors don't set the required context they break this binding. Steps to Repro: Open a terminal in the editor area Pin the terminal editor Inspect context keys Notice activeEditorIsPinned is not set VS Code version: Code - Insiders 1.76.0-insider (, 2023-02-10T16:22:19.445Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: Yes <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
The type of editor should not play any role in this. I somewhat doubt this is a bug in our code, so setting label that we need confirmation. Open for help, investigation, suggested fixes, PR.
This one I cannot confirm or reproduce. See this gif where I open a terminal, pin it and then inspect the context keys: ! What are some exact steps?
Looks like it depends where you click when inspecting context keys.
Code change:
private _usedShellIntegrationInjection: boolean = false; get usedShellIntegrationInjection(): boolean { return this._usedShellIntegrationInjection; } private _lineDataEventAddon: LineDataEventAddon | undefined; <ins> private readonly _scopedContextKeyService: IContextKeyService; </ins> readonly capabilities = new TerminalCapabilityStoreMultiplexer(); readonly statusList: ITerminalStatusList;

Related discussion:
text: I'm clicking inside the terminal, where my cursor is, because I'm attempting to make keybindings that work when using the terminal. You're clicking the editor tab. So it appears the context is set for the editor, but when you focus the terminal within it that context is removed. Interestingly I still see some of the context so not all of it is removed.
Quite likely that the terminal itself sets its own context keys.
<!-- 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, but while confirming the fix I noticed more issues with these context keys