jiebi/CodeConvo huggingface dataset:
Code change:
import { EventType, addDisposableListener, addStandardDisposableListener, h } from 'vs/base/browser/dom'; import { createFastDomNode } from 'vs/base/browser/fastDomNode'; import { IMouseWheelEvent } from 'vs/base/browser/mouseEvent'; <ins> import { ScrollbarState } from 'vs/base/browser/ui/scrollbar/scrollbarState'; </ins> import { Color } from 'vs/base/common/color'; import { Disposable } from 'vs/base/common/lifecycle'; import { IObservable, autorun, derived, observableFromEvent, observableSignalFromEvent } from 'vs/base/common/observable';

Related discussion:
text: This has been fixed for notebook diffs but is still an issue for text diffs: <img width="115" alt="image" src="https://user-"
Code change:
private provider: IURLCallbackProvider | undefined; constructor( <del> @IWorkbenchEnvironmentService environmentService: IWorkbenchEnvironmentService </del> <ins> @IWorkbenchEnvironmentService environmentService: IWorkbenchEnvironmentService, @IOpenerService openerService: IOpenerService, @IProductService productService: IProductService </ins> ) { super(); this.provider = environmentService.options?.urlCallbackProvider; this.registerListeners(); <ins> const that = this; this._register(openerService.registerOpener({ async open(resource: URI | string) { if (!matchesScheme(resource, productService.urlProtocol)) { return false; } if (typeof resource === 'string') { resource = URI.parse(resource); } return that.open(resource); } })); </ins> } private registerListeners(): void {

Related discussion:
text: Testing scenario in Codespaces web UI Opening a Python file in a fresh codespace Web UI shows a notification: ! Clicking on Yes shows ! VSCode desktop is opened Python calls VSCode should intercept that URI and handle it by directly opening the extensions viewlet and not make an external call
Unassigning myself as it seems url handling related. Please let me know if there is something I have to do in extensions area.
What do you think? Should we perform the fast-track to handle these URIs internally?
I can't repro this in desktop Code. I can repro in web
I couldn't get the Python extension to show that dialog again, so I verified that with my own extension that does That code is inspired by That code works and, on codespaces now directly opens the extension viewlet. -verified However, if you do '();' it opens the external open dialog again. In the first case the URL has a relative path (), in the second one an absolute (). Relative paths are kind of rare. Is that all as designed? Or would it be better to also accept the absolute path?
Paths are not required to be rooted in , or even separated by characters: they can be arbitrary strings within the allowed character set. We've long defined extension URIs to simply be . Not sure if you've seen the format anywhere in our docs? If so we gotta fix it.
I will have to revert the fix for this, since it broke existing functionality. With the fix, a web extension can no longer actually open a URI in desktop Code. When looking at the breakage, I no longer this this is true. If is invoked, it should always be handled externally, never internally, unless it's absolutely obvious (running in Desktop). The right way to move forward here is to have the Python extension run the instead of calling .
Code change:
const sessionId = viewModel.sessionId; const view = await viewService.openView(widget.viewContext.viewId) as ChatViewPane; <ins> const viewState = view.widget.getViewState(); </ins> view.clear(); <del> await editorService.openEditor({ resource: ChatEditorInput.getNewEditorUri(), options: <IChatEditorOptions>{ target: { sessionId }, pinned: true } }, moveTo === MoveToNewLocation.Window ? AUX_WINDOW_GROUP : ACTIVE_GROUP); </del> <ins> await editorService.openEditor({ resource: ChatEditorInput.getNewEditorUri(), options: <IChatEditorOptions>{ target: { sessionId }, pinned: true, viewState: viewState } }, moveTo === MoveToNewLocation.Window ? AUX_WINDOW_GROUP : ACTIVE_GROUP); </ins> } async function moveToSidebar(accessor: ServicesAccessor): Promise<void> {

Related discussion:
text: chat in sidebar something into input Session in Editor :bug: input is cleared
This still repros for me
The input is preserved but the input for the new chat session in the sidebar is not cleared
Code change:
// Always fallback to monospace, otherwise a proportional font may become the default fontFamily += ', monospace'; <ins> // Always fallback to AppleBraille on macOS, otherwise braille will render with filled and // empty circles in all 8 positions, instead of just filled circles // See https://github.com/microsoft/vscode/issues/174521 if (isMacintosh) { fontFamily += ', AppleBraille'; } </ins> const letterSpacing = this._terminalConfigurationService.config.letterSpacing ? Math.max(Math.floor(this._terminalConfigurationService.config.letterSpacing), MINIMUM_LETTER_SPACING) : DEFAULT_LETTER_SPACING; const lineHeight = this._terminalConfigurationService.config.lineHeight ? Math.max(this._terminalConfigurationService.config.lineHeight, 1) : DEFAULT_LINE_HEIGHT;

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 <!-- 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.75.1 OS Version: macOS 12.6 Steps to Reproduce: any CLI utility that displays a loader animation that uses braille, such as every step of the animation, you should see an array of dots that don't use up a full square space, but leave some blank space and look like a "snake" (this works fine in Windows) This is how it looks in other terminals such as iTerm2 or <img width="33" alt="image" src="https://user-"This is how it looks in VS Code (i've tried changing fonts, it doesn't help) <img width="31" alt="image" src="https://user-"This is the character: On Windows version of VS Code, this behaves correctly on macOS, instead of white space it shows circles with transparent filling
any news?
Hello, it's been half a year and it's been tagged many things, I'd love to know if this is being taked into consideration since it's very bad UX
Interesting that this works on windows but not mac.... This issue reproduces in the monaco editor
it looks like for we are using the python3.9 spinners
I found this - have you tried other fonts?
i found out that it's Chromium's fault, the issue happens in Chrome for macOS and every other child browser, but doesn't happen in Firefox nor Safari, so I opened a bug report there
Looking at it appears that whatever font is being fallen back to is adding the empty circles?
Code change:
// Always fallback to monospace, otherwise a proportional font may become the default fontFamily += ', monospace'; <ins> // Always fallback to AppleBraille on macOS, otherwise braille will render with filled and // empty circles in all 8 positions, instead of just filled circles // See https://github.com/microsoft/vscode/issues/174521 if (isMacintosh) { fontFamily += ', AppleBraille'; } </ins> const letterSpacing = this._terminalConfigurationService.config.letterSpacing ? Math.max(Math.floor(this._terminalConfigurationService.config.letterSpacing), MINIMUM_LETTER_SPACING) : DEFAULT_LETTER_SPACING; const lineHeight = this._terminalConfigurationService.config.lineHeight ? Math.max(this._terminalConfigurationService.config.lineHeight, 1) : DEFAULT_LINE_HEIGHT;

Related discussion:
text: If that's the case the fix here would be one of: Try falling back to something like in the font family setting, eg. Support custom glyph rendering for those characters, I really would rather not supporting this unless we absolutely had to though.
This bug is still present in Version: 1.84.2/macOS 14. I tried using Symbola, SF Mono, Menlo and Monaco as the main fonts, without success.
I double checked today and it looks like Chrome Version 127.0.6533.89 renders Braille characters without hollow circles on MacOS. <img width="952" alt="Screenshot 2024-08-02 at 10 50 29" src=""(I have a macOS app that's rendering the top bar differently)
So... I spent a bit too long today investigating what was happening here and here's how I've resolved this issue for myself: Before / After <img width="163" alt="Screenshot 2024-08-07 at 22 22 32" src=""<img width="163" alt="Screenshot 2024-08-07 at 22 22 42" src=""In case the diagnostic steps are useful to someone, here's the portion of my search tree that resulted in this solution / bodge.... I looked through my macOS font book for which fonts were providing symbols for (U+2879) and ended up finding "Apple Braille" and "Apple Symbols". "Apple Symbols" had the wrong amount of whitespace when I set that as the fallback font and the "Apple Braille" looked like a drop-in replacement. Turns out, Apple Braille looked different in the OS's Font Book vs in VS Code. The reason for this ended up being that Apple Braille has multiple variants and... for some reason... the version of Chromium being used in VS Code uses either Outline6Dot or Outline8Dot variants by default (these have the hollow/outline circles) instead of the Regular variant which does not have hollow circles. I assume this has to do with the font-renderer-level behaviour. None the less, the of the specific font variant within the "Apple Braille" family that I want to use was "AppleBraille" and adding that to the stack makes it use the correct-for-me variant of the OS-provided Braille symbols!
Code change:
// Always fallback to monospace, otherwise a proportional font may become the default fontFamily += ', monospace'; <ins> // Always fallback to AppleBraille on macOS, otherwise braille will render with filled and // empty circles in all 8 positions, instead of just filled circles // See https://github.com/microsoft/vscode/issues/174521 if (isMacintosh) { fontFamily += ', AppleBraille'; } </ins> const letterSpacing = this._terminalConfigurationService.config.letterSpacing ? Math.max(Math.floor(this._terminalConfigurationService.config.letterSpacing), MINIMUM_LETTER_SPACING) : DEFAULT_LETTER_SPACING; const lineHeight = this._terminalConfigurationService.config.lineHeight ? Math.max(this._terminalConfigurationService.config.lineHeight, 1) : DEFAULT_LINE_HEIGHT;

Related discussion:
text: Alternatively, you can also do what I did recently and change to a font that includes braille characters (like ).
I considered creating an issue for this for the editor as well, but the visualize progress isn't as important there and it's more possible people may want the filled/empty circle rendering in the editor to more easily identify which circles are filled.
This failed the macOS build when merged:
Code change:
// on the onDidHide event. picker.show(); <del> // If the previous picker had a selection, we should set that in the new picker. if (visibleSelection) { picker.valueSelection = visibleSelection; } </del> // Pick mode: return with promise if (pick) { return pickPromise?.p;

Related discussion:
text: open normal quick pick () type notice you want symbol search and select the cursor is random, within the word, and doesn't select the previous input anymore
Code change:
import { Action2, IAction2Options, registerAction2 } from 'vs/platform/actions/common/actions'; import { ServicesAccessor } from 'vs/editor/browser/editorExtensions'; import { localize } from 'vs/nls'; <del> import { IEditSessionsWorkbenchService, Change, ChangeType, Folder, EditSession, FileType, EDIT_SESSION_SYNC_CATEGORY, EDIT_SESSIONS_CONTAINER_ID, EditSessionSchemaVersion, IEditSessionsLogService, EDIT_SESSIONS_VIEW_ICON, EDIT_SESSIONS_TITLE, EDIT_SESSIONS_SCHEME } from 'vs/workbench/contrib/editSessions/common/editSessions'; </del> <ins> import { IEditSessionsWorkbenchService, Change, ChangeType, Folder, EditSession, FileType, EDIT_SESSION_SYNC_CATEGORY, EDIT_SESSIONS_CONTAINER_ID, EditSessionSchemaVersion, IEditSessionsLogService, EDIT_SESSIONS_VIEW_ICON, EDIT_SESSIONS_TITLE, EDIT_SESSIONS_SCHEME, EDIT_SESSIONS_SHOW_VIEW, EDIT_SESSIONS_SIGNED_IN } from 'vs/workbench/contrib/editSessions/common/editSessions'; </ins> import { ISCMRepository, ISCMService } from 'vs/workbench/contrib/scm/common/scm'; import { IFileService } from 'vs/platform/files/common/files'; import { IWorkspaceContextService } from 'vs/platform/workspace/common/workspace';

Related discussion:
text: fyi
Verification: opt into edit sessions using , then ensure the edit sessions view does not appear in the sidebar until you run the Show Edit Sessions action in the command palette.
Code change:
DOM.addStandardDisposableListener(inputBox.inputElement, DOM.EventType.KEY_DOWN, (e: IKeyboardEvent) => { if (e.equals(KeyCode.Enter)) { if (inputBox.validate()) { <del> done(true, true); </del> <ins> done(true); </ins> } } else if (e.equals(KeyCode.Escape)) { <del> done(false, true); </del> <ins> done(false); </ins> } }), blurDisposable,

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.34.0 OS Version: Windows 10 Steps to Reproduce: terminal any command that makes any change of your current project directory after a while, like 'New Folder' action refreshing directory by the terminal command, 'New Folder' input will disappear and File Explorer remains inactive <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes !
Code change:
constructor(private _trait: string) { } splice(start: number, deleteCount: number, elements: boolean[]): void { <del> deleteCount = Math.max(0, Math.min(deleteCount, this.length - start)); </del> const diff = elements.length - deleteCount; const end = start + deleteCount; const sortedIndexes: number[] = [];

Related discussion:
text: Type: <bBug</bWhen pressing to collapse all nodes in a list view it leaves selection in such a state that you cannot expand nodes with until you do something to change the selection. ! I believe what's happening is is leaving the originally selected node selected. So after executing the command you end up with 2 selections, your original selection plus the last root node in the list. The original selection is the primary selection, and if it has no children does not have anything to expand and is a no-op. As a user it looks like you have the root node selected, which has children to expand, but pressing does nothing. Pressing then expands the list to reveal your original selection and you see that you unexpectedly have multiple selections. The current behavior of appears to be: Leave the originally selected node selected Add a second selection to the last root node in the list The expected behavior here is: Move selection to the root node of your currently selected node Ideally this also retains multiple selection: each selection is moved to the root node of that selection. 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 --
Looking at this again in the File Explorer it looks like the selection highlight is left on the where the original selection was despite the fact that the node is now in a different position. However, the "real" selection is still on the node. This means it looks like one thing is highlighted and pressing opens a different thing.
Just submitted a PR for this. Could you please review it?
What is the behavior supposed to be? Here's what I see: keyboard to focus a tree node that has a parent to collapse all moves to the whole tree and arrow down takes me to the first tree element. Right arrow does nothing.
The current behavior sort-of fixes the issue, insofar as is dodges it by doing something less desirable - moves selection to the whole tree. Imo, selection should remain on the root node(s) of whichever tree branch selection is currently in.
Code change:
constructor(private _trait: string) { } splice(start: number, deleteCount: number, elements: boolean[]): void { <del> deleteCount = Math.max(0, Math.min(deleteCount, this.length - start)); </del> const diff = elements.length - deleteCount; const end = start + deleteCount; const sortedIndexes: number[] = [];

Related discussion:
text: I think this is what the previous behavior was trying to do, it just had an issue with leaving selection in a bad state. A couple examples ([x] denotes current selection): Start state End state, after Stat state End state
I agree, feel free to send an issue for it. Your observations are the fixed state. Here's the entire story: Marking it as verified.
Code change:
constructor(private _trait: string) { } splice(start: number, deleteCount: number, elements: boolean[]): void { <del> deleteCount = Math.max(0, Math.min(deleteCount, this.length - start)); </del> const diff = elements.length - deleteCount; const end = start + deleteCount; const sortedIndexes: number[] = [];

Related discussion:
text: Testing focus on trusted URI list of items tab to navigate to the X to remove an item. Press to trigger removal nicely gets removed from the list, however focus is lost Focus should be preserved in the list on the neighbour item (example: checkout how Explorer does that when deleting a file). I thought this would be tackled via
The trust editor does a lot of full page re-rendering which I should improve (remove) so I doubt this is an issue with the table widget itself.
Code change:
public removeManualRanges(ranges: ILineRange[]) { const newFoldingRanges: FoldRange[] = new Array(); <del> const containedBy = (foldRange: FoldRange) => { </del> <ins> const intersects = (foldRange: FoldRange) => { </ins> for (const range of ranges) { <del> if (range.startLineNumber <= foldRange.startLineNumber && range.endLineNumber >= foldRange.endLineNumber) { </del> <ins> if (!(range.startLineNumber > foldRange.endLineNumber || foldRange.startLineNumber > range.endLineNumber)) { </ins> return true; } }

Related discussion:
text: Remove Manual Folding Range doesn't work Originally posted by in select a range in the editor invoke . Selection turns into a folding range put the cursor at the beginning of the collapsed line invoke . Should remove the manual folding range
It works when the cursor is at the second column or to the right of that, but not when it's right at the beginning of the line, which is exactly where it is placed after running the create manual folding range command.
Code change:
return pattern.toUpperCase(); } else if (matches[0].toLowerCase() === matches[0]) { return pattern.toLowerCase(); <del> } else if (strings.containsUppercaseCharacter(matches[0][0])) { </del> <ins> } else if (strings.containsUppercaseCharacter(matches[0][0]) && pattern.length > 0) { </ins> return pattern[0].toUpperCase() + pattern.substr(1); } else { // we don't understand its pattern yet.

Related discussion:
text: VSCode Version: 1.37.1 OS Version: Linux x64 5.1.14--generic Steps to Reproduce: a search term (make sure it actually exists in the current document) the replace term empty the match case box Ctrl-Alt-T the error ! Does this issue occur when all extensions are disabled?: Yes
What does do here? I don't think I have that keybinding.
I think I meant Ctrl+Alt+Enter, the shortcut for replacing all. I am not sure if it is the correct shortcut (I don't have access to my laptop right now), but it is not specific to it. I am guessing replace or replace all will trigger the same bug.
I can't reproduce it. It would help if you can try it again and get the full error stack from the developer tools (Help Toggle Developer Tools)
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
Code change:
} /** <del> * The potential context information for a {@link TextSearchResultNew}. </del> <ins> * The context lines of text that are not a part of a match, * but that surround a match line of type {@link TextSearchMatchNew}. * * For example, consider this excerpt: * * ```ts * const bar = 1; * console.log(bar); * const foo = bar; * ``` * * If the query is `log`, then the lines `const bar = 1;` and `const foo = bar;` * should be represented using two separate {@link TextSearchContextNew} for the search instance. * This example assumes that the finder requests one line of surrounding context. </ins> */ export class TextSearchContextNew { /**

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:
} /** <del> * The potential context information for a {@link TextSearchResultNew}. </del> <ins> * The context lines of text that are not a part of a match, * but that surround a match line of type {@link TextSearchMatchNew}. * * For example, consider this excerpt: * * ```ts * const bar = 1; * console.log(bar); * const foo = bar; * ``` * * If the query is `log`, then the lines `const bar = 1;` and `const foo = bar;` * should be represented using two separate {@link TextSearchContextNew} for the search instance. * This example assumes that the finder requests one line of surrounding context. </ins> */ export class TextSearchContextNew { /**

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.