jiebi/CodeConvo huggingface dataset:
Code change:
leftMarginRatio: this.centeredEditorLeftMarginRatio, size: this.centeredEditorSize }; <del> this.storageServise.store(EditorGroupsControl.CENTERED_EDITOR_LAYOUT_DATA_STORAGE_KEY, JSON.stringify(data), StorageScope.GLOBAL); </del> <ins> this.storageService.store(EditorGroupsControl.CENTERED_EDITOR_LAYOUT_DATA_STORAGE_KEY, JSON.stringify(data), StorageScope.GLOBAL); </ins> } public getVerticalSashTop(sash: Sash): number {

Related discussion:
text: <!-- Do you have a question? Please ask it on --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.21 OS Version: Mac 10.12.16 Steps to Reproduce: editor mode should be in vertical mode on centered layout with one tab, you should see it is centered split editor mode to horizontal mode centered layout will no longer work until you switch back to vertical mode <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.458 --- <!-- score: 0.451 --- <!-- score: 0.451 --<!-- potentialduplicatescomment --
Thanks for figuring this out. I spent a while trying to figure out what the problem was. Thank to you, I changed splitting to vertical mode and now centered layout works. I can affirm that this big is happening to me too. I'm on a mac as well.
I would expect centered mode to work if I have horizontal layout and only one editor. I tried removing the check to simply also enable it for horizontal layout but somehow the layout gets broken in that case. I plan to fix this in the following week but just to let you know that a PR is more than welcome :)
I just let you know that money is more than welcome :smile: Just kidding... I run on fun xD you shall have your PR :) it has the number . The problem was, that the available size was calculated by using which holds the height and not the width of the editor when in horizontal mode. You have to play around with it a little... it seemed to work but I did no deep testing or anything As bonus I fixed two typos (one of whom I made myself :smile:)
thanks a lot for your PR, I just merged it in I tried it out and it works nicely, also thanks for fixing typos. For money feel free to apply for our internshipts if you are a student or to our open positions :)
:smile: I'll finish university in 4 month... so... I might very well do that xD
Code change:
description: nls.localize('task.quickOpen.showAll', "Causes the Tasks: Run Task command to use the slower "show all" behavior instead of the faster two level picker where tasks are grouped by provider."), default: false }, <ins> 'task.showDecorations': { type: 'boolean', description: nls.localize('task.showDecorations', "Shows decorations at points of interest in the terminal buffer such as the first problem found via a watch task. Note that this will only take effect for future tasks."), default: true }, </ins> 'task.saveBeforeRun': { markdownDescription: nls.localize( 'task.saveBeforeRun',

Related discussion:
text: VS Code Version: insiders/from sources Task terminals don't respect setting so decorations cannot be disabled.
thanks for creating this issue. I remember noticing this then got distracted by some other issue
we're separating the task decorations from terminal decorations (shell integration), so will have a setting
Verified that works
Code change:
media: { type: 'markdown', path: 'empty' } <ins> }, { id: 'accessibilitySettings', title: localize('gettingStarted.accessibilitySettings.title', "Configure accessibility settings"), description: localize('gettingStarted.accessibilitySettings.description.interpolated', "Accessibility settings can be configured by running the Open Accessibility Settings command.n{0}", Button(localize('openAccessibilitySettings', "Open Accessibility Settings"), 'command:workbench.action.openAccessibilitySettings')), media: { type: 'markdown', path: 'empty' } </ins> } ] }

Related discussion:
text: Screen reader and low vision (or other accessibility) users often use our menu items to discover things. We should include a menu item to open the getting started walkthrough under .
and WDYT?
Seems reasonable to me. The title suggests that it could also be a walkthrough, or part of an existing walkthrough. The tradeoff there would be discoverability.
I see an error in the console when opening accessible view from that welcome experience:
Cc
Related:
Code change:
if (Object.keys(matchedRecommendations).length) { this.promptFromRecommendations(uri, model, matchedRecommendations); <del> return true; </del> } <del> return false; </del> } private promptFromRecommendations(uri: URI, model: ITextModel, extensionRecommendations: IStringDictionary<IFileOpenCondition[]>): void {

Related discussion:
text: When a user opens a file extension that does not have a specific recommendation tied to it, we show the general notification that points users to the marketplace. This has the following flaws: Most popular file types are already covered by specific extensions, so what gets left in this experience is leftovers For most of the extensions there is no good extension to handle this experience. Thus opening the Extension page does not provide value This is adding un-needed pings to the Marketplace service Also we had a bug that this feature was not available in stable and only 3 users found it is not there Would love for us to get some telemetry on this actions to see if this is actually bringing value to users. If not, we should either: Remove this flow completely Have a pre-defined set of file extensions for which we show this. Checking with tags seems to be very faulty. In my example below there is not an extension that helps with PowerPoint files. !
Only of these notifications end up with users clicking on Search Marketplace ! When it is actually clicked here are the top extensions ! Thus I suggest that we: Remove this dialog Add explicit extension recommendation for and . Since those seem to be missing. what do you think?
Sounds good to me
Great. Ok, you remove the dialog when you find time, I will add the recommendations for csv and pdf. Or if you go on vacation, I can also remove the dialog. I am working in August. Thanks
Feel free to remove it in August, otherwise I can also do it in September. Here it is
To verify: a file with some strange extension. For example -make sure no notification shows up a .py file or .go file. Make sure you get an extension recommendation for specific python / go extensions
Code change:
// Stat needs to be resolved first and then revealed const options: IResolveFileOptions = { resolveTo: [resource], resolveMetadata: this.sortOrder === 'modified' }; const workspaceFolder = this.contextService.getWorkspaceFolder(resource); <del> const rootUri = workspaceFolder ? workspaceFolder.uri : this.roots[0].resource; </del> <ins> if (workspaceFolder === null) { return Promise.resolve(undefined); } const rootUri = workspaceFolder.uri; </ins> const root = this.roots.filter(r => r.resource.toString() === rootUri.toString()).pop()!; try {

Related discussion:
text: Issue Type: <bBug</bAssume If a FileSystemProvider extension implements more than one scheme, and if a file is opened using a scheme that is not used by the root folder(s) of the workspace, then when focus is switched to that file a call is issued on a folder resource that cannot possibly contain the file resource (because the scheme is different). In some scenarios a stat() call on a root folder can be costly, meaning it is important not to do it unnecessarily. This is not a new 1.37 issue. I will add information about how to demonstrate the issue using a variant of fsprovider-sample, and I am also willing to supply a PR to fix it. VS Code version: Code 1.37.0 (, 2019-08-08T02:33:50.993Z) OS version: Windows_NT x64 10.0.
Steps to reproduce: Use 1.38.0-insider, or a 1.37 build that contains the fix for branch at fsprovider-sample in VS Code a logpoint in the stat() method of (line 58) with the following message: that the 'Launch Extension' debug configuration. the Extension Development Host window appears, run the following commands in it: MemFS: Setup Workspace MemFS: Add Second Root MemFS: Create Files to Explorer view. on under the second root (MemFS2 - Different Scheme) the first root doubleclick on at least two files. the Debug Console of your initial VS Code instance, observe the stat messages as you switch between file tabs on the EDH, e.g. context menu of second root (MemFS2) to Remove Folder from Workspace. between tabs of the files and observe how when you click on the opened from memfs2 there is an additional stat of the first root (memfs)
Fixed via can you just let us know tomorrow once the new insiders is out if the issue is indeed fixed for you. Thank you
confirmed good in today's Insider. Thanks!
Thanks, adding verified label.
Code change:
return extHostTypeConverter.location.from(value); } else if (extHostTypes.NotebookRange.isNotebookRange(value)) { return extHostTypeConverter.NotebookRange.from(value); <ins> } else if (value instanceof ArrayBuffer) { hasBuffers = true; return VSBuffer.wrap(new Uint8Array(value)); } else if (value instanceof Uint8Array) { hasBuffers = true; return VSBuffer.wrap(value); </ins> } if (!Array.isArray(value)) { return value;

Related discussion:
text: Currently when using , ArrayBuffers just turn into an empty object. We should support these for efficient data transfer between extensions/extension hosts. We recently support for them on a protocol level, so support here should not be terribly hard...
I see two possible approaches to support this: this logic specifically for commands (or even just for a specific command). This is what we do for webviews for example: our implementation aware of array buffers instead of only supporting VSBuffers. Take a look at how is used in our rpc code as a starting point: The webview serialization logic I linked to above would probably be a good starting point for this
Code change:
// Terminal shell integration 'out-build/vs/workbench/contrib/terminal/browser/media/shellIntegration.ps1', 'out-build/vs/workbench/contrib/terminal/browser/media/shellIntegration-bash.sh', <ins> 'out-build/vs/workbench/contrib/terminal/browser/media/shellIntegration-env.zsh', 'out-build/vs/workbench/contrib/terminal/browser/media/shellIntegration-profile.zsh', </ins> 'out-build/vs/workbench/contrib/terminal/browser/media/shellIntegration.zsh', '!**/test/**'

Related discussion:
text: from Windows to Linux where zshell is installed, with shell integration turned on a new (zsh) terminal. Terminal remains empty a bash terminal. That works shell intergation and create a zsh terminal. That works Left side was created with shell integration on, right side was create  Let me know if there's any addition info to get.
It would be helpful if you could turn on trace logging and provide the logs
Code change:
"inputOption.activeBorder": "#2488DB", "keybindingLabel.foreground": "#CCCCCC", "menu.background": "#1F1F1F", <ins> "menu.selectionBackground": "#0078d4", </ins> "notificationCenterHeader.background": "#1F1F1F", "notificationCenterHeader.foreground": "#CCCCCC", "notifications.background": "#1F1F1F",

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.85.2 OS Version: Windows 11 Enterprise (Windows_NT x64 10.0..3007) Description During an accessibility test, we found the contrast ratio between the highlight color of the focused button in "More Actions..." in notification popup and its background is not high enough under "Default Dark Modern" theme. Highlight Color: Background Color: Contrast Ratio: 1.346:1 Required Contrast Ratio: 3:1 !
I think this refers to the background color of the gear icon in the toolbar of a notification relative to the background color of the notification.
The bug reported on my side particularly specified the "Manage Extension" button highlight color and the background color of that actions popup under settings icon in the notification.
Looks like it's about the blue on black bg, in that case this applies to all the web menus in VS Code.
yes, it's about the blue highlight and black background.
A11yMAS; #A11yTCS; #A11ySev2; #DesktopApp; #Win32; #Visual Studio Code Client; #BM-VisualStudioCodeClient-Win32-Aug2023; #WCAG1.4.11; #Non-text Contrast;
Hi, is there any update on the plan of fixing this accessibility bug?
putting this on the March plan.
Hi, may I check if the fix is included in v1.88.0?
Hi, I have checked v1.88.0 but it seems the active color is still not the one you changed to in your PR. Did I miss something?
Code change:
"inputOption.activeBorder": "#2488DB", "keybindingLabel.foreground": "#CCCCCC", "menu.background": "#1F1F1F", <ins> "menu.selectionBackground": "#0078d4", </ins> "notificationCenterHeader.background": "#1F1F1F", "notificationCenterHeader.foreground": "#CCCCCC", "notifications.background": "#1F1F1F",

Related discussion:
text: Verified with the Dark Modern theme, but do we also have to fix this with the Dark+ or Dark (Visual Studio) themes?
Thanks, I think it's fine we only fix it in default dark theme for now. The test team doesn't require that in other themes so far.
Code change:
let prefixFileRegex = RegExp('(d+)(' + separators + '.*)(..*)$'); if (!isFolder && name.match(prefixFileRegex)) { return name.replace(prefixFileRegex, (match, g1?, g2?, g3?) => { <del> return strings.pad(parseInt(g1) + 1, g1.length) + g2 + g3; </del> <ins> let number = parseInt(g1); return number < maxNumber ? strings.pad(number + 1, g1.length) + g2 + g3 : strings.format('{0}{1}.1{2}', g1, g2, g3); </ins> }); }

Related discussion:
text: Have file named in explorer Copy/paste it Window hangs This is from We shouldn't attempt this when the number is = Number.MAXSAFEINTEGER. It loops forever here: This bug will happen whenever incrementFileName fails to modify the file name.
I guess only interesting thing about this what we should do in this case as we need to create some new file name? Add without changing the original number?
that sounds reasonable
Code change:
[ localize('openExternalDialogButtonRetry', "Try again"), localize('openExternalDialogButtonInstall', "Install {0}", this.productService.nameLong), <del> localize('openExternalDialogButtonContinue', "Continue here") </del> <ins> localize('openExternalDialogButtonCancel', "Cancel") </ins> ], { cancelId: 2, <del> detail: localize('openExternalDialogDetail', "We tried opening {0} on your computer.", this.productService.nameLong) </del> <ins> detail: localize( 'openExternalDialogDetail.v2', "We launched {0} on your computer.nnIf {1} did not launch, try again or install it below.", this.productService.nameLong, this.productService.nameLong, ) </ins> }, );

Related discussion:
text: Testing on run continue on clone locally I see a browser-native dialog to open desktop I see a custom message that just reads "We tried opening Visual Studio Code - Insiders on your computer." which is confusing Unsure if we have to show the message or not but its wording needs to be improved. I mean tried and succeed in opening desktop so don't confusing me with this message. If we cannot prevent it I'd suggest to rephrase it and assume that it worked and give me a close option. Today, there this only covers the "didn't work cases" despite success https://user-
We cannot tell from the browser whether opening the protocol url succeeded, and the current wording for this dialog is based on a similar dialog from Office which also unconditionally appears in the browser: Maybe renaming 'Continue here' to 'Cancel' or 'Close' would help? Some other ideas for wording--when you launch a Zoom meeting from a browser in the desktop client, it says !
I can accept that but the wording should be positive/happy. Like: "This session now continues in VS Code Desktop. You can close this window, all your changes have been carried along. Try again if VS Code Desktop didn't start yet."
Code change:
this._terminalHasTextContextKey.set(isActive && this.hasSelection()); } <del> private _sanitizeInput(data: any) { return typeof data === 'string' ? data.replace(TerminalInstance.WINDOWS_EOL_REGEX, 'r') : data; } </del> protected _getCwd(shell: IShellLaunchConfig, root: Uri): string { if (shell.cwd) { return shell.cwd;

Related discussion:
text: VSCode Version: Version 1.12.2 (1.12.2) OS Version: OS X E Capitan 10.11.6 Steps to Reproduce: integrated terminal <kbdctrl+`</kbdterminal: key combination <kbdctrl + j</kbdExpected Cursor moves back a word, this the behavior that iTerm and exhibit Actual Newline is sent, essentially the same as using <kbdreturn</kbd
doesn't seem to be in the path in for me?
It's in zsh which is in mac by default? So just type in
Works for me, if you remove the backtick from your command: Not
Oh that was a typo, I am using Hmm that works in the integrated terminal for you? Using zsh without a .zshrc: Expected (in iTerm): ! <kbdctrl + j</kbdcauses the cursor to jump back to the beginning of each word. Actual (in integrated terminal): ! Should have probably left this gif linger a bit longer but at the end it says: As if you had just pressed <kbdreturn</kbd.
FYI, I just tried rebinding <kbdctrl + j</kbdwith bash's native binding commands: Again this works in iTerm and but not in the integrated terminal. Expected Terminal screen should be cleared Actual Newline is sent, essentially the same as using return
Hm I doesn't seem to be working anymore, maybe I didn't test it right or something. I looked into it a little bit, it seems to work fine in the demo which is the underlying library used. so that's why it's happening. The question is why does it work in the demo but not VS Code. It definitely gets registered within zsh inside VS Code: <img width="430" alt="screen shot 2017-05-17 at 9 50 05 pm" src=""Stepping through the code nothing stuck out as misbehaving through when run inside VS Code; they appear to both be sending 'n'. Nothing in the seems to be wrong either.
Aw I was really of hoping it was something wrong with my local configuration. Also I got the same behavior when trying it on windows + cygwin with a fresh install of vscode, <kbdctrl + j</kbdnot being distinguished from newline.
Hey just wondering if there was any progress on this?
Code change:
this._terminalHasTextContextKey.set(isActive && this.hasSelection()); } <del> private _sanitizeInput(data: any) { return typeof data === 'string' ? data.replace(TerminalInstance.WINDOWS_EOL_REGEX, 'r') : data; } </del> protected _getCwd(shell: IShellLaunchConfig, root: Uri): string { if (shell.cwd) { return shell.cwd;

Related discussion:
text: If this is low priority could one of the contributors point me a area/file that might be causing the issue? Thanks!
I can't look into it any further right now, I'm pretty stumped on where to go from here though. It's a pretty technical problem so it might not be the easiest thing to jump in to. If you want to you can start by cloning and trying to reproduce it using the demo. If you can reproduce it you can check what's sent to the backend by loading up devtools and debugging If works fine, it would be a matter of doing a similar exercise but figuring out why VS Code behaves different by debugging similar code.
(Copied from ) This was happening because ctrl+j translates to (see ) and since we normalized to all input to the pty, this was getting lost and converted to a new line. The fix here is to never "sanitize" data that has already been processed by (ie. key strokes and paste) as knows how to handle them. We only need to process text that we send directly to the terminal such as a script the user is running or text being pasted into vim, etc.
Hmm just updated to 1.14.1 and this still isn't working for me... !
This will only be in 1.15.
Oh okay thanks.
Code change:
resolved "https://registry.yarnpkg.com/xterm-addon-unicode11/-/xterm-addon-unicode11-0.5.0.tgz#41c0d96acc1e3bb6c6596eee64e163b6bca74be7" integrity sha512-Jm4/g4QiTxiKiTbYICQgC791ubhIZyoIwxAIgOW8z8HWFNY+lwk+dwaKEaEeGBfM48Vk8fklsUW9u/PlenYEBg== <del> xterm-addon-webgl@0.15.0-beta.7: version "0.15.0-beta.7" resolved "https://registry.yarnpkg.com/xterm-addon-webgl/-/xterm-addon-webgl-0.15.0-beta.7.tgz#ab247b499f61e8eebff92e08ec5ca999d87e06af" integrity sha512-7WCI/D6uFNp3y9TeTsbSo1h7gCy4h/yP2lWn8ZEjCaiGvO11DbKMq17fbiwaR3YmGWXoRKkcLaNIiqxFnjKO4w== </del> <ins> xterm-addon-webgl@0.15.0-beta.8: version "0.15.0-beta.8" resolved "https://registry.yarnpkg.com/xterm-addon-webgl/-/xterm-addon-webgl-0.15.0-beta.8.tgz#2005198582f6f1f4a9b2612b9354c0bcc9f148d8" integrity sha512-HjTr9bi3FvdOIPaaIpih6qdHX2z+H7sQPluLj5KzwCqRiEVUVRi19dl8SdHjf6dCmN3GahMhjV7D+zxHi2pLTw== </ins> <del> xterm@5.2.0-beta.30: version "5.2.0-beta.30" resolved "https://registry.yarnpkg.com/xterm/-/xterm-5.2.0-beta.30.tgz#6f50796d1652a61b30eeed7fa2bdd9c485a7d8ee" integrity sha512-l1YBwMnakKXd638oxbzEg9Y1sWqxcrm/q7i5gBuWaK8N7Tq1NvF51FCamxXtfdL4dostgw8WoM+/6KRlL53t6A== </del> <ins> xterm@5.2.0-beta.33: version "5.2.0-beta.33" resolved "https://registry.yarnpkg.com/xterm/-/xterm-5.2.0-beta.33.tgz#584fb261ec283573ddb9d3ef4b3ea63a9a359f81" integrity sha512-HIkQgn0/akWLWLzUJquAeVF1/nqPgqL6KzmhkAOJbOtNHftNZbEK+lDGfzz1dUC/smpXQkKm7X2nn92h3i1tgQ== </ins>

Related discussion:
text: <!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --With the above settings in effect and a terminal open in the bottom panel: If the terminal has focus, the cursor blinks If the terminal doesn't have focus, then the cursor remains visible without blinking Unlike the block-shaped cursor, which becomes hollow when the terminal loses focus, the line-shaped cursor doesn't change appearance when the terminal loses focus; it merely stops blinking. This makes it hard to tell at a glance whether the terminal has focus. So that it's easier to tell whether the terminal has focus, I would like an option to customize how the line-shaped cursor appears in the terminal when it doesn't have focus. Possible options (not exhaustive): Hide the cursor altogether Keep it visible, but make it (say) 50% opacity Show the same hollow block that's used with the block-shaped cursor
I actually thought it showed the hollow block in this case, I think that makes the most sense
try try
We're going back on the decision made in and making unfocused show the rectangle regardless of cursor style. Discussion: