jiebi/CodeConvo huggingface dataset:
Change:
this.lifecycleService.when(LifecyclePhase.Restored).then(() => { this.notificationService.prompt(Severity.Info, localize('extensionsDisabled', "All installed extensions are temporarily disabled. Reload the window to return to the previous state."), [{ label: localize('Reload', "Reload"), <del> // Using ReloadWindowAction because depending on IHostService causes cyclic dependency - #108522 run: () => instantiationService.createInstance(ReloadWindowAction, ReloadWindowAction.ID, ReloadWindowAction.LABEL).run() </del> <ins> run: () => hostService.reload() </ins> }]); }); }

Discussion:
Steps to Reproduce: = workbench does not open From: Workaround:
I think depending on is logically correct. But, in web is depending on other workbench services like --and causing cycle. Not having consistent base services in desktop and web is causing confusion and debt and it might add up as we evolve. I think fixing in is just a patch. To unblock for now, I removed the dependency on and used . Assigning back to you for fixing this in .
Change:
from: 'remote indicator' }); this.commandService.executeCommand(commandId); <ins> quickPick.hide(); </ins> } <del> quickPick.hide(); </del> } }));

Discussion:
Testing After clicking the "Install" entry in the quick pick, there's progress for a few moments, then the quick pick flashes back to showing all the previous entries again, before finally landing on the setup options for the remote extension. !
Change:
this.taskProviderSub = vscode.workspace.registerTaskProvider('typescript', new TscTaskProvider(this.client)); } } <del> } </del>  No newline at end of file <ins> } </ins>

Discussion:
<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.30.2 OS Version: macOS X 10.13.6 (17G4015) Steps to Reproduce: a package with in the file to execute the build task the error (pardon my french): <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes The issue appears to be caused by the being at , resulting in an invalid invocation of . A possible solution might be to append at the end instead of prepending.
I have a fix for this in my fork that I should be able to push a PR for pretty soon (waiting for employee to approve the contrib).
Change:
this.unstickyEditorTabsControl.closeEditor(editor); this.stickyEditorTabsControl.openEditor(editor); <del> this.handlePinnedTabsLayoutChange(); </del> <ins> this.handleTabBarsStateChange(); </ins> } unstickEditor(editor: EditorInput): void { this.stickyEditorTabsControl.closeEditor(editor); this.unstickyEditorTabsControl.openEditor(editor); <del> this.handlePinnedTabsLayoutChange(); </del> <ins> this.handleTabBarsStateChange(); </ins> } setActive(isActive: boolean): void {

Discussion:
Type: <bBug</bfile A from EXPLORER tab with file A file B from EXPLORER -breadcrumb shows file B path (correct) on the pinned tab with file A -breadcrumb shows file B path but should file A This is the minimal case. When I have multiple pinned tabs and open other files, the breadcrump gets more random. UPDATE: Looks like the bug only comes out if this setting is set to true: VS Code version: Code 1.92.2 (, 2024-08-14T17:29:30.058Z) OS version: WindowsNT x64 10.0. Modes: Remote OS version: Linux x64 5.15.153.1-microsoft-standard-WSL2 <details<summarySystem Info</summary </details<details<summaryExtensions (15)</summaryExtensionVersion ------ macos-modern-theme2.3.19 better-cpp-syntax1.27.1 remote-containers0.380.0 remote-ssh0.113.1 remote-ssh-edit0.86.0 remote-wsl0.88.2 vscode-remote-extensionpack0.25.0 remote-explorer0.4.3 remote-server1.5.2 vscode-clangd0.1.29 regionfolder1.0.22 cmake-tools1.18.44 cpptools1.21.6 workspace-include-what-you-use0.0.3 cmake0.0.17 (4 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
This doesn't reproduce for me. Please try without extensions enabled and without custom settings
I turned off extensions and custom settings. I nailed it down to this setting in It appears that the bug is reproducible only if is true.
can you help here? It seems that pinned, extra-row items don't make the call to the breadcrumbs controls, like how it is done for instance for the
Thanks for steps. could you take a look?
Thanks for reporting. When switching to the last previous active tab of the other tab bar it wasn't updating the breadcrumbs. Made a fix
<!-- 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!
Still doesn't work correctly on current insiders version. Version: 1.93.0-insider (user setup) Commit: Date: 2024-08-23T06:45:56.108Z Electron: 30.4.0 ElectronBuildId: Chromium: 124.0.6367.243 20.15.1 V8: 12.4.254.20-electron.0 OS: Windows_NT x64 10.0.
Change:
const line = firstPart.lines[0]; const langId = this.editor.getModel()!.getLanguageIdAtPosition(ghostText.lineNumber, 1); const config = this.languageConfigurationService.getLanguageConfiguration(langId); <del> const r = new RegExp(config.wordDefinition, config.wordDefinition.flags.replace('g', '')); const m = line.match(r); </del> <ins> const wordRegExp = new RegExp(config.wordDefinition.source, config.wordDefinition.flags.replace('g', '')); const m1 = line.match(wordRegExp); </ins> let acceptUntilIndexExclusive = 0; <del> if (m && m.index !== undefined) { if (m.index === 0) { acceptUntilIndexExclusive = m[0].length; </del> <ins> if (m1 && m1.index !== undefined) { if (m1.index === 0) { acceptUntilIndexExclusive = m1[0].length; </ins> } else { <del> acceptUntilIndexExclusive = m.index; </del> <ins> acceptUntilIndexExclusive = m1.index; </ins> } } else { acceptUntilIndexExclusive = line.length; } <ins> const wsRegExp = /s/g; let m2 = wsRegExp.exec(line); if (m2 && m2.index === 0) { m2 = wsRegExp.exec(line); } if (m2 && m2.index !== undefined) { if (m2.index < acceptUntilIndexExclusive) { acceptUntilIndexExclusive = m2.index; } } </ins> const partialText = line.substring(0, acceptUntilIndexExclusive); this.editor.pushUndoStop();

Discussion:
found from TPI: When I am using Typescript, there is a bit of inconsistency with how it defines a "single word". I am not sure if this is intention behavior that I am seeing for which characters get group together or not. For example the chunks for the following text: it is grouped like so: Where is much longer and contains spaces. Not sure what desired behavior is so this could also be expected behavior but wanted to point it out in case there was any inconsistency. Thanks!
This is by design. Either the immediate next word is taken or all the text until the next word. Maybe this should be adjusted, but that depends on how this feature is being used.
Ah yes it makes sense once you explain it. I feel like the is a different thought than maybe the entire . For example if I wanted that line to say then I would have wanted to select through to then type Null instead of selecting then deleting to go back and writing Null. I think either way is fine, it is more just a preference thing and people will quickly adapt to the design as they start using it.
We could additionally split by whitespace, let me reopen this issue for that.
can you verify the fix? Thanks!
Looks great! Thanks for the fix!
Change:
import { IConfigurationService } from 'vs/platform/configuration/common/configuration'; import { CancellationToken } from 'vs/base/common/cancellation'; import { DebugConfigurationProviderTriggerKind } from 'vs/workbench/api/common/extHostTypes'; <ins> import { DebugCompoundRoot } from 'vs/workbench/contrib/debug/common/debugCompoundRoot'; </ins> export const VIEWLET_ID = 'workbench.view.debug';

Discussion:
Ever since I started using the new JS debugger, when running our top level target and then manually closing the code-oss window, the and targets remain: ! Eventually, maybe 1 minute later, the goes away, but the other one stays, I always have to manually disconnect from it. ! cc
This is because is set for the shared process and extension host, which allows them to reconnect when vscode is reloaded. Eventually js-debug in extension host gives up, but the shared process is using the previous Node debugger which doesn't give up. Both these are working as designed, this is kind of a downside of the compound launch configs in that there's no "compound stop".
Yeah, would actually LOVE a compound stop. Could this be a feature of compounds, & Meaning, if something like was set in the compound, all targets would share the same action, and I would see no actions.
We could add a attribute to the compound, however how would that work? Clicking stop on any of the compound sessions would send stop to all sessions? And it would never be rendered as dicsonnect?
Maybe compound launch configs could have a pseudo-root, which has a "stop" action that affects all individual configs? ` The compound config could have an option whether sessions can be stopped individually, or whether stopping one session is treated as stopping the whole set of configuration.
ok makes somewhat sense, the flaw of my proposel is that once compound starts 4 sessions those sessions are not related in any way. So adding a pseudo root might be smart. The pseudo root would not be rendered, and the pseudo root would remember the attribute. Here are code pointers for a PR. We should add the attribute and to the schema . Code pointer for the debug session to add the pseudo root stopAll smartness
I like both options.
This bug has been fixed in to 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 pallette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Please let's have the bot not do this for ourselves.
BTW, the bot's wording sounds wrong: in to the latest...
Much better, and I this attribute to our compound config. But the behavior partly confuses me and I opened
Change:
import { TPromise } from 'vs/base/common/winjs.base'; import { Emitter, debounceEvent } from 'vs/base/common/event'; import { ITerminalInstance } from 'vs/workbench/parts/terminal/common/terminal'; <del> import XTermTerminal = require('xterm'); </del> <ins> import { Terminal as XTermTerminal } from 'xterm'; </ins> const SHELL_EXECUTABLES = ['cmd.exe', 'powershell.exe', 'bash.exe'];

Discussion:
Upstream issue: Please verify this on Linux by opening tmux in mouse mode and ensuring regular mouse selection triggers "tmux selection" and shift+mouse selection triggers the regular terminal selection.
I thought I verified this last month?
this was Mac only last month, needs verification on Linux.

Scrolling within the integrated terminal doesn't scroll curses interfaces such as , , , etc. <!-- Use Help Report Issues to prefill these. --- VSCode Version: Version 1.15.0 OS Version: Arch Linux Shell: ZSH (oh-my-zsh) the integrated terminal ( ``) a curses style pager interface (e.g. , , , ) the mouse scrollwheel to try and scroll the pager happens, using keyboard commands to scroll works fine (, , , , arrow keys, etc) a seperate terminal (e.g. or ) step 2 & 3 above as expected; pager scrolls <!-- Launch with to check. --Reproduces without extensions: Yes
This should be fixed in the next version. Note that this only applies to applications that launch the alt buffer however, so it does not apply to . Upstream issue:
Sounds like the upstream issue might be a different one to this. It appears to be about the alternative buffer being rendered twice after a scroll. This is about passing scroll events to pager style programs, such as less and git log.
The reason scroll isn't making it to the terminal app is because the scrollbar is grabbing the event and not passing it to the terminal. When there is no scrollback it gets sent to the terminal correctly.
It works in tmux fine now but not vim yet.
This has been working for a few versions now
Change:
description: 'test', before: { content: 'bar' <del> } </del> <ins> }, showIfCollapsed: true </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. --Currently, the inlay hints will clean and shows again as scheduler's strategy. It's might not friendly if you are editing some line who has many hints. I have an idea: Clean all hints where the cursor’s line when we are editing the code and append new hints by the scheduler. I think It's might improve the experience about inlay hints.
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.494 --<!-- potentialduplicatescomment --
/gifPlease
!
I think inlay hints should disappear immediately if the surrounding text is deleted. Afaik, currently, when text gets deleted, decorations inside of that text get collapsed but are not deleted.
Yes, I agree that hints should disappear immediately when their "anchor" position is removed. Maybe it's not so easy to know what remove actually means in this case. Arguably this is an editor bug as I was expecting this to work?
I wouldn't call this a bug - decorations are never removed automatically. Alex suggests (I asked him before his vacation): I also suggest to extend the inlay hints API so that a hint refers to a range. The hint itself then can either be after or before the range. The range allows to better predict what should happen with the hint if the text changes. With injected text, we now have two cursor stops around inlay hints - both refer to the same model position. Maybe the move behavior of inlay text should depend on the view position where the text change was caused from? I suggest to think about how we can better predict synchronously how a text change affects inlay hints.
This is how we started, mostly to optionally support overlay hints, and everyone was confused about ranges for inlay hints. Using a range with before/after screams "position" and I don't want to leak an implementation detail into the API. We would also still have the case of empty ranges... I'd rather create "fake ranges" from positions so that I can use the notion of collapsed ranges.
I have pushed a change () to use the range of touching words of inlay positions (when possible).

In that case will be and my expectation was that decorations hide/disappear when removing all their text.. is that a bug in decorations land or am I using this wrong? Should I listen to decoration changes and "manually" remove them?
I think so, decorations are not removed automatically.
But what does mean then?
Ah, maybe I forgot to consider that flag for injected text, I'll look into it tomorrow.
Change:
let tracer = SdkTracerProvider::builder().build().tracer("codecli"); let mut log = log::Logger::new(tracer, log_level); if let Some(f) = &core.global_options.log_to_file { <del> log = log.tee(log::FileLogSink::new(log_level, f).expect("expected to make file logger")) </del> <ins> log = log .with_sink(log::FileLogSink::new(log_level, f).expect("expected to make file logger")) </ins> } log

Discussion:
opens in a window instead of running in background. I have seen , which introduced this behavior. For me, means . Console window breaks it completely. If the window is closed - service is gone, what shouldn't happen. I understand that there were reasons about changing service behavior to ordinary application. However, I would really like service-like functionality back for my remote development. It's perfectly fine if this would be an additional installation flag. That would keep current easy behavior and allow for unattended installs. <!-- 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.78.2 (System) OS Version: Windows 11 22H2 Steps to Reproduce:
Sorry, misread. Will look at that
I believe this issue is only partially fixed, even in . The window does not appear when only or (the cli) is running, however, as soon as a tunnel is connected to, a window appears (as code- is run). If the user closes the window, the tunnel connection is dropped. I believe the fix is to pass to creationflags in as seen here: However, without the proprietary "mixin" , it seems my builds of code cli are not able to properly run code-server, failing with To reproduce the issue, on a windows machine: an arbitrary tunnel to authorize the machine: the tunnel with the code at the tunnel service with connect to the tunnel again a on the desktop, close it and observe the tunnel disconnect on
Change:
await this.clipboardService.writeText(this.getVisibleContent()); return Promise.resolve(); })); <ins> actions.push(new Action('debug.replPaste', localize('paste', "Paste"), undefined, true, async () => { const clipboardText = await this.clipboardService.readText(); if (clipboardText) { this.replInput.setValue(this.replInput.getValue().concat(clipboardText)); } })); </ins> actions.push(new Action('debug.collapseRepl', localize('collapse', "Collapse All"), undefined, true, () => { this.tree.collapseAll(); this.replInput.focus();

Discussion:
! VSCode Version: 1.46 Steps to Reproduce: the debug debug console -click inside the console view There should be an option to paste text. Currently, pasting is only allowed when right-clicking the very narrow text input area. The debug console should be more similar to the terminal, which allows for right-click pasting anywhere. Does this issue occur when all extensions are disabled?: Yes/No
I like this idea and makes perfect sense. We are open for a PR that fixes this Code pointer You would simply need to create a new action that uses a clipboardService to read what is in the clipboard and write it in the
I'd like to take this on, Is that OK?
Yes it is ok. Thanks
Just to confirm, is this the expected behaviour, or is the idea that it would overwrite the input field, instead of appending the pasted text to what's already there?
This is what I had in mind. Pasting to the input field by right clicking the debug console.
Correct, this is also what I had in mind. Thanks!
Verifying... After a right-click "Paste" from the upper part of the "Debug Console" (which cannot receive keyboard input), the focus stays on that part (which is pretty useless). The focus should be transferred to the bottom text box so that I can just press return to execute the pasted command. The "Clear Console" command transfers the focus correctly. When no debug session is running, it is not possible to type into the bottom text box of the debug console. But pasting the clipboard is allowed. This is inconsistent.
good catch. Pushed a fix.
Yeah let's also disable the action when debug session is not running.
Change:
getAriaLabel(element: IDisassembledInstructionEntry): string | null { let label = ''; <del> if (element.isBreakpointSet) { label += localize('breakpointIsSet', "Breakpoint is set"); } else if (element.allowBreakpoint) { label += localize('breakpointAllowed', "Can set breakpoint"); } </del> const instruction = element.instruction; <del> label += `, ${localize('instructionAddress', "Instruction address")}: ${instruction.address}`; </del> <ins> label += `${localize('instructionAddress', "Address")}: ${instruction.address}`; </ins> if (instruction.instructionBytes) { <del> label += `, ${localize('instructionBytes', "Instruction bytes")}: ${instruction.instructionBytes}`; </del> <ins> label += `, ${localize('instructionBytes', "Bytes")}: ${instruction.instructionBytes}`; </ins> } label += `, ${localize(`instructionText`, "Instruction")}: ${instruction.instruction}`;

Discussion:
Testing disassembly view on screen reader on an element, notice the following being read out "Can set breakpoint, Instruction address: 0x000000ea, Instruction: of" We need to imrpove this aria label: most important piece of information needs to go first, so that blind users can skip the boring repetitive part. So start with the "0x000000ea address, " it more concise, I think "can set breakpoint" is not needed here do not understand the last part "intruction: of", this needs to be fixed I think
will fix this.
Is there a way to update aria label via accessibility provider? Looks like it's set only when the element is rendered? I'm wondering if we can add/remove all texts about breakpoint and stack frame. If not, we should probably remove texts related to breakpoints. Also, it's a great suggestion that we should reduce the amount of duplicates. So I'll change it to . As for , it's likely the disassembly instruction you are looking at is . For now, each line in disassembly view looks like: Where there may not be InstructionBytes. For example, Will have aria label (currently) .
no, it is not possible to dynamically update the aria label. This sounds good, I would just cut it short to be