jiebi/CodeConvo huggingface dataset:
Change:
clipboardText = await clipboardService.readText(); } <ins> editor.focus(); </ins> SnippetController2.get(editor)?.insert(snippet.codeSnippet, { clipboardText }); snippetsService.updateUsageTimestamp(snippet); }

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 <!-- 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: Version: 1.71.2 (user setup) Commit: Date: 2022-09-14T21:03:37.738Z Electron: 19.0.12 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: WindowsNT x64 10.0. Sandboxed: No OS Version: Windows 10 Steps to Reproduce: Use a snippet that has repeat placeholder variables, e.g. command palette, select "Insert snippet" the list of available snippets, select using the mouse to left click on it typing to fill in the highlighted/selected placeholder variable text editor does not have focus. (If you manually select the text editor for focus, it is very easy to lose the multiple cursor focus which is essential for efficiently 'filling in' the snippet) This is an accessibility issue, which arose while using eye control for coding, but the issue persists when just using conventional mouse control. This video shows the correct behaviour, with focus immediately moved to the text file with correct cursor selection when keyboard control is used to select a snippet. Note that NumPad2 is being used as a shortcut for 'tabbing' to the next placeholder, to avoid other conflicts: This video shows the bug, with focus lost when mouse control is used to select a snippet.
I will push a change to explicitly set focus back to the editor after having interacted with quick pick.

However, this looks like an issue with quick pick itself, that fact that clicking vs key-down is different seems y and other might be affected by this as well
Thanks for the quick investigation. We are getting on really well with eye control otherwise, and getting snippets working flawlessly is going to be a big win!
since you are out, I'll move this to next iteration.
fixed the actual bug... and the focus stuff is covered by
Cough, cough. IMO is the actual bug and affected folks are implementing workarounds
Agreed
Change:
assert.deepStrictEqual(view2.size, [400, 300]); assert.deepStrictEqual(view3.size, [400, 300]); }); <ins> test('flipping orientation should preserve absolute offsets', function () { const view1 = new TestView(50, Number.POSITIVE_INFINITY, 50, Number.POSITIVE_INFINITY); gridview.addView(view1, 200, [0]); const view2 = new TestView(50, Number.POSITIVE_INFINITY, 50, Number.POSITIVE_INFINITY); gridview.addView(view2, 200, [1]); gridview.layout(800, 600, 100, 200); assert.deepStrictEqual([view1.top, view1.left], [100, 200]); assert.deepStrictEqual([view2.top, view2.left], [100 + 300, 200]); gridview.orientation = Orientation.HORIZONTAL; assert.deepStrictEqual([view1.top, view1.left], [100, 200]); assert.deepStrictEqual([view2.top, view2.left], [100, 200 + 400]); }); </ins> });

Discussion:
Was finally able to repo this but not reliably. It seems to rely on a new being created, but this doesn't always happen. The most reliable repo for me: with a notebook and text editor in a single editor group the notebook editor down to create a new group below the text editor grab the notebook editor and drag it right to move the bottom editor to the right I think the root cause is that the notebook widget is passed the wrong position. I'm going to work around this by making the notebook editor ignore the position it is given, however this will also undo the performance fixes we made this iteration for notebook layout I don't fully understand the grid layout code but it seems that is being set incorrectly in cases where a new BranchNode/SplitView is created. Here's what I see happening after step 3 of the repo above: setter is called calls which creates a new the constructor, a new Split View is created is called on it. At this point, of the split view is: the time layout is called on the notebook editor widget, is computed as zero. This results in the wrong layout. Looking at the code, we can see that is passed in as the absolute offset in step 4: <img width="1104" alt="Screenshot 2022-11-30 at 12 48 54 PM" src="https://user-"If I then slightly resize the window, here's what happens: call on the split View for the new group now is: we layout the notebook editor, is now correctly computed as Originally posted by in
Change:
private _readOnly: boolean; private _cursorBlinking: editorCommon.TextEditorCursorBlinkingStyle; private _cursorStyle: editorCommon.TextEditorCursorStyle; <del> private _canUseTranslate3d: boolean; </del> private _isVisible: boolean;

Discussion:
VSCode Version: 1.3.0-Insider OS Version: MacOSX 10.11.5 Steps to Reproduce: document with long lines (longer then screen width to the right and move the cursor to accordingly -Cursor is invisible
Unless I'm misunderstanding the issue, this is expected behaviour. How would you expect the editor to behave? This happens on every editor. If you'd like your long line to wrap, you can control that by setting the configuration to .
No, this has nothing to do with wrapping long lines. My cursor is literally invisible: !
Interesting, but I still can't reproduce... Can you provide a screencast or similar?
Where is your focus? The cursor blinks/is rendered only when the editor is focused
I tried reproducing it with new files, but I'm unable to. This happens with a few xsl files at work. I'll try to see if I can get a 100% reproducible file. The focus is in the active editor. I'm only moving the cursor to the right. Screencast: ! EDIT: The cursor is only visible for as long as it doesn't surpass the last character that was visible in the initial view region of the editor
Thank you for the gif! I've never seen that before. Do you see any errors in the console () ? I've quickly tried with a file with these contents but could not reproduce: Other things that might be relevant: does this reproduce when running code without extensions (close it completely and launch with ), did you customize the font and/or picked a different theme?
I found a way to reliably reproduce this issue. The missing piece was, that it only happens when you have split the main editor. I can't reproduce it with just one editor visible. Launching with doesn't help. I did try with the default user settings and theme as well, but without success. I managed to nail it down to the following steps to reproduce this issue: vscode random file (doesn't matter) the editor with (this is important) random code/text with long lines in one of the 2 editor panels
Forgot to mention: unfortunately there are no errors in the devtools console.
I'm also seeing this issue. VS Code 1.3.0 commit Windows 10.0.

Edit: Oops, didn't notice that a fix was already committed yesterday.
can you try my solution in ?
Yes, but disabling extensions doesn't help. This issue only occurs when you have more than a single editor view. See:
We decided to fix this by removing the property from the tabs container. The visual impact is that if you use a theme that introduces a custom background color, it will only be picked up for the active tab. E.g. for our themes "red" and "abyss": ! ! To verify: be on windows have 2 groups open at least have enough tabs open to cause scrolling activate a tab that is at the end of the tab list in group one find a long line and arrow right verify the cursor is not lost
can I ask you to verify this on Windows using this 1.3.1 stable build: Thanks!
I verified this.
Change:
import * as fs from 'fs'; import * as path from 'path'; import * as vscode from 'vscode'; <ins> import * as nls from 'vscode-nls'; </ins> import API from '../utils/api'; import { TypeScriptServiceConfiguration } from '../utils/configuration'; import { RelativeWorkspacePathResolver } from '../utils/relativePathResolver'; <del> import { ITypeScriptVersionProvider, localize, TypeScriptVersion, TypeScriptVersionSource } from './versionProvider'; </del> <ins> import { ITypeScriptVersionProvider, TypeScriptVersion, TypeScriptVersionSource } from './versionProvider'; const localize = nls.loadMessageBundle(); </ins> export class DiskTypeScriptVersionProvider implements ITypeScriptVersionProvider {

Discussion:
devtools. the vscode repo and open a TS file. . over an expression while the TS extension loads. hover appears. :bug: In the devtools console, the "didn't get externalized correctly" warning shows up.
Any ideas what would cause this?
This would happen if the call wasn't rewritten by the webpack loader defined here: can you look at the built version of typescript-language-features and tell me what the call looks like?
Ah looks like we're incorrectly importing from another file. Here's the compiled call (which doesn't appear to be rewritten): Will push a PR with a fix
That'll do it. loadMessageBundle is actually responsible for giving you your strings for that specific file so you need to have one of those everywhere you have a localize call
Change:
return (await this.remoteAuthorityResolverService.resolveAuthority(remoteAuthority)).authority; } } : undefined; <del> const tunnel = await this.tunnelService.openTunnel(addressProvider, portMappingRequest.address, portMappingRequest.port); </del> <ins> let tunnel = await this.tunnelService.getExistingTunnel(portMappingRequest.address, portMappingRequest.port); if (!tunnel) { tunnel = await this.tunnelService.openTunnel(addressProvider, portMappingRequest.address, portMappingRequest.port); } </ins> if (tunnel) { const addressAsUri = URI.parse(tunnel.localAddress); const resolved = addressAsUri.scheme.startsWith(uri.scheme) ? addressAsUri : uri.with({ authority: tunnel.localAddress }); return { resolved, <del> dispose: () => tunnel.dispose(), </del> <ins> dispose: () => tunnel?.dispose(), </ins> }; } }

Discussion:
<!-- 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. --I'm using the 'Remote - SSH' extension. Suppose I set up static forwarding in my local : So port 3000 is statically forwarded to port 3000. Now if I output a link to the terminal (from within the remote), when this link is 'Command + Clicked', vscode opens in the browser - the wrong port, because it's auto-forwarded to the next available port. It feels like if static forwarding for this port is already set up, it could always infer that no auto port forwarding is needed and hence open in the browser at port 3000. The setting does not help in this case. Thanks :)
does the SSH extension use () to ensure that statically forwarded ports like this show in the ports view?
Yes
Thanks for confirming!
This looks like it will be a larger change. Moving to September.
Hi. Just encountered this problem today. I am using VSCode Docker remotes with Docker Desktop. One of my containers is running minio. There is a static port forward configured in that looks like this: My application sometimes prints out a full URL to the integrated terminal that looks like Clicking that link to open it in my web browser causes VSCode to dynamically forward a brand new port and rewrite the URL replacing the 9000 with something like . I would actually be ok with that, but that URL with the new port number doesn't even work. The original one does work. My situation sounds basically the same as OP, only using Docker remote instead of SSH remote. Just wanted to share my use case to verify it is actually the same issue and that whatever solution comes will solve it for both of us. I also want to say this feature was very unexpected. Personally, I think it should be off by default. URLs should be opened exactly as they are written. Please provide at least a setting so I can always open URLs from integrated terminal exactly as they appear. The back of my mind also wonders if there could be any potential security implication of rewriting URLs this way. Thanks.
Change:
import { NativeWindow } from 'vs/workbench/electron-sandbox/window'; import { ModifierKeyEmitter } from 'vs/base/browser/dom'; import { applicationConfigurationNodeBase, securityConfigurationNodeBase } from 'vs/workbench/common/configuration'; <ins> import { MAX_ZOOM_LEVEL, MIN_ZOOM_LEVEL } from 'vs/platform/window/electron-sandbox/window'; </ins> // Actions (function registerActions(): void {

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 <!-- 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 Version: 1.68.0 (user setup) Commit: Date: 2022-06-08T11:44:16.822Z Electron: 17.4.7 Chromium: 98.0.4758.141 16.13.0 V8: 9.8.177.13-electron.0 OS: Windows_NT x64 10.0. Steps to Reproduce: is not in F11 fullscreen mode. the Settings GUI, set window.zoomLevel to a negative value (e.g. -3) add an extra 0 (e.g. -30) setting is automatically applied, which leads to a state where the entire UI disappears. Clicking anywhere in the window minimizes the window. F11 fullscreen mode appears to fix this situation and the UI becomes visible again(albeit very tiny at the -30 zoom level). My initial take is this could be fixed with a sane lower bounds on window.zoomLevel. However, it appears that part of the issue is also that as window.zoomLevel becomes more negative(zooms out), the Menu Bar becomes larger. At high magnitude negative values, the Menu Bar increases in size to the point where it takes up the entire window and prevents user input. Ex.) window.zoomLevel: -20 . ! Ex.) window.zoomLevel: -30. At this level, the Menu Bar minimize "-" icon takes up the whole window.

At this level, the setting input box also de-focuses, preventing the user from pressing backspace to remove the extra 0. !
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Change:
"scrollbarSlider.background": "#6e768133", "scrollbarSlider.hoverBackground": "#6e768145", "settings.dropdownBackground": "#313131", <del> "settings.dropdownBorder": "#ffffff17", </del> <ins> "settings.dropdownBorder": "#ffffff1f", </ins> "settings.headerForeground": "#ffffff", "settings.modifiedItemIndicator": "#bb800966", "sideBar.background": "#181818",

Discussion:
Ref Unchecked and unfocused checkboxes in the Settings editor currently do not have much contrast between the checkbox background colour and the checkbox border colour for both Light+ v2 and Dark+ v2 themes. !
Change:
*--------------------------------------------------------------------------------------------*/ import { ITerminalLinkResolver, ResolvedLink } from 'vs/workbench/contrib/terminalContrib/links/browser/links'; <del> import { removeLinkSuffix, winDrivePrefix } from 'vs/workbench/contrib/terminalContrib/links/browser/terminalLinkParsing'; </del> <ins> import { removeLinkSuffix, removeLinkQueryString, winDrivePrefix } from 'vs/workbench/contrib/terminalContrib/links/browser/terminalLinkParsing'; </ins> import { URI } from 'vs/base/common/uri'; import { ITerminalBackend, ITerminalProcessManager } from 'vs/workbench/contrib/terminal/common/terminal'; import { Schemas } from 'vs/base/common/network';

Discussion:
<img width="1440" alt="image" src="https://user-"path: Versions:
I have one question wish can get help: how vscode terminal detect the path cwd? why can the path correctlly go to the file with a releative path? <img width="1440" alt="image" src="https://user-"I guess it may use the But seems I can get the cwd in TerminalLinkProvider now: <img width="1440" alt="image" src="https://user-"
We check a few things to determine which to use
vite become more and more popular recent days, I think it would be convinient to support the path with query string: !
When I click, it opens the right file, but it underlines the first query argument when I hover, is that an issue? <img width="539" alt="image" src=""
not much of an issue but it would look more polished by just underlining the whole thing
Change:
return result; } <del> export function to(task: ITaskDTO | undefined, workspace: IWorkspaceContextService, executeOnly: boolean, icon?: { id: string; color?: string }): ContributedTask | undefined { </del> <ins> export function to(task: ITaskDTO | undefined, workspace: IWorkspaceContextService, executeOnly: boolean, icon?: { id?: string; color?: string }): ContributedTask | undefined { </ins> if (!task || (typeof task.name !== 'string')) { return undefined; }

Discussion:
Testing I the following to the "Core - Build" task in this repo: The color shows in the "Run Task" quick pick, but not in the terminal tabs (I tried reloading, but still no color). !
the color will only take effect the next time you run the task - don't think it's worth listening to the config and updating. we don't do that for existing terminals either when an icon or color is set for their profile <img width="1291" alt="Screen Shot 2022-06-28 at 12 06 04 PM" src="https://user-"
Alex mentioned , I actually reproduced the icon and color not applying when testing also
I'm guessing it's just on tasks run via ? It works when running Core - Build explicitly but not ctrl+shift+b: !
should work for dependsOn tasks
works w ctrl+shift+b for other default build tasks () https://user-
works w ctrl+shift+b and the VS Code build task for me https://user-
can you pls send me the exact task config this isn't working for?
it's was just what was shown in the screenshot, the small change to . Might be related to Windows somehow then if you don't see it?
not sure why I can't reproduce it, but could be fixed by
I can still repro this in the latest insiders.
yes so can on Windows. we're going to debug
are there any task load messages in the output channel?
or any way the build task on windows is handled specially?
If there's an issue reading tasks from then an error should be logged to the tasks output channel, and I don't have any. The Run Build Task command shouldn't be handled any differently here, and I confirmed that this isn't build specific by making this keybinding:
to verify: set an icon for a dependency task
If I just set the icon color it now changes the icon away from the tools icon (its still the tools icon in the task quick pick): !
Change:
'default': EDITOR_DEFAULTS.contribInfo.lightbulbEnabled, 'description': nls.localize('codeActions', "Enables the code action lightbulb in the editor.") }, <ins> 'editor.maxTokenizationLineLength': { 'type': 'integer', 'default': 20_000, 'description': nls.localize('maxTokenizationLineLength', "Configures length of lines, for which tokenization process will be skipped for performance reasons") }, </ins> 'editor.codeActionsOnSave': { 'type': 'object', 'properties': {

Discussion:
Found no duplicated for this one Currently it's hardcoded I propose a config entry for long line length If you're object, I'd like to create pull request for this feature Your thoughts?
I think this makes sense as a workspace setting that defaults to the current value. Feel free to make a PR!
Change:
let activeRecordingDimmedColor: Color | undefined; if (theme.type === ColorScheme.LIGHT || theme.type === ColorScheme.DARK) { activeRecordingColor = theme.getColor(ACTIVITY_BAR_BADGE_BACKGROUND) ?? theme.getColor(focusBorder); <del> activeRecordingDimmedColor = activeRecordingColor?.transparent(0.2); </del> <ins> activeRecordingDimmedColor = activeRecordingColor?.transparent(0.38); </ins> } else { activeRecordingColor = theme.getColor(contrastBorder); activeRecordingDimmedColor = theme.getColor(contrastBorder);

Discussion:
!
It seems the new animation changes the size of the element, as can be seen when used in inline chat: !
Change:
layout(dimensions: IEditorTitleControlDimensions): Dimension { const stickyDimensions = this.stickyEditorTabsControl.layout(dimensions); <del> const unstickyDimensions = this.unstickyEditorTabsControl.layout(dimensions); </del> <ins> const unstickyAvailableDimensions = { container: dimensions.container, available: new Dimension(dimensions.available.width, dimensions.available.height - stickyDimensions.height) }; const unstickyDimensions = this.unstickyEditorTabsControl.layout(unstickyAvailableDimensions); </ins> return new Dimension( dimensions.container.width,

Discussion:
Testing See here: ! When many tabs are wrapping and height is little, at once point we disable wrapping to make room for the editor. I think this limit now needs to account for when 2 tab rows are showing.
Change:
flakySuite('ID', () => { test('getMachineId', async function () { <del> const id = await getMachineId(); </del> <ins> const errors = []; const id = await getMachineId(err => errors.push(err)); </ins> assert.ok(id); <ins> assert.strictEqual(errors.length, 0); </ins> }); test('getMac', async () => {

Discussion:
When fails to get a mac address it still returns a generated mac id, but uses to log the error. That's a bit risky as it rely on VS Code to already have installed a . The default handler throws an exception in a timeout that can crash the process. (see issue ) IMO the better way would be to pass a logger to , e.g. the -move to -add to
if you support the idea I can provide a PR
that all sounds fine to me, thanks for looking into this. I didn't know this could cause a crash since it had been in desktop for so long.
Change:
- libgl1 - libglib2.0-0 - libgtk-3-0 <ins> - libibus-1.0-5 </ins> - libnss3 - libpango-1.0-0 - libsecret-1-0

Discussion:
Ubuntu 22.10, Gnome 43.1, fresh VM - The errors are not shown the second time I call and also VS Code seems to start and work I saw , but that should be in by now.