jiebi/CodeConvo huggingface dataset:
Code change:
type: 'ptyHost', entryPoint: 'vs/platform/terminal/node/ptyHostMain', execArgv, <ins> args: ['--logsPath', this._environmentMainService.logsHome.fsPath], </ins> env: this._createPtyHostConfiguration(lastPtyId) });

Related discussion:
text: Needs to be fixed to reproduce the issue Repro: log level of "Pty Host" specifically to trace a terminal to verify trace logs show up in pty host channel the restart pty host command a terminal to verify trace logs show up in pty host channel, they don't show up
some help would be appreciated here. When the process is restarted the logging just stops working completely. Here's where the utility process environment is created: Here's the logger initialization on the pty host proc: If you try repro you'll need this change
I can reproduce it.
It seems pty process is creating the log file in a new folder instead in the logs home folder. <img width="386" alt="image" src=""It is because a new folder is getting passed to the pty process from main process. Fixing that would fix this.
Weird. Thanks, I'll look into that
This is causing following regression - only last 5 log sessions are being retained instead of 10. Hence moved it to current milestone and prepared a fix for it.
so the logs do show up, but the terminal doesn't seem to get created correctly - I cannot type in it. EDIT: after restarting the pty host, I cannot type in any of the terminals.
the terminal created before the pty host restarted receives input but does not display it. the one created after it restarted does not receive it.
I don't see this log
I ran it again and now can type in the terminals, but there are no logs happening when I type or create a new terminal !
As long as the regression fixed in is good, this is low priority. Will check it out again in July.
Flaky repro, but sometimes a window might not ack the restart. See the bg window correctly shows the restart and relaunches, but the fg doesn't: <img width="1008" alt="Screenshot 2023-06-30 at 8 02 18 am" src=""Restarting again fixes it, I can't repro any problem with the log not working though.
Weird, when this happens data events aren't getting fired for just one window: !
Code change:
type: 'ptyHost', entryPoint: 'vs/platform/terminal/node/ptyHostMain', execArgv, <ins> args: ['--logsPath', this._environmentMainService.logsHome.fsPath], </ins> env: this._createPtyHostConfiguration(lastPtyId) });

Related discussion:
text: On input in the broken terminal: <img width="747" alt="Screenshot 2023-06-30 at 8 31 15 am" src=""
The 2 windows are connected to 2 different pty hosts: <img width="989" alt="Screenshot 2023-06-30 at 8 38 10 am" src=""
I'm closing this issue off again as the logging problem was fixed in the linked commit. I investigated the problem hit and created some more targeted issues to fix:
Code change:
} } <del> if (typeof anchorElementIndex === 'number') { </del> <ins> if (updateScrollTop && typeof anchorElementIndex === 'number') { </ins> this.scrollTop = this.elementTop(anchorElementIndex) - anchorElementTopDelta!; }

Related discussion:
text: Issue Type: <bBug</bWhen : one mouse wheel scroll in extension view: moves 100px one mouse wheel scroll in settings editor: moves 100px When : one mouse wheel scroll in extension view: moves 100px, with slight animation one mouse wheel scroll in settings editor: moves 15~25px, without animation I'm using a Logitech G502 Lightspeed mouse, without any scrolling tweaking softwares. ! VS Code version: Code - Insiders 1.48.0-insider (, 2020-08-05T05:30:25.429Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </detailsExtensions: none <!-- generated by issue reporter --
I don't see this, any idea
I believe this setting is ignored for macOS. Duplicate of
Actually not a duplicate. Interesting. I need to get my hands on a mouse to see if I can repro.
Created a PR that fixes this:
Code change:
}); } <ins> async function runCommand(instance: ITerminalInstance, commandLine: string, addNewLine: boolean): Promise<void> { // Determine whether to send ETX (ctrl+c) before running the command. This should always // happen unless command detection can reliably say that a command is being entered and // there is no content in the prompt if (instance.capabilities.get(TerminalCapability.CommandDetection)?.hasInput !== false) { await instance.sendText('x03', false); // Wait a little before running the command to avoid the sequences being echoed while the ^C // is being evaluated await timeout(100); } // Use bracketed paste mode only when not running the command await instance.sendText(commandLine, addNewLine, !addNewLine); } </ins> class TerminalOutputProvider implements ITextModelContentProvider { static scheme = 'TERMINAL_OUTPUT';

Related discussion:
text: Repro: in a terminal and select something ! We should hit ctrl+c beforehand () which should work properly on all shells
We should also do this when is clicked in the decoration's context menu
I attempted this in but it was more complicated than I originally anticipated. Moving to backlog.
Code change:
}; function renderHTML(outputInfo: OutputItem, container: HTMLElement): void { <ins> clearContainer(container); </ins> const htmlContent = outputInfo.text(); const element = document.createElement('div'); const trustedHtml = ttPolicy?.createHTML(htmlContent) ?? htmlContent;

Related discussion:
text: Hi ! I am running into an issue issue when using vscode 1.66 : when running pymc models there is a progress bar output which was working fine before the update and now the progress bar simply prints down :( See pic below ! This is how it prints in Jupyter notebooks (anaconda) and it was looking so in vscode 1.65.2 ! Here is the info about my session
Update It actually works when I am not looking ie, I am not in that specific cell of the notebook ¯()/¯ !
Here is a reproducible example: Code: Output: !
I'm having a similar issue using enlighten progressbar. This likely started after a recent vscode update. A new progressbar is printed everytime it updates/redraws. I'm guessing this is the same issue. (This works/prints fine when run using jupyter-notebook on a web browser) !
Thank you for working so fast on this one! Looking forward for the next update/release !
I couldn't verify this fix, using : !
thanks, it's not being picked to the release branch yet.
Works for me too. !
Code change:
"editor.selectionHighlightBackground": "#ADD6FF4D", "editorSuggestWidget.background": "#F3F3F3", "activityBarBadge.background": "#007ACC", <del> "sideBarTitle.foreground": "#6F6F6F" </del> <ins> "sideBarTitle.foreground": "#6F6F6F", "list.hoverBackground": "#e0e0e0" </ins> } }  No newline at end of file

Related discussion:
text: Light themes have relatively low contrast for foreground and hover colors. ideally we do not need to create a new color. Either we can tweak the default list colors which are used for quick pick , SelectBox, Explorer et cetera. Light Default: ! Bad Hover contrast: ! I suggest we increase the contrast for the default listHoverBackground applicable to all users. For the foreground color we could make this slightly darker again for the default. I don't see why we would create new colors either, I think whatever is good for selectBox should be the same and good for the quick pick Tagging this "under discussion" hopefully that is correct.
I finally figured out the listFocusForeground has no default, it's inherited from Monaco-shell. If we define it and listFocusHover in light-defaults we won't create any other colors. Screenshot does not do justice to foreground, you probably want to try it on your own machines. Let me know what you guys think. Below light+ with foreground, hover darkened: foreground === originally hover === # !
can you make a PR for me to try out your suggested color change?
Code change:
throw new Error(nls.localize('restartCode', "Please restart VS Code before reinstalling {0}.", this.manifest.displayName || this.manifest.name)); } } <del> } else { // Remove the extension with same version if it is already uninstalled. // Installing a VSIX extension shall replace the existing extension always. const existingWithSameVersion = await this.unsetIfUninstalled(this.extensionKey); if (existingWithSameVersion) { try { await this.extensionsScanner.removeExtension(existingWithSameVersion, 'existing'); } catch (e) { throw new Error(nls.localize('restartCode', "Please restart VS Code before reinstalling {0}.", this.manifest.displayName || this.manifest.name)); } </del> <ins> } // Remove the extension with same version if it is already uninstalled. // Installing a VSIX extension shall replace the existing extension always. const existingWithSameVersion = await this.unsetIfUninstalled(this.extensionKey); if (existingWithSameVersion) { try { await this.extensionsScanner.removeExtension(existingWithSameVersion, 'existing'); } catch (e) { throw new Error(nls.localize('restartCode', "Please restart VS Code before reinstalling {0}.", this.manifest.displayName || this.manifest.name)); </ins> } }

Related discussion:
text: 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!
Looks like this is working now in the latest VS Code Insiders. Tried with WSL: And using the latest stable (which doesn't have the fix yet) I can repro the errors that describes.
Code change:
super({ id: 'chat.action.focus', title: localize2('actions.interactiveSession.focus', 'Focus Chat List'), <del> precondition: ContextKeyExpr.and(CONTEXT_IN_CHAT_INPUT, CONTEXT_CHAT_LOCATION.isEqualTo(ChatAgentLocation.Panel)), </del> <ins> precondition: ContextKeyExpr.and(CONTEXT_IN_CHAT_INPUT), </ins> category: CHAT_CATEGORY, keybinding: [ // On mac, require that the cursor is at the top of the input, to avoid stealing cmd+up to move the cursor to the top

Related discussion:
text: Testing Repro: /explain in inline chat to get a long response. using to focus the last response (does not work) to focus the last response using to scroll up in list view of chat messages. (does not work)
Same for panel chat. I believe the keybinding simply isn't bound
You may have to press it twice, once to move the cursor to the top of the editor, and then another time to trigger the chat keybinding, does that work? It's working fine for me.
Oh, not in inline chat though
I can't remember what terminal chat looked like in March, do you still want this disabled? I think we probably want it enabled in all chat widgets now:
I fixed this so that cmd+up/down will work in the terminal and inline chat widgets. But in the terminal, once the list is focused, then the arrow keys still navigate history. It looks like the terminal widget is registering a bunch of its own commands for history and for moving focus around. You shouldn't need to do that anymore, since you can use the commands that the ChatWidget has.
Code change:
.pipe(replace('@@UPDATEURL@@', product.updateUrl || '@@UPDATEURL@@')) .pipe(rename('DEBIAN/postinst')); <del> const all = es.merge(control, postinst, postrm, prerm, desktop, appdata, icon, code); </del> <ins> const all = es.merge(control, postinst, postrm, prerm, desktop, desktopUrlHandler, appdata, icon, code); </ins> return all.pipe(vfs.dest(destination)); };

Related discussion:
text: This may be useful as a hint: Please, take a two minutes to look into source, it may work only for :
I think adding a desktop file with that launches VS Code with is what's needed to implement this.
nice relevant gist:
VS Code has native support for opening it's own URL scheme via the hidden argument, I don't think there is a need for wrapper script shenanigans. I'm going to submit a PR.
I've not checked too far into it (Just subscribed to this to keep up to date) but the wrapper script is probably there because in the standard would include the "vscode://" prefix.
That's what should happen, that's what handles. :smiley: You can test if you like. Alternatively you can test this (Which is what the PR adds): For OSS: For release version: Drop it into or and run on that directory.
Code change:
default: true, markdownDescription: localize('interactiveWindow.alwaysScrollOnNewCell', "Automatically scroll the interactive window to show the output of the last statement executed. If this value is false, the window will only scroll if the last cell was already the one scrolled to.") }, <del> [InteractiveWindowSetting.interactiveWindowHotExit]: { </del> <ins> [InteractiveWindowSetting.interactiveWindowRestore]: { </ins> type: 'boolean', default: false, <del> markdownDescription: localize('interactiveWindow.hotExit', "Controls whether the interactive window sessions should be restored when the workspace reloads.") </del> <ins> markdownDescription: localize('interactiveWindow.restore', "Controls whether the Interactive Window sessions/history should be restored across window reloads. Whether the state of controllers used in Interactive Windows is persisted across window reloads are controlled by extensions contributing controllers.") </ins> } } });

Related discussion:
text: Testing microsoft/vscode-jupyter The setting description says that the 'interactive window session' is restored. But after a reload, it seems that the state has been forgotten e.g. Open the interactive window run run prints 9 reload the window the output is restored but running again will show Note that I had to retype print(x) as there was no way to rerun the previously shown cells What's restored seems to be the last output. Maybe the settings description can clarify that?
Code change:
default: true, markdownDescription: localize('interactiveWindow.alwaysScrollOnNewCell', "Automatically scroll the interactive window to show the output of the last statement executed. If this value is false, the window will only scroll if the last cell was already the one scrolled to.") }, <del> [InteractiveWindowSetting.interactiveWindowHotExit]: { </del> <ins> [InteractiveWindowSetting.interactiveWindowRestore]: { </ins> type: 'boolean', default: false, <del> markdownDescription: localize('interactiveWindow.hotExit', "Controls whether the interactive window sessions should be restored when the workspace reloads.") </del> <ins> markdownDescription: localize('interactiveWindow.restore', "Controls whether the Interactive Window sessions/history should be restored across window reloads. Whether the state of controllers used in Interactive Windows is persisted across window reloads are controlled by extensions contributing controllers.") </ins> } } });

Related discussion:
text: Testing microsoft/vscode-jupyter IMO is about restoring a editor with unsaved changes, but the interactiveWindow doesn't seem to have a dirty state. Maybe just call it 'interactiveWindow.restore`? It's actually not really a window ;-)
Good point Martin, I think calling it makes better sense. is a bit ambiguous, we can revisit the name for it in the core when we stabilize the API.
Code change:
import { ElementsDragAndDropData, ListViewTargetSector } from 'vs/base/browser/ui/list/listView'; import { IAsyncDataSource, ITreeContextMenuEvent, ITreeDragAndDrop, ITreeDragOverReaction, ITreeNode, ITreeRenderer, TreeDragOverBubble } from 'vs/base/browser/ui/tree/tree'; import { CollapseAllAction } from 'vs/base/browser/ui/tree/treeDefaults'; <del> import { ActionRunner, IAction } from 'vs/base/common/actions'; </del> <ins> import { ActionRunner, IAction, Separator } from 'vs/base/common/actions'; </ins> import { timeout } from 'vs/base/common/async'; import { CancellationToken, CancellationTokenSource } from 'vs/base/common/cancellation'; import { Codicon } from 'vs/base/common/codicons';

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?: No, issue is with extension contributed context menus. <!-- 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.89.0-insider OS Version: Mac OS X (ARM) Steps to Reproduce: a context menu in Stable and compare it to the same menu in Insiders. I verified the issue reproduces for multiple extensions including GitLens. Stable: <img width="424" alt="image" src=""Insiders: <img width="420" alt="image" src=""
If this is a confirmed regression, it would help to know which change caused it. We maintain a based CLI tool  that automatically downloads and runs previous VS Code insiders and asks for each build if the issue reproduces. It takes up to 8 steps to find exactly the build that caused the regression. Steps: install (if not yet done) follow the instructions until you found the offending build (its fine to leave the commit empty) report back the commit range in this issue Thanks!
Bisect points to My money would be on Reproduces by looking at the context menu of "Commits" when GitLens is installed: !
Code change:
* and searches with the same session object can search the same cache. When the object is garbage-collected, the session is complete and the cache can be cleared. * Please do not store any references to the session object, except via a weak reference (e.g. `WeakRef` or `WeakMap`). */ <del> session: unknown; </del> <ins> session: object; </ins> /** * The maximum number of results to be returned.

Related discussion:
text: a traditional . , listen for debugging the extension, open a file picker, then close it. session token's never gets triggered when the session is done (aka when the file picker is closed) :bug: This contradicts
regression from
Code change:
* and searches with the same session object can search the same cache. When the object is garbage-collected, the session is complete and the cache can be cleared. * Please do not store any references to the session object, except via a weak reference (e.g. `WeakRef` or `WeakMap`). */ <del> session: unknown; </del> <ins> session: object; </ins> /** * The maximum number of results to be returned.

Related discussion:
text: Testing The type cannot be used with because that requires objects (no primitives). We should accommodate for that and change the API accordingly.
Code change:
import { IEditableData } from 'vs/workbench/common/views'; import { TerminalFindWidget } from 'vs/workbench/contrib/terminal/browser/terminalFindWidget'; import { ITerminalStatusList } from 'vs/workbench/contrib/terminal/browser/terminalStatusList'; <ins> import { ScrollPosition } from 'vs/workbench/contrib/terminal/browser/xterm/markNavigationAddon'; </ins> import { ITerminalQuickFixAddon } from 'vs/workbench/contrib/terminal/browser/xterm/quickFixAddon'; import { INavigationMode, IRegisterContributedProfileArgs, IRemoteTerminalAttachTarget, IStartExtensionTerminalRequest, ITerminalBackend, ITerminalConfigHelper, ITerminalFont, ITerminalProcessExtHostProxy } from 'vs/workbench/contrib/terminal/common/terminal'; import { EditorGroupColumn } from 'vs/workbench/services/editor/common/editorGroupColumn';

Related discussion:
text: Notice how for the task terminal it jumps all the way to the top on the first ctrl+up, instead of going to the most recently run task: !
When I run the build task and do cmd + up, the window crashes !
That's even worse
the call to get markers here returns undefined !
I bet the markers are getting disposed of, so deleted from the map in but it looks like that wouldn't even happen since we don't set like we should. Could be why I see the renderer process crash?
Code change:
const os = this._processManager.os || OS; const parsedLinks = detectLinks(text, os); <ins> this._logService.trace('terminalLocaLinkDetector#detect text', text); this._logService.trace('terminalLocaLinkDetector#detect parsedLinks', parsedLinks); </ins> for (const parsedLink of parsedLinks) { // Don't try resolve any links of excessive length if (parsedLink.path.text.length > Constants.MaxResolvedLinkLength) { continue;

Related discussion:
text: <!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --So far, I haven't been able to find any issues around this, but I also haven't found a ton of documentation on this feature either. Basically, I'd like to have finer grained control over how the terminal "word link" auto detection works. This is one of the only comments I was able to find about: Example: In the terminal, I have some output from a compiler that includes relative paths that can be clicked conveniently as an autodetected "word link": Specifically, clicking takes me to the line in question, which is great! However, at some point I tried configuring to include a forward slash (colon has related effects too), e.g. By doing so, the auto-detected file path is no longer clickable, since each path segment is considered as a separate word instead. Notably, the absolute path above is still clickable, but relative paths appear not to be (unless I remove from again). I guess there is probably more than one way to solve this, but a simple solution that comes to mind would be to have a separate config, maybe something like . If null it could fall back to the value, but at least this way it would be possible to configure different separators for double-click selection and link detection. Thanks in advance!
This case is meant to work with the regular non-word link detection as you can see here: <img width="490" alt="Screenshot 2023-05-08 at 6 31 15 am" src="https://user-"This may not work is if the relative path is not relative to the current working directory or you have shell integration disabled (which is provides better cwd detection). In your example is relative to the directory the terminal was currently on? The word links are meant to catch the majority of cases where the verified file links fall through.
Edit: never mind, I think I was testing with the wrong value of as I described in the original issue body :( I did however notice an interesting data point while integration was still disabled: the clickability of the file path seemed inconsistent. Here are a few screenshots showing what I mean (ctrl held in each case): Can't click in a compiler diagnostic, maybe due to the prefix on that line? !