jiebi/CodeConvo huggingface dataset:
Code change:
this.updateActions(); if (!shouldShowFilterInHeader) { append(this.filterContainer!, this.filterWidget.element); <del> height = height - 44; </del> } } <ins> if (!shouldShowFilterInHeader) { height = height - 44; } </ins> this.filterWidget.layout(width); this.layoutBodyContent(height, width); }

Related discussion:
text: Issue Type: <bBug</bthe integrated console viewlets to a vertical layout the viewlet narrow When wide enough: ! Once narrowed: ! Expected result: Debug Console search bar shrinks/hides itself in order to show other tabs first (like in the first screenshot). The 3 dots "works", but is, at least in my opinion, more annoying than not being able to search in the Debug Console when the viewlet is narrow. VS Code version: Code 1.63.2 (, 2021-12-15T09:40:02.816Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </details<!-- generated by issue reporter --
The min width is 300, I think that can be narrower. The problems view filter input goes into the body when the view is too narrow, which is sorta cool <img width="571" alt="image" src="https://user-"but I won't implement that right now
Actually it was easy to opt into that. I tweaked the min widths and also when the pane is narrow, the filter box will move down into the body
Holy, I forgot about this issue! Love the idea of copying the behaviour of the Problems tab! Excited to try it on Insiders :) Thanks !
Code change:
cursors.setStates( args.source, CursorChangeReason.Explicit, <del> CursorMoveCommands.addCursorUp(context, cursors.getAll()) </del> <ins> CursorMoveCommands.addCursorUp(context, cursors.getAll(), useLogicalLine) </ins> ); cursors.reveal(true, RevealTarget.TopMost, ScrollType.Smooth); } } export class InsertCursorBelow extends EditorAction { constructor() { super({ id: 'editor.action.insertCursorBelow',

Related discussion:
text: VSCode Version: 0.10.11 OS Version: OS X 10.10.5 Steps to Reproduce: a long line of text that wraps in the editor the cursor on the first line and press Cmd-Option-Down (on OS X). This creates a second cursor on the next visual line, which means it is somewhere on the same logical line depending on how the text is wrapped. When creating multiple cursors on adjacent lines, often it is to perform the same edit on multiple (logical) lines that are aligned with each other. The current behavior having the second cursor appear instead at some situation-specific place on the same logical line throws a wrench in this workflow. I can't think of a good situation where it makes sense (though I do realize it is consistent with pressing the down arrow without cmd-option) Definitions: a logical line is a line in the file on disk. A visual line is a line in the editor. A logical line may span multiple visual lines when there is wrapping.
Code change:
bugsUrl: manifest.bugs && manifest.bugs.url, displayName: manifest.displayName, id: extension.identifier.id, <del> isTheme: isTheme </del> <ins> isTheme, isBuiltin, </ins> }; }); const theme = this.themeService.getColorTheme(); const issueReporterData: IssueReporterData = assign({ styles: getIssueReporterStyles(theme), zoomLevel: webFrame.getZoomLevel(), <del> enabledExtensions: extensionData </del> <ins> enabledExtensions: extensionData, </ins> }, dataOverrides); return this.issueService.openReporter(issueReporterData); }

Related discussion:
text: Feature Request The command takes an extension argument so that extensions can open an issue reporter for that extension. I'd like to use this for the built-in JS/TS extension as well but cannot at the moment: It'd be nice if for VS Code builtin extensions, we automatically changed the field to
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our . Happy Coding!
Code change:
category, keybinding: { weight: KeybindingWeight.WorkbenchContrib, <del> when: ContextKeyExpr.and(Constants.SearchViewVisibleKey, Constants.FirstMatchFocusKey), </del> <ins> when: ContextKeyExpr.and(Constants.SearchViewVisibleKey, ContextKeyExpr.or(Constants.FirstMatchFocusKey, CONTEXT_ACCESSIBILITY_MODE_ENABLED)), </ins> primary: KeyMod.CtrlCmd | KeyCode.UpArrow, }, });

Related discussion:
text: CC In , you type something in the input field and hit enter. When search result pops up, you need to press tab key tediously mutiple times to land in the search result treeview. It would be better if the search result tabindex could be adjusted so that users can quickly jump into the treeview after providing the search term (e.g., pressing from the search input field goes to the result treeview). Another way is pressing key in the search input field moves user focus to the search result treeview directly. Version: 1.78.0-insider (system setup) Commit: Date: 2023-04-04T09:32:52.453Z Electron: 22.4.3 Chromium: 108.0.5359.215 16.17.1 V8: 10.8.168.25-electron.0 OS: Windows_NT x64 10.0. Sandboxed: Yes
The latter option is preferred for a screen reader user's better navigability.
what do you think of this suggestion?
You can press ctrl+down/up to move between the input and the tree immediately, does that help? I don't quite understand the suggestion, that the tree come before the search input in the the tab order? And with pressing enter to move focus to the tree, I think that doing multiple searches while tweaking your search query is a common workflow, and this would interrupt that, but maybe something like that could be configurable.
If you want to jump directly to the results, you could add a keybinding like The command will focus the results view.
and -- Thanks for sharing great tips! I did not even know that I could use Ctrl+Down/Up Arrows. This is working very well. -- I think this is now a "discoverability" issue. I recommend adding an aria-label or other similar techniques to remind screen reader users of these Ctrl+Down/Up key commands.
I did not know that either, so agree that this is a discoverability problem. does it make sense to you to add this hint to the ?
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it.
Code change:
category, keybinding: { weight: KeybindingWeight.WorkbenchContrib, <del> when: ContextKeyExpr.and(Constants.SearchViewVisibleKey, Constants.FirstMatchFocusKey), </del> <ins> when: ContextKeyExpr.and(Constants.SearchViewVisibleKey, ContextKeyExpr.or(Constants.FirstMatchFocusKey, CONTEXT_ACCESSIBILITY_MODE_ENABLED)), </ins> primary: KeyMod.CtrlCmd | KeyCode.UpArrow, }, });

Related discussion:
text: To learn more about how we handle feature requests, please see our . Happy Coding!
Yes, I could add it as an on the search text box. Is there an example elsewhere that I can follow in terms of adding a hint?
Here's what we do for the terminal's
I have found that Ctrl+UpArrow does not work when the keyboard focus is on the last item in the search result. Ctrl+Up only works in the first search result item.
The context key is why it only works for the first item: . Removing will do what you want
-- Shouldn't it be removed by default for other users? It does not make sense it only works in the first item if we want to generalize this behavior.
do you know why was applied here?
I'm guessing that it's because users wanted a keybinding that allowed them to move to the query fields when there were no more results to see. do you happen to know why it's like this and whether we can remove the check for ?
That keybinding also does other things- on mac. I didn't want to interfere with normal list keybindings. If this would be really useful, we could add a new keybinding which doesn't have that context key? Or users can customize it that way for themselves too?
On mac when the search results are focused, does not do anything.
It works for me
Ah yeah I see it working now. hb as it seems like it is more important to be able to get back to the search box in this case than to scroll one line up?
I think I'd rather leave the typical list navigation commands alone, but if it's just behind tbh I'll defer to you. But I also remember that the ctrl+shift+F shortcut should just focus the search input too, if that helps.
Since is a pattern we use elsewhere and screen reader users already have a high cognitive load placed upon them, I think we should follow suit here behind that flag.
To verify: With , search for something, navigate in the search results, and use to return to the search input fields
Code change:
import { CancellationToken } from 'vs/base/common/cancellation'; import { isUNC } from 'vs/base/common/extpath'; import { Schemas } from 'vs/base/common/network'; <del> import { sep } from 'vs/base/common/path'; </del> <ins> import { normalize, sep } from 'vs/base/common/path'; </ins> import { URI } from 'vs/base/common/uri'; import { FileOperationError, FileOperationResult, IFileService } from 'vs/platform/files/common/files'; import { ILogService } from 'vs/platform/log/common/log';

Related discussion:
text: An information disclosure vulnerability exists in VS Code 1.71 and earlier versions. If an attacker is able to run arbitrary scripts inside of a webview (either created by extension or by core VS Code), the attacker could bypass the local resource roots check to read arbitrary files on the user's system The fix is available starting with VS Code 1.71.1. The mitigates this attack by performing input validation on the URL pointing to the repository to be cloned. Only use webviews from extensions that follow proper security measures to block script injection Do not disable VS Code's default security measures in the built-in markdown preview The patch for this can be found at An advisory for this can be found at MSRC details for this can be found at
Hi, just curious about this: The description of the vulnerability ends mid-sentence. I see the same phrasing on the GHSA advisory as well: Can it be revised to be clearer what is the nature of the vulnerability? (And of course: Thanks for finding and fixing it, and for making these advisories! Transparency and security are appreciated!)
Updated
Should the references to 1.71 in fact be 1.72?
Code change:
[deltaY, deltaX] = [deltaX, deltaY]; } <del> if (this._options.scrollYToX && !deltaX) { </del> <ins> // Convert vertical scrolling to horizontal if shift is held, this // is handled at a higher level on Mac const shiftConvert = !Platform.isMacintosh && e.browserEvent.shiftKey; if ((this._options.scrollYToX || shiftConvert) && !deltaX) { </ins> deltaX = deltaY; deltaY = 0; }

Related discussion:
text: VSCode Version: Code - Insiders 1.12.0-insider (, 2017-04-13T06:10:58.128Z) OS Version: Windows_NT ia32 6.1.7601 Extensions: the listing exceeds the lower minimum of browsers' URL characters limit Steps to Reproduce: any file and try to horizontal scroll either via mouse wheel or shift scroll.
Hello i'm still experiencing this issue , I've noticed a separate issue was closed for Ubuntu users, but still noticing this with Windows.
This seems to be fixed in the latest release.
correction, this issue still exists.
/cc I'm seeing this issue again as well, on my Ubuntu work machine and on Windows: VSCode Version: Code - Insiders 1.12.0-insider (, 2017-04-21T06:12:00.370Z) OS Version: Windows_NT ia32 10.0. Extensions: ;
Some more info: shift+mouse wheel does not work, however when I use the trackpad and two finger swipe horizontally it works fine. Unplugging and plugging in the mouse again didn't fix it.
Hmm the trackpad usually is for forward and back commands. I can confirm this is the same case for me. I'm wondering if electron has switched the forward and back commands for the horizontal scrolling. Because in my mouse settings if I set the horizontal scroll will to page forward and backward it works perfectly. But I shouldn't have to do that.
I tried to reproduce and failed with my setup (Windows 10 and Windows 7 on macOS running in Parallels). Here is what I try: shift-scrolling in the editor wheel-left/right in the editor ! Are you doing something different? Does it reproduce when you run with blank settings?
I tried to reload vscode insiders without any settings, and i'm still having the same experience.
One other note, I have mac os sierra at my home workstation and everything works perfectly there. It seems to be Windows specific. I'm running Windows 7
Here are errors and warnings upon restarting insiders without typing anything. I wonder if this has anything to do with it.
I assume those warnings would go away when you run code . I would not assume however that this would help you for this issue, but worth a try anyway.
I wonder if we could do a little experiment.
Code change:
[deltaY, deltaX] = [deltaX, deltaY]; } <del> if (this._options.scrollYToX && !deltaX) { </del> <ins> // Convert vertical scrolling to horizontal if shift is held, this // is handled at a higher level on Mac const shiftConvert = !Platform.isMacintosh && e.browserEvent.shiftKey; if ((this._options.scrollYToX || shiftConvert) && !deltaX) { </ins> deltaX = deltaY; deltaY = 0; }

Related discussion:
text: Can you: download run it from the window that opens make it small enough that horizontal scrollbars appear see if you can scroll ! If so, this would point to a general problem with our UI framework (electron) and we should report it there.
seems to be this line that's throwing an error which may be causing the scroll to not work.
I would think that is unrelated, but please follow my steps to find out more.
I downloaded () on the Linux machine that I can reproduce it on and I can scroll just fine. ! Note that after this gif I updated to latest and it still doesn't work on:
Sorry I didn't see your message until just now. Yes it scrolls fine. On Mon, Apr 24, 2017, 10:31 AM Daniel Imms <:
need your help here for more debugging. First thing that comes to my mind is to add a breakpoint into  to see if this is even triggered when scrolling horizontally?
it's hit, but is set, not as I would expect. ! is set though: ! Are we meant to handle manually?
any chance you could debug stable to verify that e.deltaX is set? Is there any other property that has an increasing value? /cc if you have any clues on this Looking for chrome issues I stumbled upon:
Fixed via
Thank you guys, very much appreciated. Have realized over the last few days just how much I depend on horizontal scrolling.
As i'm not familiar with the insiders release pattern, any idea when we can expect this to come down the pipeline ?
should be in tomorrow's Insiders build
Thank you Daniel Imms <:
Code change:
return TPromise.as(true); } <del> } </del>  No newline at end of file <ins> } </ins>

Related discussion:
text: In order to create custom keybindings to toggle focus between the editor and something such as the terminal panel, a command to focus the active/most recently used editor group needs to be . I believe this is the best that can be accomplished currently: Focuses the first group, meaning if the second or third editor groups were focused this would feel wrong: Or this which focused the most recently used editor group but opens the last editor/file in the group: Some context on request:
isn't that as easy as providing a global command that just puts focus into the active editor? E.g. ? PR welcome if you wanna give it a try.
yes, I expect it to be pretty easy.
got a better name than ?
works for me
Code change:
// Avoid adding cache busting if there is already a query string if (resource.query) { <del> return webviewEditor.webview.asWebviewUri(resource).toString(true); </del> <ins> return webviewEditor.webview.asWebviewUri(resource).toString(); </ins> } <del> return webviewEditor.webview.asWebviewUri(resource).with({ query: `version=${version}` }).toString(true); </del> <ins> return webviewEditor.webview.asWebviewUri(resource).with({ query: `version=${version}` }).toString(); </ins> } private extensionResource(path: string) {

Related discussion:
text: Issue Type: <bBug</bIf I try to open an image with a name such as 'test-' it says 'An error occurred while loading the image'. In the developer console, the following error is shown: VS Code version: Code 1.44.2 (, 2020-04-16T17:07:18.473Z) OS version: Darwin x64 19.4.0 <details<summarySystem Info</summary </detailsExtensions: none <!-- generated by issue reporter --
Looks like the problem is on the , line 22 We got , which is a string looks like it is correct. Next, when we do it becomes an object and the paths are not correct here. Going down into the () i found that the string is being processed inside the by the This piece of code takes the string, and tries to decode any part started from %, thats why %41 becomes A
I don't think the decoding process is faulty, but the encoding part. Every browser will interpret as . ! So the url should escape in the first place. !
You're right. The percent ("%") character is missed in the encodeTable, and in the encodeURIComponentMinimal() 562 line.
Code change:
import { KeyCode, KeyMod } from 'vs/base/common/keyCodes'; import { ToggleCaseSensitiveKeybinding, TogglePreserveCaseKeybinding, ToggleRegexKeybinding, ToggleWholeWordKeybinding } from 'vs/editor/contrib/find/browser/findModel'; import { category, getSearchView, openSearchView } from 'vs/workbench/contrib/search/browser/searchActionsBase'; <ins> import { CONTEXT_ACCESSIBILITY_MODE_ENABLED } from 'vs/platform/accessibility/common/accessibility'; </ins> //#region Actions: Changing Search Input Options registerAction2(class ToggleQueryDetailsAction extends Action2 {

Related discussion:
text: CC In , you type something in the input field and hit enter. When search result pops up, you need to press tab key tediously mutiple times to land in the search result treeview. It would be better if the search result tabindex could be adjusted so that users can quickly jump into the treeview after providing the search term (e.g., pressing from the search input field goes to the result treeview). Another way is pressing key in the search input field moves user focus to the search result treeview directly. Version: 1.78.0-insider (system setup) Commit: Date: 2023-04-04T09:32:52.453Z Electron: 22.4.3 Chromium: 108.0.5359.215 16.17.1 V8: 10.8.168.25-electron.0 OS: Windows_NT x64 10.0. Sandboxed: Yes
The latter option is preferred for a screen reader user's better navigability.
what do you think of this suggestion?
You can press ctrl+down/up to move between the input and the tree immediately, does that help? I don't quite understand the suggestion, that the tree come before the search input in the the tab order? And with pressing enter to move focus to the tree, I think that doing multiple searches while tweaking your search query is a common workflow, and this would interrupt that, but maybe something like that could be configurable.
If you want to jump directly to the results, you could add a keybinding like The command will focus the results view.
and -- Thanks for sharing great tips! I did not even know that I could use Ctrl+Down/Up Arrows. This is working very well. -- I think this is now a "discoverability" issue. I recommend adding an aria-label or other similar techniques to remind screen reader users of these Ctrl+Down/Up key commands.
I did not know that either, so agree that this is a discoverability problem. does it make sense to you to add this hint to the ?
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it.
Code change:
import { KeyCode, KeyMod } from 'vs/base/common/keyCodes'; import { ToggleCaseSensitiveKeybinding, TogglePreserveCaseKeybinding, ToggleRegexKeybinding, ToggleWholeWordKeybinding } from 'vs/editor/contrib/find/browser/findModel'; import { category, getSearchView, openSearchView } from 'vs/workbench/contrib/search/browser/searchActionsBase'; <ins> import { CONTEXT_ACCESSIBILITY_MODE_ENABLED } from 'vs/platform/accessibility/common/accessibility'; </ins> //#region Actions: Changing Search Input Options registerAction2(class ToggleQueryDetailsAction extends Action2 {

Related discussion:
text: To learn more about how we handle feature requests, please see our . Happy Coding!
Yes, I could add it as an on the search text box. Is there an example elsewhere that I can follow in terms of adding a hint?
Here's what we do for the terminal's
I have found that Ctrl+UpArrow does not work when the keyboard focus is on the last item in the search result. Ctrl+Up only works in the first search result item.
The context key is why it only works for the first item: . Removing will do what you want
-- Shouldn't it be removed by default for other users? It does not make sense it only works in the first item if we want to generalize this behavior.
do you know why was applied here?
I'm guessing that it's because users wanted a keybinding that allowed them to move to the query fields when there were no more results to see. do you happen to know why it's like this and whether we can remove the check for ?
That keybinding also does other things- on mac. I didn't want to interfere with normal list keybindings. If this would be really useful, we could add a new keybinding which doesn't have that context key? Or users can customize it that way for themselves too?
On mac when the search results are focused, does not do anything.
It works for me
Ah yeah I see it working now. hb as it seems like it is more important to be able to get back to the search box in this case than to scroll one line up?
I think I'd rather leave the typical list navigation commands alone, but if it's just behind tbh I'll defer to you. But I also remember that the ctrl+shift+F shortcut should just focus the search input too, if that helps.
Since is a pattern we use elsewhere and screen reader users already have a high cognitive load placed upon them, I think we should follow suit here behind that flag.
To verify: With , search for something, navigate in the search results, and use to return to the search input fields
Code change:
this.inSelectionToggle = this._register(new Toggle({ icon: findSelectionIcon, <del> title: NLS_FIND_IN_CELL_SELECTION_BTN_LABEL, </del> <ins> title: NLS_TOGGLE_SELECTION_FIND_TITLE, </ins> isChecked: false, inputActiveOptionBackground: asCssVariable(inputActiveOptionBackground), inputActiveOptionBorder: asCssVariable(inputActiveOptionBorder),

Related discussion:
text: Testing I found "Find in Cell Selection" confusing label for the button given it is to find in selected cells. Does it make sense? Would "Find in Selected Cells" be a bit easier? !
Yeah, agreed that the labeling isn't perfect. Will workshop this in the next iteration, as this button will be serving dual purpose as a way to search in textual selections within a cell, as well as searching in multi-cell selections as the feature is currently. Thanks for the feedback!
Code change:
this.inSelectionToggle = this._register(new Toggle({ icon: findSelectionIcon, <del> title: NLS_FIND_IN_CELL_SELECTION_BTN_LABEL, </del> <ins> title: NLS_TOGGLE_SELECTION_FIND_TITLE, </ins> isChecked: false, inputActiveOptionBackground: asCssVariable(inputActiveOptionBackground), inputActiveOptionBorder: asCssVariable(inputActiveOptionBorder),

Related discussion:
text: Notebooks: ! Editor: ! Version: 1.90.0-insider Commit: Date: 2024-05-28T05:48:32.492Z Electron: 29.4.0 ElectronBuildId: Chromium: 122.0.6261.156 20.9.0 V8: 12.2.281.27-electron.0 OS: Darwin arm64 23.4.0