jiebi/CodeConvo huggingface dataset:
Change:
this._onGroupFocusChanged = new Emitter<void>(); <del> this.toDispose = []; </del> <ins> this.onStacksChangeScheduler = new RunOnceScheduler(() => this.handleStacksChanged(), 0); this.toDispose.push(this.onStacksChangeScheduler); this.stacksChangedBuffer = []; </ins> this.create(this.parent); this.registerListeners();

Discussion:
For: scoped keybinding service scoped progress service For the title area and the editor itself. This requires a common parent (or the editor-container itself) to be reparented instead of the editor moving around. Enables more scenarios around menu and command contributions for contexts.
I merged this to master: title container, editor container, progress bar widget and the instantiation service are now within a new container that gets reparented when a) you move an editor around or b) you close editor group LEFT when LEFT | RIGHT exist and RIGHT becomes LEFT as well as for when you have 3 editors open and you close the left or center group. Is there a way to verify this works for the scenario you disabled late before we finished June milestone? I remember you reverted a commit and I am not sure if this can be now reverted back again. !
I can verify
LGTM - will push the revert revert commit
Verified via
Change:
import { CommentContextKeys } from 'vs/workbench/contrib/comments/common/commentContextKeys'; import { ICommentThreadWidget } from 'vs/workbench/contrib/comments/common/commentThreadWidget'; import { ICellRange } from 'vs/workbench/contrib/notebook/common/notebookRange'; <del> import { LayoutableEditor, STARTING_EDITOR_HEIGHT, SimpleCommentEditor, calculateEditorHeight } from './simpleCommentEditor'; </del> <ins> import { LayoutableEditor, MIN_EDITOR_HEIGHT, SimpleCommentEditor, calculateEditorHeight } from './simpleCommentEditor'; </ins> const COMMENT_SCHEME = 'comment'; let INMEM_MODEL_ID = 0;

Discussion:
window a comment :bug: as you can see from the scrollbar, the comment text doesn't fill the full editor !
<!-- UNABLETOLOCATECOMMITMESSAGE issue --Issue marked as unreleased but unable to locate closing commit in issue timeline. You can manually reference a commit by commenting , or directly add the label if you know this has already been releaased
closedWith
Change:
import { CancellationTokenSource } from 'vs/base/common/cancellation'; import { generateUuid } from 'vs/base/common/uuid'; import { ISerializableEnvironmentVariableCollection } from 'vs/workbench/contrib/terminal/common/environmentVariable'; <del> import { IProcessReadyEvent, IShellLaunchConfigDto, ITerminalChildProcess, ITerminalDimensionsOverride, ITerminalLaunchError, ITerminalProfile, TerminalShellType } from 'vs/platform/terminal/common/terminal'; </del> <ins> import { IProcessReadyEvent, IShellLaunchConfigDto, ITerminalChildProcess, ITerminalDimensionsOverride, ITerminalLaunchError, ITerminalProfile, TerminalIcon, TerminalShellType } from 'vs/platform/terminal/common/terminal'; </ins> import { TerminalDataBufferer } from 'vs/platform/terminal/common/terminalDataBuffering'; import { ThemeIcon } from 'vs/platform/theme/common/themeService'; import { withNullAsUndefined } from 'vs/base/common/types';

Discussion:
Testing Ran into this verifying a different issue, the API says that ThemeIcons are assignable in the TerminalOptions but they are not !
Change:
protected override async runAction(action: IAction): Promise<void> { try { <del> // Check if toolbar is disabled if (this.contextKeyService.getContextKeyValue(SCMInputContextKeys.ActionIsEnabled.key) === false) { return; } </del> // Cancel previous action if (this._ctxIsActionRunning.get() === true) { this._cts?.cancel();

Discussion:
a change to a file the file another view so that the SCM view isn't visible the window sparkle will be disabled when you open the SCM view
nice catch! Thank you!
Change:
import { IntervalCounter } from 'vs/base/common/async'; import { assertIsDefined } from 'vs/base/common/types'; import { NotificationsToastsVisibleContext } from 'vs/workbench/common/contextkeys'; <del> import { IKeybindingService } from 'vs/platform/keybinding/common/keybinding'; import { IConfigurationService } from 'vs/platform/configuration/common/configuration'; </del> interface INotificationToast { readonly item: INotificationViewItem;

Discussion:
Testing Repro: some notifications and focus one. You should hear a hint about opening the notification in the accessible view. !
Oh, this is because it's not focused. I found this a little confusing as the info message doesn't say it's a notification or anything so how would a new user know how to answer the question?
I'm still hitting this sometimes when the notification is focused as well No verbosity settings are set here: !
When this happens alt+f2 doesn't work It might be something off with context keys?
Proof: !
I was also going to report this - I triggered this notification and selected it to focus it, but I didn't get a hint: !
I have occasionally found that this does not work when I have the screen reader text view open. Can you try with that closed and speech on / volume up?
Is that the speech viewer / text box shows in his screenshots? I didn't have that open in my flow afaik.
I need to add to the aria label - currently, it's just to the free floating notification element
It's better now, but the hint still doesn't show up if the notification appears and the user tabs to it. The hint shows up if the user tabs to the button, but then Alt+F2 doesn't work while the user is on the button. Good: the screen reader optimized button. the notification. the show notification command. is properly displayed. Bad notifications from the notifications center. the screen reader optimized button. tab until the focus is on the notification. Enable tab moves focus mode if needed. :bug: The hint doesn't show up, and pressing Alt+F2 doesn't work. tab until the focus is on the Yes button. :bug: The hint shows up, but pressing Alt+F2 doesn't work. Let me know if you're able to reproduce the issue and whether it's worth reopening.
Thanks I'll probably wait to see if this is an issue screen reader users encounter.
Change:
constructor( @IInstantiationService private readonly _instantiationService: IInstantiationService, @IContextViewService private readonly _contextViewService: IContextViewService, <del> @IContextMenuService contextMenuService: IContextMenuService </del> <ins> @IContextMenuService contextMenuService: IContextMenuService, @IKeybindingService private readonly _keybindingService: IKeybindingService </ins> ) { contextMenuService.onDidShowContextMenu(() => this.hideHover()); }

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.70.1 OS Version: Windows_NT x64 10.0. From some versions until now, I noticed that the copy and paste behavior of the TreeView component's markdown tooltips stopped working. Simply when I click on CTRL the tooltip disappears, and does not perform the action. In the GIF below you can also see issue occurring sporadically when hovering over the item. !
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.70.2. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Yes, problem persists in 1.70.2.
does this ring any bells, or should I investigate?
This seems to be a regression. Adding to this iteration, if you have any time to look into this it would be appreciated as I'll be pretty busy this week.
thanks for fix!
Verified on mac - not sure if this was windows specific
The issue was not Windows specific, verifying on mac is good.
Change:
} private _shouldShowCurrentLine(): boolean { <del> return this._renderLineHighlight && this._selectionIsEmpty && this._primaryCursorIsInEditableRange && !this._readOnly; </del> <ins> return this._renderLineHighlight && this._selectionIsEmpty && this._primaryCursorIsInEditableRange; </ins> } }

Discussion:
VSCode Version: 1.6.1 OS Version: macOS The editor component of VSCode does not highlight/outline the currently selected line when in read-only mode. The ability to highlight lines in read only mode is useful for a variety of reasons. For example in we use this to bring attention to specific lines when the UI navigates the user to a new cursor position after a jump-to-definition. Steps to Reproduce: You can reproduce this within the Monaco playground the and instantiate a new read only editor. E.g. on the editor to set the cursor position. The line containing the selected position is not outlined. Remove the read only flag and observe the difference in behavior.
Change:
constructor(options: string[], selected: number, contextViewProvider: IContextViewProvider, styles: ISelectBoxStyles) { this.toDispose = []; <ins> this._isVisible = false; </ins> this.selectElement = document.createElement('select'); this.selectElement.className = 'select-box';

Discussion:
VSCode Version: Code - Insiders 1.20.0-insider (, 2017-12-19T07:32:34.862Z) OS Version: Windows_NT x64 10.0. Extensions: none Steps to Reproduce: Debug panel the top SelectBox [SelectBox expands] again at the same spot Expected result: SelectBox closes. Actual result: It stays expanded. It affects SelectBox on Debug and Output panels. Terminal panel SelectBox closes as expected.
thanks for the nice bug report, forwarding to fyi
Thanks, good bug find!
Fixed With:
thanks. the verified label should not be until our endgame where we verify all the bugs we had during a milestone. I will remove it so that we can have someone else verify the bug.
Thanks
Change:
this._store.add(this._widget); this._widget.render(this._inputContainer); this._widget.setModel(this._defaultChatModel, {}); <del> this._store.add(this._widget.inputEditor.onDidContentSizeChange(() => _editor.layoutContentWidget(this))); </del> <ins> this._store.add(this._widget.onDidChangeContentHeight(() => _editor.layoutContentWidget(this))); </ins> this._domNode.tabIndex = -1; this._domNode.className = 'inline-chat-content-widget interactive-session';

Discussion:
have a squiggle open inline chat for it the UI flickers when coming up
I believe the is the same underlying cause as Drilling into this and it seems that setting follow up always triggers a layout with the "old" dimensions which isn't going fit. I believe that explains why the editor is looking so weirdly. It only gets very little height left IMO setting follow up should only trigger a content heigh change event so that the owner can issue a relayout but should not attempt to relayout with the existing dimensions. (maybe unless the number of follow up has changed in which case the content height didn't change...) <img width="1412" alt="Screenshot 2024-06-18 at 16 47 47" src=""
tried this is a notebook and it felt very jittery still (but in a regular file it was fine) should I create a new issue for this? Seems to be due to the inline fix dialog getting placed in one spot then immediately moved <img width="1273" alt="Screenshot 2024-06-26 at 10 31 06 AM" src=""<img width="938" alt="Screenshot 2024-06-26 at 10 31 01 AM" src=""
Change:
} else { if (options.hideOnHover === undefined) { // When unset, will default to true when it's a string or when it's markdown that <del> // appears to have a link using a naive check for '](' hideOnHover = typeof options.content === 'string' || isMarkdownString(options.content) && !options.content.value.includes(']('); </del> <ins> // appears to have a link using a naive check for '](' and '</a>' hideOnHover = typeof options.content === 'string' || isMarkdownString(options.content) && !options.content.value.includes('](') && !options.content.value.includes('</a>'); </ins> } else { // It's set explicitly hideOnHover = options.hideOnHover;

Discussion:
https://user- problem extension:
I have the same problem in tooltips of TreeItem. I thought it was associated with my extension, but apparently not. This behavior does not happen with the GitLens extension.
This issue only happen to stausBarItem at left side
!
this issue should be mark new release label
can you help look into this issue?
Wasn't this always like this? I just tested and it's not hoverable in 1.78.0 either. You can hold alt to hover it though which is a common feature of hovers (outside the editor)
1.78 is the current VSCode version - the one where it broke. 1.77 and below works properly.
Doh, checking an older one
Looks like the hover only sticks if there are textual links in it. Example is the hover on the next to the language selector. I didn't change anything in the hover area recently.
that's how it used to work, it doesn't anymore. and I made some changes around this recently, it was probably us.
this is by design if the content does not contain any links. Hold alt to "lock" any hover
This is happening because you're using an anchor tag, a change was made recently to only force hovering when the hover contained "](". I'll add an anchor tag check.
Curious, because in these tooltips I never used links (html or md) and it worked. Recently this behavior started This tooltip has always been used by my users to copy information, by simply selecting and CTRL + C
previously the logic would disable hide on hover if it was any markdown string which is why it was like that. If the user wants to copy information they can do so by . I know it's not the most discoverable but it's intuitive once you know about it. It's a harder problem than you might expect because if it didn't behave like this we would get the opposite type of issue where hovers are really annoying because they don't dismiss. So we don't hide hovers on mouse over only when there's a high chance of interaction.
Change:
import { IXtermMarker } from 'vs/platform/terminal/common/capabilities/capabilities'; import { ThemeIcon } from 'vs/base/common/themables'; import { Codicon } from 'vs/base/common/codicons'; <ins> import { alert } from 'vs/base/browser/ui/aria/aria'; import { localize } from 'vs/nls'; </ins> const symbolMap: { [key: string]: string } = { 'Ampersand': '&',

Discussion:
Sighted users see preview text as a voice recording occurs and they see the resultant output, which could be drastically different from what they might expect. To make this clear for SR users, after the recording has stopped, we should alert with the content that was inserted in at least the terminal. Unclear if this would also be desirable to do in the chat input boxes
Do you move over to using braille when using the speech functionality Otherwise, doesn't the mic pick up on what the screen reader is saying?

It seems that the mic icon requires at least one line above the prompt to show: ! It does not appear for me in the above case.
Thanks for the issue. Should be an easy fix and in this case the mic will have to go on the cursor line
Change:
private _pendingEditsCache: { [key: string]: { [key: string]: { [key: number]: string } } }; // owner -> threadId -> uniqueIdInThread -> pending comment private _editorDisposables: IDisposable[] = []; private _activeCursorHasCommentingRange: IContextKey<boolean>; <ins> private _hasProvidedAriaStatus: boolean = false; </ins> constructor( editor: ICodeEditor,

Discussion:
[x] Indicate when a document has commentable ranges Aria status when a document is opened [x] Add keyboard shortcut for adding a comment [x] Provide commands to go to next and previous commentable range [x] Add an accessible help menu to the comment widget Esc dismisses widget Lists go to next/previous commentable range commands + keyboard shortcuts Lists command and keyboard shortcut to add a comment Lists keyboard shortcut to execute the comment primary action and what the primary action is [x] The Comments view should respect the enter/space = reveal+focus/reveal [x] Make the comment widget toolbar always visible when in screen reader mode
Related to
is the last part of this, and it's almost done!
Mr.KITSANAPAN MEEKEAW
Change:
import { Disposable } from 'vs/base/common/lifecycle'; import { ContentWidgetPositionPreference, ICodeEditor, IContentWidget } from 'vs/editor/browser/editorBrowser'; import { KeyCode } from 'vs/base/common/keyCodes'; <ins> import { localize } from 'vs/nls'; import { IAccessibilityService } from 'vs/platform/accessibility/common/accessibility'; </ins> export class SlashCommandContentWidget extends Disposable implements IContentWidget { private _domNode = document.createElement('div'); private _lastSlashCommandText: string | undefined; <del> constructor(private _editor: ICodeEditor) { </del> <ins> constructor(private _editor: ICodeEditor, private _accessibilityService: IAccessibilityService) { </ins> super(); this._domNode.toggleAttribute('hidden', true);

Discussion:
on a screen reader on Windows (JAWS/NVDA) in the chat view backspace hear "space' said this is typical of a screen reader. We discussed using an audio cue to indicate deletion. We have concluded it would be better and simpler to just disable this feature for screen reader users. !
-- After this meeting, something came to mind. What if I love the current command deletion behavior and would like to keep it? would you like to add a user setting to toggle this behavior for some advanced users?
We try to add settings sparingly because we want the default experience to be very nice. I will leave this with to decide. We could keep this behavior and mention it in the chat's accessibility help menu so a screen reader user is aware of what's happening.
do you personally anticipate that you would use this setting to preserve the command deletion behavior? Do you know why the screenreader reads 'space' on a deletion? If we can avoid that, would it be more reasonable that hitting backspace results in the screenreader announcing 'exiting mode'?
JooYoung and I discussed that approach and agreed it would be too verbose. We should either use an audio cue, disable the feature, or provide a setting.
Or mention it in the chat's accessibility help?
After thinking about this issue for a day, I think we can add an alert "input cleared" when the command is entirely deleted. I found that character-by-character deletion works after when you move your cursor to the left.
This is great
Change:
import { CancellationToken, CancellationTokenSource } from 'vs/base/common/cancellation'; import { KeyCode } from 'vs/base/common/keyCodes'; import * as lifecycle from 'vs/base/common/lifecycle'; <ins> import { clamp } from 'vs/base/common/numbers'; </ins> import { isMacintosh } from 'vs/base/common/platform'; import { ScrollbarVisibility } from 'vs/base/common/scrollable'; import { ContentWidgetPositionPreference, ICodeEditor, IContentWidget, IContentWidgetPosition } from 'vs/editor/browser/editorBrowser'; import { ConfigurationChangedEvent, EditorOption } from 'vs/editor/common/config/editorOptions'; <ins> import { IDimension } from 'vs/editor/common/core/dimension'; </ins> import { Position } from 'vs/editor/common/core/position'; import { Range } from 'vs/editor/common/core/range'; import { ModelDecorationOptions } from 'vs/editor/common/model/textModel';

Discussion:
an object that has many long property values There is no scrollbar the prototype There is a scrollbar !
Probably only with the horizontalscrolling setting enabled? I know that's a bit tricky
What's the setting for that? I don't have any scroll setting that appears debug related enabled. Just sticky scroll for the editor.
I think you have set, right?
No I do not.
Change:
"category": "Git" }, { <ins> "command": "git.branchFrom", "title": "%command.branchFrom%", "category": "Git" }, { </ins> "command": "git.deleteBranch", "title": "%command.deleteBranch%", "category": "Git"

Discussion:
Similar to the visual-studio feature: Right now the way to do this would be to checkout the remote branch and then create a branch from there !
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.678 --- <!-- score: 0.631 --- <!-- score: 0.585 --- <!-- score: 0.58 --- <!-- score: 0.53 --<!-- potentialduplicatescomment --
The command will show you a list of branches. If you pick a remote branch, it will create a local branch and set it to track the remote one. Isn't that enough?
this would require me to first checkout the remote branch
Please try <kbdF1</kbd, , pick a remote branch and let me know if that doesn't create a local branch.
it does create a local branch. I think I didn't explain the feature request correctly for example: When working on a new feature you create a branch from the remote master into your own local branch you have no need to actually create a local version of the branch. I never create a local branch tracking the remote branch
So, you want to create a branch based off a specific remote branch?
Exactly
I don't see a "Create Branch From" command, what happened to it?
The standard command now asks you where the branch should be created.
hey is there a way to set this branch to be the current branch by default?
What does that mean? When running the command, that branch will be checked out.
Sorry for not being very clear! Right now when I run this command I'm prompted to choose which branch to branch off every time. I quite liked it when the command would use the current branch as the branch to branch off of, without me having to specify it. I can see how the new behaviour is useful, but is there a way to set the old behaviour as the default behaviour, so that I don't have to confirm that I want to branch off the current branch when making a new branch?
The current experience auto selects ... so all you have to do is press <kbdEnter</kbdwhen asked which ref the branch should be created from. That is the equivalent of the old behaviour.
Change:
const size = item.size; <del> if (!this.setRowHeight && item.row) { const newSize = item.row.domNode.offsetHeight; item.size = newSize; </del> <ins> if (item.row) { item.row.domNode.style.height = ''; item.size = item.row.domNode.offsetHeight; </ins> item.lastDynamicHeightWidth = this.renderWidth; <del> return newSize - size; </del> <ins> return item.size - size; </ins> } const row = this.cache.alloc(item.templateId); row.domNode.style.height = ''; this.rowsContainer.appendChild(row.domNode); const renderer = this.renderers.get(item.templateId); <del> if (renderer) { renderer.renderElement(item.element, index, row.templateData, undefined); renderer.disposeElement?.(item.element, index, row.templateData, undefined); </del> <ins> if (!renderer) { throw new BugIndicatingError('Missing renderer for templateId: ' + item.templateId); </ins> } <ins> renderer.renderElement(item.element, index, row.templateData, undefined); </ins> item.size = row.domNode.offsetHeight; <ins> renderer.disposeElement?.(item.element, index, row.templateData, undefined); </ins> this.virtualDelegate.setDynamicHeight?.(item.element, item.size);

Discussion:
Open a text editor and settings editor side by side and resize the sash in between and notice a lot of lag: ! A lot of time spend in : !
Sadly, this is the cost of having dynamic heights. This is why dynamic height is disabled for all lists but is enabled (and actually created for) the settings editor. Will investigate and see if there's low hanging fruit.
Actually, this is the culprit: cc It broke what achieved. That statement was made sure we reused DOM nodes for this computation if they were already in the DOM tree. But that commit broke this for the Settings Editor, making recomputing heights based on wrap a lot more expensive.
Before, each frame takes 60ms: ! After, each frame takes 12ms: !