jiebi/CodeConvo huggingface dataset:
Change:
this._eventDispatcher.emitSingleViewEvent(new viewEvents.ViewCompositionEndEvent()); } <del> private _onConfigurationChanged(eventsCollector: ViewModelEventsCollector, e: ConfigurationChangedEvent): void { // We might need to restore the current centered view range, so save it (if available) let previousViewportStartModelPosition: Position | null = null; if (this._viewportStart.isValid) { </del> <ins> private _captureStableViewport(): StableViewport { // We might need to restore the current start view range, so save it (if available) // But only if the scroll position is not at the top of the file if (this._viewportStart.isValid && this.viewLayout.getCurrentScrollTop() > 0) { </ins> const previousViewportStartViewPosition = new Position(this._viewportStart.viewLineNumber, this.getLineMinColumn(this._viewportStart.viewLineNumber)); <del> previousViewportStartModelPosition = this.coordinatesConverter.convertViewPositionToModelPosition(previousViewportStartViewPosition); </del> <ins> const previousViewportStartModelPosition = this.coordinatesConverter.convertViewPositionToModelPosition(previousViewportStartViewPosition); return new StableViewport(previousViewportStartModelPosition, this._viewportStart.startLineDelta); </ins> } <del> let restorePreviousViewportStart = false; </del> <ins> return new StableViewport(null, 0); } private _onConfigurationChanged(eventsCollector: ViewModelEventsCollector, e: ConfigurationChangedEvent): void { const stableViewport = this._captureStableViewport(); </ins> const options = this._configuration.options; const fontInfo = options.get(EditorOption.fontInfo); const wrappingStrategy = options.get(EditorOption.wrappingStrategy);

Discussion:
use autofolding of imports . use a type that is not imported in a TS file use quick fix to add the import the editor scrolls to an incorrect position. I think this is a recent regression, because I've been using both import folding and quick fix for imports since quite a while... maybe starting with the last stable. https://user- Version: 1.72.0-insider Commit: Date: 2022-09-21T05:40:07.654Z Electron: 19.0.17 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Darwin arm64 21.6.0 Sandboxed: Yes
Un-assigning myself as I don't think this cause by something the JS/TS extension itself is doing
who owns the quick fix UI now?
I own the UI. However it looks like scrolling here happen when the edit from the quick fix is applied. That's why I unassigned myself
It also unfolds if you do "Organize Imports", so seems like any action related with imports unfolds even though setting is
The root cause appears to be the folding ranges change and end up calling . That one does not attempt to maintain the viewport stable in any way.
this issue still exists:
Change:
"emmet.extensionsPath": { "type": [ "string", <ins> "array", </ins> "null" ], "default": null,

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 program in Windows Subsystem for Linux (WSL) but sometimes also in Windows 10 directly, I want to add custom snippets to emmet but the emmet.extensionPath variable only allows 1 path, It would be nice to add a secondary path if the first one is not found, so I can use the snippets in both systems, WSL and Windows 10 directly
Change:
return; } <del> this._webview.focusOutput(cell.id, this._webviewFocused); </del> <ins> if (!options?.skipReveal) { this._webview.focusOutput(cell.id, this._webviewFocused); } </ins> cell.updateEditState(CellEditState.Preview, 'focusNotebookCell'); cell.focusMode = CellFocusMode.Output;

Discussion:
a notebook and run a cell that produces an output long enough to scroll, e.g within the output element :bug: the output element scrolls to the top to select the first link
Change:
async goto(args: DebugProtocol.GotoArguments): Promise<DebugProtocol.GotoResponse | undefined> { if (this.capabilities.supportsGotoTargetsRequest) { <ins> this.stoppedSinceLastStep = false; </ins> const response = await this.send('goto', args); <del> this.fireSimulatedContinuedEvent(args.threadId); </del> <ins> if (!this.stoppedSinceLastStep) { this.fireSimulatedContinuedEvent(args.threadId); } </ins> return response; }

Discussion:
Stepping using the debug adapter that I helped develop has been broken by a VS Code change between 1.78.2 and 1.79.0. I used a to log the messages sent back and forth using the same extension version, but different VS Code versions. I attached the logs below. After diffing the two files, the only difference is that the "scopes" request isn't sent to the adapter after the "next" request reports a stopped event. The end result is that the debugging UI in VS Code is stuck in "running" mode even though the debug adapter is stopped, and the user has no way to advance. See
I think this is related to the fact that you send the "stopped" event before the "next" response. We should be able to support that but as a workaround you could respond to "next" before stopping the debugger.
Thanks for the quick response I will look into that workaround. In what cases is tit required? Any type of step?
I see the issue but it will be too much of a risky change to get into our next stable release. I will try to address it in July but I'd recommend working around it in your extension.
I understand. I implemented the workaround in my extension and initial tests show that it works, so thanks for making me aware of that.
For my own reference, I think it should be ok to do immediately instead of waiting for the response.
Hi what are some verification steps for this issue?
<!-- 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!
I verified this by hacking mock-debug, but are you able to verify the change in Insiders, or have you moved on to not rely on that behavior anymore?
I've modified my extension to implement your workaround. I can download an old version of the extension to test this if you want.
It's ok, I think I've got it now
Change:
"resolved": "https://registry.npmjs.org/pend/-/pend-1.2.0.tgz" } } <ins> }, "windows-mutex": { "version": "0.1.3", "from": "windows-mutex@0.1.3", "dependencies": { "bindings": { "version": "1.2.1", "from": "bindings@>=1.2.1 <2.0.0", "resolved": "https://registry.npmjs.org/bindings/-/bindings-1.2.1.tgz" }, "nan": { "version": "2.1.0", "from": "nan@>=2.1.0 <3.0.0", "resolved": "https://registry.npmjs.org/nan/-/nan-2.1.0.tgz" } } </ins> } } }

Discussion:
This will let the Setup installer not go ahead and perform an update/install if Code is running.
We already have a native app mutex node module which we could use for this.
Change:
import { ITextModel } from 'vs/editor/common/model'; import { IModelService } from 'vs/editor/common/services/model'; import * as nls from 'vs/nls'; <ins> import { IConfigurationService } from 'vs/platform/configuration/common/configuration'; </ins> import { IContextKey, IContextKeyService } from 'vs/platform/contextkey/common/contextkey'; import { IInstantiationService } from 'vs/platform/instantiation/common/instantiation'; import { editorForeground, resolveColorValue } from 'vs/platform/theme/common/colorRegistry';

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. --When replying to a code review comment, the reply editor unconditionally auto-closes brackets. We have had complaints from users about not affecting this behavior (when set to ). We are not 100% convinced that should apply here, since conceptually, editing comments is different from editing code, so a separate setting for comments could be more flexible, but maybe also unnecessarily complex. discusses specifying a on to control other behavior like syntax highlighting (mainly plaintext vs Markdown). Since already supports using per-language settings, it might work well enough to just make also take effect in the comment reply editor.
it seems that only applies to the main editor and not also other editors. Is this expected? I took a look and from what I can see all will respect language configurations for auto closing pairs. It's only when you try to set it something other than that it get's ignored.
I don't know much about that setting, I'd need to debug too.
do you know the answer to
To allow for most flexibility, the code editor doesn't listen to the by itself. That job is always left to the place which instantiates editors. For example, the workbench listens to the and forwards all values to the editor instaces.
Change:
if (injection.filesToCopy) { for (const f of injection.filesToCopy) { await fs.mkdir(path.dirname(f.dest), { recursive: true }); <del> await fs.copyFile(f.source, f.dest); </del> <ins> try { await fs.copyFile(f.source, f.dest); } catch { // Swallow error, this should only happen when multiple users are on the same // machine. Since the shell integration scripts rarely change, plus the other user // should be using the same version of the server in this case, assume the script is // fine if copy fails and swallow the error. } </ins> } } } else {

Discussion:
Type: <bBug</bThe terminal cannot be opened when multiple users use remote-ssh When I used Remote-SSH today, I found that the terminal could not be opened. After checking the log, I found the following error output: Since the terminal I use is , vscode-server copies my to , and the permission of this file belongs to me. As a result, the other users who use as the terminal cannot open the terminal when using Remote-SSH for no permission to overwrite this file. And I find that when the user uses bash, vscode-server does not copy to . Therefore, this bug does not exist when is used by all users VS Code version: Code 1.70.0 (, 2022-08-04T04:38:55.829Z) OS version: Darwin x64 20.6.0 Modes: Remote OS version: Linux x64 5.4.0-122-generic Remote OS version: Linux x64 5.4.0-122-generic <details<summarySystem Info</summary </details<details<summaryExtensions (10)</summaryExtensionVersion ------ pythonsnippets1.0.2 vscode-language-pack-zh-hans1.70. jupyter-keymap1.0.0 remote-containers0.241.3 remote-ssh0.84.0 remote-ssh-edit0.80.0 material-icon-theme4.19.0 svg-preview2.8.3 jinja0.0.8 material-theme3.15.2 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
EDIT: I found the log... I encountered the same problem. When upgrading to 1.70 the zsh shell only opens for the first remote user...
You can find the error log in of , as shown below. <img width="1099" alt="" src="https://user-"After I rolled the software back to the previous version, the issue was solved.
Thx, I found the log also now.

Rolling back to 1.69.2 and disabling auto update of VSCode solves the problem currently... I hope the VSCode team will take care of this issue, for the next release
I tried also to find the line which is copying the file in the script, but was not really able to find it... I believe the command is hidden somewhere in the method
Thanks for the report, you can workaround this by disabling shell integration automatic injection with and then in your :
thanks, your workaround works!
yes thanks, I was having to go back to the previous release until sent me here!
This is fixed in that it will no longer block the terminal from being created, as called out in though we need to make sure that multiple users are able to write the same file. We could perhaps solve this by moving the zsh shell integration files into their own folder in the bundle and just use that?
is this workaround still valid or should we be waiting for an update in vs code?
it's fixed in insider's it's reopened bc of some complications that the fix has caused
Change:
goToSymbol(): void; disableHint(): void; getPosition(id: AccessibleViewProviderId): IPosition | undefined; <del> setPosition(position: IPosition, reveal?: boolean): void; </del> <ins> setPosition(position: IPosition, reveal?: boolean, select?: boolean): void; </ins> getLastPosition(): IPosition | undefined; /** * If the setting is enabled, provides the open accessible view hint as a localized string.

Discussion:
reported by
I am calling here on navigating to the command. On macOS, this works beautifully. I haven't tested on Windows, but am not sure why it wouldn't work the same way there. One reason it wouldn't work for you is if shell integration isn't enabled or activated properly. I know we've seen that happen for you before. do you have any thoughts / can you repro the issue on windows: run some commands in the terminal open the accessible view use alt/opt+up/down arrow to navigate between commands you should hear the commands
It has nothing to do with the shell integration because the cursor actually moves, but the aria alert does not work on Windows.
hi If I follow the steps, I only hear command failed / command succeeded for each command with the corresponding audio cue, and these are actually communicated as screen reader alerts. if I do the same on the mac, I hear the command and the corresponding audio cue for success / failure, but not the command succeeded / command failed message. for the sake of troubleshooting, I disabled the signal announcement on Windows for command succeeded / command failed. After doing that I hear the audio cue only, but not announcement. I did a bit of debugging with NVDA, and the screen reader doesn't seem to be receiving any aria live update event. One easy fix here could be to simply select the text for the command when the cursor moves to previous / next command. That would completely eliminate the need for an aria alert, and would likely work consistently across all platforms.
Thanks so much for troubleshooting I love that idea, will try it tomorrow.
<!-- UNABLETOLOCATECOMMITMESSAGE repo --Issue marked as unreleased but unable to locate closing commit in repo history. If this was closed in a separate repo you can add the label directly, or comment .
I only hear the command status as "command succeeded" or "command failed" but not the command itself.
do you see the command selected? A gif would help
it is not working for me because of this:
Makes sense - this feature is built on shell integration, so that'll have to work to test this
provided a fix for the shell integration. This is verified with that fix.
Change:
}); const sanitizedLink = link.replace(/:d+(:d+)?$/, ''); <del> const results = await this._searchService.fileSearch( this._fileQueryBuilder.file(this._workspaceContextService.getWorkspace().folders, { // Remove optional :row:col from the link as openEditor supports it filePattern: sanitizedLink, maxResults: 2 }) ); // If there was exactly one match, open it if (results.results.length === 1) { </del> <ins> let exactMatch = await this._getExactMatch(sanitizedLink, link); if (exactMatch) { // If there was exactly one match, open it </ins> const match = link.match(/:(d+)?(:(d+))?$/); const startLineNumber = match?.[1]; const startColumn = match?.[3]; await this._editorService.openEditor({ <del> resource: results.results[0].resource, </del> <ins> resource: exactMatch, </ins> options: { pinned: true, revealIfOpened: true,

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: 1.58.2 OS Version: Linux x64 5.4.0-80-generic Steps to Reproduce: open a vscode window open the embedded vscode terminal any file path to a path that exists, but prepended with the uri 'file:///' prefix (example: file:////home/somedir) ctrl+click on that path error message appears: "Unable to open 'somedir': File is a directory The expected behavior (opening the directory in vscode) works for regular paths (/home/somedir)
+1
duplicate of
Can we get a little explanation of how this is a duplicate? Seems completely unrelated. This is incorrect handling of RFC 8089, RFC 3986 links while the other is failure to handle softlinks while using remote ssh. The issue here is file:// schema is treated as if it can only be a file while on the posix path it detects file vs directory.
Can reproduce the problem, it should say folder not file: ! !
Repros on Windows too. Same thing happens in the editor: ! Above should use 3 slashes:
So the link does work (tried it with multiple folders)... but I guess I expected the underline to include the bit. It's a nit and I don't feel too strongly about it, but thought I'd mention. !
let's wait until is back for that. I'm considering this verified for now
Problem is back, looks a little different though: !
I think the new problem is Windows only
Change:
readOnly: true, fontFamily: 'var(--monaco-monospace-font)' }; <ins> this.textModelResolverService.registerTextModelContentProvider(Schemas.accessibleView, this); </ins> this._editorWidget = this._register(this._instantiationService.createInstance(CodeEditorWidget, this._container, editorOptions, codeEditorWidgetOptions)); this._register(this._accessibilityService.onDidChangeScreenReaderOptimized(() => { if (this._currentProvider && this._accessiblityHelpIsShown.get()) {

Discussion:
Testing Repro: "getting started with accessiblity features" second step click on blue button to "open accessible view" results in an error in dev console says that "the editor is not accessible at this time" and advises to turn on screen optimized view, but I already have that on as you can see in status bar item. Version: 1.94.0-insider Commit: Date: 2024-09-24T05:04:12.797Z Electron: 30.5.1 ElectronBuildId: Chromium: 124.0.6367.243 20.16.0 V8: 12.4.254.20-electron.0 OS: Darwin arm64 23.6.0
As part of this flow - I was also confused why a new file is opened after I close the Accessible View: !
I'm getting "the editor is not accessible at this time" messages while moving focus to the Python REPL input box or the Copilot Chat input box !
seems like an issue with the walkthrough accessible view?
this looks an issue with the accessible view editor. I'm seeing a similar issue when I open the chat-panel and request the accessible view.
Change:
}); }); <del> test.skip('ExtensionRecommendationsService: Able to retrieve collection of all ignored recommendations', async () => { </del> <ins> test('ExtensionRecommendationsService: Able to retrieve collection of all ignored recommendations', async () => { </ins> const storageService = instantiationService.get(IStorageService); const workspaceIgnoredRecommendations = ['ms-dotnettools.csharp']; // ignore a stored recommendation and a workspace recommendation.

Discussion:
Cannot reproduce it locally. Will check how often this is failing.
I was able to reproduce this same bug locally with just using the . Reproduction: and select TypeScript (I also used and no ) Open and change the test to only have debugger for tests Output: ! VSCode install version: ! Happy to send along the reproduction project if needed edit: after more exploration, I found that all the other areas of worked. So using instead of is a workaround.+
Change:
return range; } <del> return decorations[0].getActiveRange() ?? undefined; </del> <ins> return (decorations.length > 0 ? (decorations[0].getActiveRange() ?? undefined) : undefined); </ins> } public dispose(): void {

Discussion:
I'm on a mac. setting it to be works though
it started to work the moment I had at least one comment in the editor
did the original keybinding work after you comment? Even before adding a comment I'm seeing the command work.
that keybinding still doesn't work for me (maybe my keyboard or something)...? when I use a different keybinding, it does try to run the command, but I'm now seeing this error. !
I have confirmed that the default keyboard shortcut works on mac: . There's probably something up with your keybindings that's causing this. You could try the "Developer: Toggle Keyboard Shortcuts Troubleshooting" command and see what it outputs. I'm fixing this error though:
Change:
.map(ref => new CheckoutRemoteHeadItem(ref)); const picks = [...heads, ...tags, ...remoteHeads]; <del> const placeHolder = 'Select a ref to checkout'; </del> <ins> const placeHolder = localize('select a ref to checkout', 'Select a ref to checkout'); </ins> const choice = await window.showQuickPick<CheckoutItem>(picks, { placeHolder }); if (!choice) {

Discussion:
It does not currently appear possible to merge local git branches in VS Code. Quite a common workflow is to have a "development" branch to develop new features on (or alternatively have feature specific branches). When the development is finished, the development branch is then merged into the "master" branch before release. This can be done via the integrated terminal, but as VS Code's git implementation is so wizzy, it would be great to be able to replicate this workflow using the GUI.
I can't believe there aren't more for this... what are the current alternatives? An extension, or have you guys set up a task for this?
+1, I think that feature might be considered priority for the git extension, it's a really nice implementation and with merging, would be perfect. No news?
It'd be lovely to be able to trigger a merge from the command palette, e.g. cmd + shift + p Select a branch to merge from via search-dropdown Any opportunity to avoid having to dip back into the command line is lovely. Thanks in advance!
Weird it is still not implemented and even weirder since we can create and change branch. It spoils the git integration in Code as if the feature was unfinished. We can still rely on built-in terminal or extension but it is not a consistent Code workflow Same for git stash
I also would like to see a Git Merge implemented eventually without going in the console. you might be interested to know that there's an open PR to which will hopefully land soon. There's actually also a PR for but changes were asked over a month ago and it wasn't done yet, so it might not land.
Fixed in