Question:
a folder/workspace that contains a git repository a topic branch changes to main and the topic branch that would result in a merge conflict main into the topic branch to get a conflict Expected: commit action button is disabled Actual: commit action button is enabled
The button is now disabled while merging is in progress, but the button and the dropdown both take on a background color when clicked, which was confusing to me: !
Also, while the commit action button is disabled, the commit button above the input box is not: !
That is expected. At the moment the enablement is only toggled for the commit action button and not the commit action in the toolbar.
This is currently being tracked as

private disposables: Disposable[] = []; constructor(readonly repository: Repository) { <del> this._state = { HEAD: undefined, isCommitInProgress: false, isSyncInProgress: false, repositoryHasChanges: false }; </del> <ins> this._state = { HEAD: undefined, isCommitInProgress: false, isMergeInProgress: false, isSyncInProgress: false, repositoryHasChanges: false }; </ins> repository.onDidRunGitStatus(this.onDidRunGitStatus, this, this.disposables); repository.onDidChangeOperations(this.onDidChangeOperations, this, this.disposables);


Question:
a folder/workspace that contains a git repository a topic branch changes to main and the topic branch that would result in a merge conflict main into the topic branch to get a conflict Expected: commit action button is disabled Actual: commit action button is enabled
The button is now disabled while merging is in progress, but the button and the dropdown both take on a background color when clicked, which was confusing to me: !
Also, while the commit action button is disabled, the commit button above the input box is not: !
That is expected. At the moment the enablement is only toggled for the commit action button and not the commit action in the toolbar.
This is currently being tracked as

}, ] ], <del> enabled: this.state.repositoryHasChanges && !this.state.isCommitInProgress </del> <ins> enabled: this.state.repositoryHasChanges && !this.state.isCommitInProgress && !this.state.isMergeInProgress </ins> }; }


Question:
a folder/workspace that contains a git repository a topic branch changes to main and the topic branch that would result in a merge conflict main into the topic branch to get a conflict Expected: commit action button is disabled Actual: commit action button is enabled
The button is now disabled while merging is in progress, but the button and the dropdown both take on a background color when clicked, which was confusing to me: !
Also, while the commit action button is disabled, the commit button above the input box is not: !
That is expected. At the moment the enablement is only toggled for the commit action button and not the commit action in the toolbar.
This is currently being tracked as

const config = workspace.getConfiguration('git', Uri.file(this.repository.root)); const showActionButton = config.get<{ publish: boolean }>('showActionButton', { publish: true }); <del> // Branch does have an upstream, commit is in progress, or the button is disabled if (this.state.HEAD?.upstream || this.state.isCommitInProgress || !showActionButton.publish) { return undefined; } </del> <ins> // Branch does have an upstream, commit/merge is in progress, or the button is disabled if (this.state.HEAD?.upstream || this.state.isCommitInProgress || this.state.isMergeInProgress || !showActionButton.publish) { return undefined; } </ins> return { command: {


Question:
a folder/workspace that contains a git repository a topic branch changes to main and the topic branch that would result in a merge conflict main into the topic branch to get a conflict Expected: commit action button is disabled Actual: commit action button is enabled
The button is now disabled while merging is in progress, but the button and the dropdown both take on a background color when clicked, which was confusing to me: !
Also, while the commit action button is disabled, the commit button above the input box is not: !
That is expected. At the moment the enablement is only toggled for the commit action button and not the commit action in the toolbar.
This is currently being tracked as

const config = workspace.getConfiguration('git', Uri.file(this.repository.root)); const showActionButton = config.get<{ sync: boolean }>('showActionButton', { sync: true }); <del> // Branch does not have an upstream, commit is in progress, or the button is disabled if (!this.state.HEAD?.upstream || this.state.isCommitInProgress || !showActionButton.sync) { return undefined; } </del> <ins> // Branch does not have an upstream, commit/merge is in progress, or the button is disabled if (!this.state.HEAD?.upstream || this.state.isCommitInProgress || this.state.isMergeInProgress || !showActionButton.sync) { return undefined; } </ins> const ahead = this.state.HEAD.ahead ? ` ${this.state.HEAD.ahead}$(arrow-up)` : ''; const behind = this.state.HEAD.behind ? ` ${this.state.HEAD.behind}$(arrow-down)` : '';


Question:
a folder/workspace that contains a git repository a topic branch changes to main and the topic branch that would result in a merge conflict main into the topic branch to get a conflict Expected: commit action button is disabled Actual: commit action button is enabled
The button is now disabled while merging is in progress, but the button and the dropdown both take on a background color when clicked, which was confusing to me: !
Also, while the commit action button is disabled, the commit button above the input box is not: !
That is expected. At the moment the enablement is only toggled for the commit action button and not the commit action in the toolbar.
This is currently being tracked as

this.state = { ...this.state, HEAD: this.repository.HEAD, <ins> isMergeInProgress: this.repository.mergeGroup.resourceStates.length !== 0, </ins> repositoryHasChanges: this.repository.indexGroup.resourceStates.length !== 0 || <del> this.repository.mergeGroup.resourceStates.length !== 0 || </del> this.repository.untrackedGroup.resourceStates.length !== 0 || this.repository.workingTreeGroup.resourceStates.length !== 0 };


Question:
See the grey row that moves up when it scrolls !
I looked into this a bit, but is this something that is within the tree code? Nothing sticks out to be surrounding us registering the drag and drop handlers when it comes to a focus, or hover rendering
The grey row is the CSS state which stays enabled throughout a native DnD, but stuck in the same position the event fired. It's arguably a browser bug. But we can eat it as a list bug. I see no other way than to disable the hover decoration while the list is being dragged from. Having both and labels is a bit confusing. Those are mutually exclusive.
Oh I always used polish to indicate something that is a small change (at least to the user) and then it's a bug because it shouldn't happen . Idk, I guess I'll stick with just bug

setTimeout(() => document.body.removeChild(dragImage), 0); } <ins> this.domNode.classList.add('dragging'); </ins> this.currentDragData = new ElementsDragAndDropData(elements); StaticDND.CurrentDragAndDropData = new ExternalElementsDragAndDropData(elements);


Question:
See the grey row that moves up when it scrolls !
I looked into this a bit, but is this something that is within the tree code? Nothing sticks out to be surrounding us registering the drag and drop handlers when it comes to a focus, or hover rendering
The grey row is the CSS state which stays enabled throughout a native DnD, but stuck in the same position the event fired. It's arguably a browser bug. But we can eat it as a list bug. I see no other way than to disable the hover decoration while the list is being dragged from. Having both and labels is a bit confusing. Those are mutually exclusive.
Oh I always used polish to indicate something that is a small change (at least to the user) and then it's a bug because it shouldn't happen . Idk, I guess I'll stick with just bug

const dragData = this.currentDragData; this.teardownDragAndDropScrollTopAnimation(); this.clearDragOverFeedback(); <ins> this.domNode.classList.remove('dragging'); </ins> this.currentDragData = undefined; StaticDND.CurrentDragAndDropData = undefined;


Question:
See the grey row that moves up when it scrolls !
I looked into this a bit, but is this something that is within the tree code? Nothing sticks out to be surrounding us registering the drag and drop handlers when it comes to a focus, or hover rendering
The grey row is the CSS state which stays enabled throughout a native DnD, but stuck in the same position the event fired. It's arguably a browser bug. But we can eat it as a list bug. I see no other way than to disable the hover decoration while the list is being dragged from. Having both and labels is a bit confusing. Those are mutually exclusive.
Oh I always used polish to indicate something that is a small change (at least to the user) and then it's a bug because it shouldn't happen . Idk, I guess I'll stick with just bug

this.canDrop = false; this.teardownDragAndDropScrollTopAnimation(); this.clearDragOverFeedback(); <ins> this.domNode.classList.remove('dragging'); </ins> this.currentDragData = undefined; StaticDND.CurrentDragAndDropData = undefined;


Question:
See the grey row that moves up when it scrolls !
I looked into this a bit, but is this something that is within the tree code? Nothing sticks out to be surrounding us registering the drag and drop handlers when it comes to a focus, or hover rendering
The grey row is the CSS state which stays enabled throughout a native DnD, but stuck in the same position the event fired. It's arguably a browser bug. But we can eat it as a list bug. I see no other way than to disable the hover decoration while the list is being dragged from. Having both and labels is a bit confusing. Those are mutually exclusive.
Oh I always used polish to indicate something that is a small change (at least to the user) and then it's a bug because it shouldn't happen . Idk, I guess I'll stick with just bug

} if (styles.listHoverBackground) { <del> content.push(`.monaco-list${suffix}:not(.drop-target) .monaco-list-row:hover:not(.selected):not(.focused) { background-color: ${styles.listHoverBackground}; }`); </del> <ins> content.push(`.monaco-list${suffix}:not(.drop-target):not(.dragging) .monaco-list-row:hover:not(.selected):not(.focused) { background-color: ${styles.listHoverBackground}; }`); </ins> } if (styles.listHoverForeground) { <del> content.push(`.monaco-list${suffix} .monaco-list-row:hover:not(.selected):not(.focused) { color:  ${styles.listHoverForeground}; }`); </del> <ins> content.push(`.monaco-list${suffix}:not(.drop-target):not(.dragging) .monaco-list-row:hover:not(.selected):not(.focused) { color:  ${styles.listHoverForeground}; }`); </ins> } if (styles.listSelectionOutline) {


Question:
Lately (since a few days) I see the explorer show an expand all icon even though some folders are expanded (in a multi root workspace): <img width="300" alt="image" src="https://user-"This must be a recent regression, not sure if in explorer or tree widget.
See
This breaks my muscle memory, I always collapse the explorer to start a new task and the new behaviour breaks this. I really see no value of this new behaviour? It is not even expanding all folders, only the ones that can be resolved? What is the use case?
As a suggestion: only show the expand button when really all nodes are collapsed, but keep the collapse button when any node is expanded.
I'm with this is quite different behavior in a multi-root workspace, I have one workspace with 5 root folders and another with 10+, prior to this change clicking the expand/collapse button in explorer would collapse all the folders in each root folder, clicking again would then collapse all the root folders. What I get now is the following: If all root folders are collapsed, clicking the expand/collapse button does nothing If one root folder is open the expand/collapse button expands and collapses folders within that root folder More than one root folder open the same as before for all of the open root folders Perhaps we could have an option to opt-in to this new behavior, I can't think of a single reason why I would want to expand every folder in a project.
Feature got removed.

listDropBackground?: Color; } <del> // Accepts a single or multiple workspace folders function hasExpandedRootChild(tree: WorkbenchCompressibleAsyncDataTree<ExplorerItem | ExplorerItem[], ExplorerItem, FuzzyScore>, treeInput: ExplorerItem | ExplorerItem[]): boolean { const inputsToCheck = []; if (Array.isArray(treeInput)) { inputsToCheck.push(...treeInput.filter(folder => tree.hasNode(folder) && !tree.isCollapsed(folder))); } else { inputsToCheck.push(treeInput); } for (const folder of inputsToCheck) { for (const [, child] of folder.children.entries()) { if (tree.hasNode(child) && tree.isCollapsible(child) && !tree.isCollapsed(child)) { return true; </del> <ins> function hasExpandedRootChild(tree: WorkbenchCompressibleAsyncDataTree<ExplorerItem | ExplorerItem[], ExplorerItem, FuzzyScore>, treeInput: ExplorerItem[]): boolean { for (const folder of treeInput) { if (tree.hasNode(folder) && !tree.isCollapsed(folder)) { for (const [, child] of folder.children.entries()) { if (tree.hasNode(child) && tree.isCollapsible(child) && !tree.isCollapsed(child)) { return true; } </ins> } } } <ins> return false; } /** * Whether or not any of the nodes in the tree are expanded */ function hasExpandedNode(tree: WorkbenchCompressibleAsyncDataTree<ExplorerItem | ExplorerItem[], ExplorerItem, FuzzyScore>, treeInput: ExplorerItem[]): boolean { for (const folder of treeInput) { if (tree.hasNode(folder) && !tree.isCollapsed(folder)) { return true; } } </ins> return false; }


Question:
Lately (since a few days) I see the explorer show an expand all icon even though some folders are expanded (in a multi root workspace): <img width="300" alt="image" src="https://user-"This must be a recent regression, not sure if in explorer or tree widget.
See
This breaks my muscle memory, I always collapse the explorer to start a new task and the new behaviour breaks this. I really see no value of this new behaviour? It is not even expanding all folders, only the ones that can be resolved? What is the use case?
As a suggestion: only show the expand button when really all nodes are collapsed, but keep the collapse button when any node is expanded.
I'm with this is quite different behavior in a multi-root workspace, I have one workspace with 5 root folders and another with 10+, prior to this change clicking the expand/collapse button in explorer would collapse all the folders in each root folder, clicking again would then collapse all the root folders. What I get now is the following: If all root folders are collapsed, clicking the expand/collapse button does nothing If one root folder is open the expand/collapse button expands and collapses folders within that root folder More than one root folder open the same as before for all of the open root folders Perhaps we could have an option to opt-in to this new behavior, I can't think of a single reason why I would want to expand every folder in a project.
Feature got removed.

this.tree.domFocus(); } <del> const treeInput = this.tree.getInput(); if (Array.isArray(treeInput)) { treeInput.forEach(folder => { folder.children.forEach(child => this.tree.hasNode(child) && this.tree.expand(child, true)); }); return; } </del> this.tree.expandAll(); }


Question:
Lately (since a few days) I see the explorer show an expand all icon even though some folders are expanded (in a multi root workspace): <img width="300" alt="image" src="https://user-"This must be a recent regression, not sure if in explorer or tree widget.
See
This breaks my muscle memory, I always collapse the explorer to start a new task and the new behaviour breaks this. I really see no value of this new behaviour? It is not even expanding all folders, only the ones that can be resolved? What is the use case?
As a suggestion: only show the expand button when really all nodes are collapsed, but keep the collapse button when any node is expanded.
I'm with this is quite different behavior in a multi-root workspace, I have one workspace with 5 root folders and another with 10+, prior to this change clicking the expand/collapse button in explorer would collapse all the folders in each root folder, clicking again would then collapse all the root folders. What I get now is the following: If all root folders are collapsed, clicking the expand/collapse button does nothing If one root folder is open the expand/collapse button expands and collapses folders within that root folder More than one root folder open the same as before for all of the open root folders Perhaps we could have an option to opt-in to this new behavior, I can't think of a single reason why I would want to expand every folder in a project.
Feature got removed.

if (treeInput === undefined) { return; } <del> this.viewHasSomeCollapsibleRootItem.set(hasExpandedRootChild(this.tree, treeInput)); </del> <ins> const treeInputArray = Array.isArray(treeInput) ? treeInput : Array.from(treeInput.children.values()); // Has collapsible root when anything is expanded this.viewHasSomeCollapsibleRootItem.set(hasExpandedNode(this.tree, treeInputArray)); </ins> } styleListDropBackground(styles: IExplorerViewStyles): void {


Question:
to start the default build ! This happened right after something strange, which might be the underlying cause. I had the build running already, the one with two terminals open. But I still pressed and noticed another two terminals showed up with the same build tasks! I closed them all. Then I pressed and ended up where the screenshot above shows. cc
I reloaded, then pressed before the workbench was done loading and got this: ! I waited a bit more, pressed it again and it worked. This is very likely a separate issue, so feel free to treat it as such.
might be a bug with the new reconnect?
Yeah I think I saw this once
That's exactly right. Steps: selfhost setup Shift B, you now have 2 build commands running VS Code VS Code, you still have 2 build commands running Shift B, You now have 4 build commands running.
C the old ones The new ones appear loading, even though they have finished compilation: ! Worse: the window horizontally, and eventually you'll get lucky and the spinning icons dissappear: !
it's not a new bug that you can launch tasks that are already running
If you press you should get the default build tasks, which are long running. If you press it again, they shouldn't be launched again and they aren't. This is good and expected. The bug is: restart Code (tasks now get restored), press and you'll get the same build tasks running again. This shouldn't happen: !
same root cause as , which is not new
This is my selfhost setup. I am 100% sure this is new.
the two bugs that you've identified here though are: the error about a terminal group command not found was already aware that statuses do not work after reload
in your old setup, run ctrl shift b, ctrl shift b again. you'll get 4
in stable !
I think you are correct it's a different issue. I see what's going on now.
might still be the same root cause, but i'll try to investigate for a bit
Thanks
could you pls verify this is fixed for you in insider's keeping in mind these two that I have a PR out to fix as well?
Sorry for reopening but I could still repro in today's build () very likely due to the . !
This is happening because this conditional is entered on ctrl+shift+b after reload: Looks like isn't restored on reconnect: !
The task has the wrong id? !
is persisted as a guid, not the expected string? !
It's the custom task with the same label that gets the uuid:
ends up returning true, that's why _id ends up as a uuid: The task's type is undefined after reconnection. It's mean to be , this is what it's meant to be: !
Note that this only reproduce for compound tasks.
That was a journey and I'm ready to throw in the towel for now. I believe the issue is either compound task state is not restored properly after reconnect here: And/or the recently used tasks cached value does not contain all recently used tasks as I only see the compound and Core - Build, no Ext - Build.
any thoughts would be appreciated. I spent ~ 3 hours on this and Daniel did as well.
I will take some time tomorrow to dig into it.
Some notes from debugging: When comparing tasks that come out of the recently used task list, they must be compared by their recently used key as this is the only stable id value (map key and task id can change). Instead of having a separate code path for reconnect, which is what is causing some state to be lost (like the ), if possible, it would be better to try the reconnect in the same place that we currently create a terminal. This would hook up all the needed state again and re-attach problem matchers. I've made an example PR here that starts to address the above points. Note that this is relatively untested, I just checked whether it fixes the problem described in this issue. Other notes: Using the recent tasks from the task service for re-connecting is problematic since users can use to entirely disable recent tasks. Instead, you will probably need a separate LRU that functions exactly like but is only used for reconnection. Tangentially related: you also need to nudge/rerun problem matchers on terminal lines that have already been written so that they can find their start pattern and the task doesn't have a spinner forever.

private _terminals: IStringDictionary<ITerminalData>; private _idleTaskTerminals: LinkedMap<string, string>; private _sameTaskTerminals: IStringDictionary<string>; <ins> private _terminalForTask: ITerminalInstance | undefined; </ins> private _taskSystemInfoResolver: ITaskSystemInfoResolver; private _lastTask: VerifiedTask | undefined; // Should always be set in run


Question:
to start the default build ! This happened right after something strange, which might be the underlying cause. I had the build running already, the one with two terminals open. But I still pressed and noticed another two terminals showed up with the same build tasks! I closed them all. Then I pressed and ended up where the screenshot above shows. cc
I reloaded, then pressed before the workbench was done loading and got this: ! I waited a bit more, pressed it again and it worked. This is very likely a separate issue, so feel free to treat it as such.
might be a bug with the new reconnect?
Yeah I think I saw this once
That's exactly right. Steps: selfhost setup Shift B, you now have 2 build commands running VS Code VS Code, you still have 2 build commands running Shift B, You now have 4 build commands running.
C the old ones The new ones appear loading, even though they have finished compilation: ! Worse: the window horizontally, and eventually you'll get lucky and the spinning icons dissappear: !
it's not a new bug that you can launch tasks that are already running
If you press you should get the default build tasks, which are long running. If you press it again, they shouldn't be launched again and they aren't. This is good and expected. The bug is: restart Code (tasks now get restored), press and you'll get the same build tasks running again. This shouldn't happen: !
same root cause as , which is not new
This is my selfhost setup. I am 100% sure this is new.
the two bugs that you've identified here though are: the error about a terminal group command not found was already aware that statuses do not work after reload
in your old setup, run ctrl shift b, ctrl shift b again. you'll get 4
in stable !
I think you are correct it's a different issue. I see what's going on now.
might still be the same root cause, but i'll try to investigate for a bit
Thanks
could you pls verify this is fixed for you in insider's keeping in mind these two that I have a PR out to fix as well?
Sorry for reopening but I could still repro in today's build () very likely due to the . !
This is happening because this conditional is entered on ctrl+shift+b after reload: Looks like isn't restored on reconnect: !
The task has the wrong id? !
is persisted as a guid, not the expected string? !
It's the custom task with the same label that gets the uuid:
ends up returning true, that's why _id ends up as a uuid: The task's type is undefined after reconnection. It's mean to be , this is what it's meant to be: !
Note that this only reproduce for compound tasks.
That was a journey and I'm ready to throw in the towel for now. I believe the issue is either compound task state is not restored properly after reconnect here: And/or the recently used tasks cached value does not contain all recently used tasks as I only see the compound and Core - Build, no Ext - Build.
any thoughts would be appreciated. I spent ~ 3 hours on this and Daniel did as well.
I will take some time tomorrow to dig into it.
Some notes from debugging: When comparing tasks that come out of the recently used task list, they must be compared by their recently used key as this is the only stable id value (map key and task id can change). Instead of having a separate code path for reconnect, which is what is causing some state to be lost (like the ), if possible, it would be better to try the reconnect in the same place that we currently create a terminal. This would hook up all the needed state again and re-attach problem matchers. I've made an example PR here that starts to address the above points. Note that this is relatively untested, I just checked whether it fixes the problem described in this issue. Other notes: Using the recent tasks from the task service for re-connecting is problematic since users can use to entirely disable recent tasks. Instead, you will probably need a separate LRU that functions exactly like but is only used for reconnection. Tangentially related: you also need to nudge/rerun problem matchers on terminal lines that have already been written so that they can find their start pattern and the task doesn't have a spinner forever.

this._reconnectToTerminals(terminals); } if (this._tasksToReconnect.includes(task._id)) { <del> this._lastTask = new VerifiedTask(task, resolver, trigger); this.rerun(); </del> <ins> this._terminalForTask = terminals.find(t => t.shellLaunchConfig.attachPersistentProcess?.task?.id === task._id); this.run(task, resolver, trigger); </ins> } return undefined; }


Question:
to start the default build ! This happened right after something strange, which might be the underlying cause. I had the build running already, the one with two terminals open. But I still pressed and noticed another two terminals showed up with the same build tasks! I closed them all. Then I pressed and ended up where the screenshot above shows. cc
I reloaded, then pressed before the workbench was done loading and got this: ! I waited a bit more, pressed it again and it worked. This is very likely a separate issue, so feel free to treat it as such.
might be a bug with the new reconnect?
Yeah I think I saw this once
That's exactly right. Steps: selfhost setup Shift B, you now have 2 build commands running VS Code VS Code, you still have 2 build commands running Shift B, You now have 4 build commands running.
C the old ones The new ones appear loading, even though they have finished compilation: ! Worse: the window horizontally, and eventually you'll get lucky and the spinning icons dissappear: !
it's not a new bug that you can launch tasks that are already running
If you press you should get the default build tasks, which are long running. If you press it again, they shouldn't be launched again and they aren't. This is good and expected. The bug is: restart Code (tasks now get restored), press and you'll get the same build tasks running again. This shouldn't happen: !
same root cause as , which is not new
This is my selfhost setup. I am 100% sure this is new.
the two bugs that you've identified here though are: the error about a terminal group command not found was already aware that statuses do not work after reload
in your old setup, run ctrl shift b, ctrl shift b again. you'll get 4
in stable !
I think you are correct it's a different issue. I see what's going on now.
might still be the same root cause, but i'll try to investigate for a bit
Thanks
could you pls verify this is fixed for you in insider's keeping in mind these two that I have a PR out to fix as well?
Sorry for reopening but I could still repro in today's build () very likely due to the . !
This is happening because this conditional is entered on ctrl+shift+b after reload: Looks like isn't restored on reconnect: !
The task has the wrong id? !
is persisted as a guid, not the expected string? !
It's the custom task with the same label that gets the uuid:
ends up returning true, that's why _id ends up as a uuid: The task's type is undefined after reconnection. It's mean to be , this is what it's meant to be: !
Note that this only reproduce for compound tasks.
That was a journey and I'm ready to throw in the towel for now. I believe the issue is either compound task state is not restored properly after reconnect here: And/or the recently used tasks cached value does not contain all recently used tasks as I only see the compound and Core - Build, no Ext - Build.
any thoughts would be appreciated. I spent ~ 3 hours on this and Daniel did as well.
I will take some time tomorrow to dig into it.
Some notes from debugging: When comparing tasks that come out of the recently used task list, they must be compared by their recently used key as this is the only stable id value (map key and task id can change). Instead of having a separate code path for reconnect, which is what is causing some state to be lost (like the ), if possible, it would be better to try the reconnect in the same place that we currently create a terminal. This would hook up all the needed state again and re-attach problem matchers. I've made an example PR here that starts to address the above points. Note that this is relatively untested, I just checked whether it fixes the problem described in this issue. Other notes: Using the recent tasks from the task service for re-connecting is problematic since users can use to entirely disable recent tasks. Instead, you will probably need a separate LRU that functions exactly like but is only used for reconnection. Tangentially related: you also need to nudge/rerun problem matchers on terminal lines that have already been written so that they can find their start pattern and the task doesn't have a spinner forever.

} try { <del> const executeResult = { kind: TaskExecuteKind.Started, task, started: {}, promise: this._executeTask(task, resolver, trigger, new Set()) }; </del> <ins> const executeResult = { kind: TaskExecuteKind.Started, task, started: {}, promise: this._executeTask(task, resolver, trigger, new Set(), undefined) }; </ins> executeResult.promise.then(summary => { this._lastTask = this._currentTask; });


Question:
to start the default build ! This happened right after something strange, which might be the underlying cause. I had the build running already, the one with two terminals open. But I still pressed and noticed another two terminals showed up with the same build tasks! I closed them all. Then I pressed and ended up where the screenshot above shows. cc
I reloaded, then pressed before the workbench was done loading and got this: ! I waited a bit more, pressed it again and it worked. This is very likely a separate issue, so feel free to treat it as such.
might be a bug with the new reconnect?
Yeah I think I saw this once
That's exactly right. Steps: selfhost setup Shift B, you now have 2 build commands running VS Code VS Code, you still have 2 build commands running Shift B, You now have 4 build commands running.
C the old ones The new ones appear loading, even though they have finished compilation: ! Worse: the window horizontally, and eventually you'll get lucky and the spinning icons dissappear: !
it's not a new bug that you can launch tasks that are already running
If you press you should get the default build tasks, which are long running. If you press it again, they shouldn't be launched again and they aren't. This is good and expected. The bug is: restart Code (tasks now get restored), press and you'll get the same build tasks running again. This shouldn't happen: !
same root cause as , which is not new
This is my selfhost setup. I am 100% sure this is new.
the two bugs that you've identified here though are: the error about a terminal group command not found was already aware that statuses do not work after reload
in your old setup, run ctrl shift b, ctrl shift b again. you'll get 4
in stable !
I think you are correct it's a different issue. I see what's going on now.
might still be the same root cause, but i'll try to investigate for a bit
Thanks
could you pls verify this is fixed for you in insider's keeping in mind these two that I have a PR out to fix as well?
Sorry for reopening but I could still repro in today's build () very likely due to the . !
This is happening because this conditional is entered on ctrl+shift+b after reload: Looks like isn't restored on reconnect: !
The task has the wrong id? !
is persisted as a guid, not the expected string? !
It's the custom task with the same label that gets the uuid:
ends up returning true, that's why _id ends up as a uuid: The task's type is undefined after reconnection. It's mean to be , this is what it's meant to be: !
Note that this only reproduce for compound tasks.
That was a journey and I'm ready to throw in the towel for now. I believe the issue is either compound task state is not restored properly after reconnect here: And/or the recently used tasks cached value does not contain all recently used tasks as I only see the compound and Core - Build, no Ext - Build.
any thoughts would be appreciated. I spent ~ 3 hours on this and Daniel did as well.
I will take some time tomorrow to dig into it.
Some notes from debugging: When comparing tasks that come out of the recently used task list, they must be compared by their recently used key as this is the only stable id value (map key and task id can change). Instead of having a separate code path for reconnect, which is what is causing some state to be lost (like the ), if possible, it would be better to try the reconnect in the same place that we currently create a terminal. This would hook up all the needed state again and re-attach problem matchers. I've made an example PR here that starts to address the above points. Note that this is relatively untested, I just checked whether it fixes the problem described in this issue. Other notes: Using the recent tasks from the task service for re-connecting is problematic since users can use to entirely disable recent tasks. Instead, you will probably need a separate LRU that functions exactly like but is only used for reconnection. Tangentially related: you also need to nudge/rerun problem matchers on terminal lines that have already been written so that they can find their start pattern and the task doesn't have a spinner forever.

})); watchingProblemMatcher.aboutToStart(); let delayer: Async.Delayer<any> | undefined = undefined; <del> [terminal, error] = await this._createTerminal(task, resolver, workspaceFolder); </del> <ins> [terminal, error] = this._terminalForTask ? [this._terminalForTask, undefined] : await this._createTerminal(task, resolver, workspaceFolder); </ins> if (error) { return Promise.reject(new Error((<TaskError>error).message));


Question:
to start the default build ! This happened right after something strange, which might be the underlying cause. I had the build running already, the one with two terminals open. But I still pressed and noticed another two terminals showed up with the same build tasks! I closed them all. Then I pressed and ended up where the screenshot above shows. cc
I reloaded, then pressed before the workbench was done loading and got this: ! I waited a bit more, pressed it again and it worked. This is very likely a separate issue, so feel free to treat it as such.
might be a bug with the new reconnect?
Yeah I think I saw this once
That's exactly right. Steps: selfhost setup Shift B, you now have 2 build commands running VS Code VS Code, you still have 2 build commands running Shift B, You now have 4 build commands running.
C the old ones The new ones appear loading, even though they have finished compilation: ! Worse: the window horizontally, and eventually you'll get lucky and the spinning icons dissappear: !
it's not a new bug that you can launch tasks that are already running
If you press you should get the default build tasks, which are long running. If you press it again, they shouldn't be launched again and they aren't. This is good and expected. The bug is: restart Code (tasks now get restored), press and you'll get the same build tasks running again. This shouldn't happen: !
same root cause as , which is not new
This is my selfhost setup. I am 100% sure this is new.
the two bugs that you've identified here though are: the error about a terminal group command not found was already aware that statuses do not work after reload
in your old setup, run ctrl shift b, ctrl shift b again. you'll get 4
in stable !
I think you are correct it's a different issue. I see what's going on now.
might still be the same root cause, but i'll try to investigate for a bit
Thanks
could you pls verify this is fixed for you in insider's keeping in mind these two that I have a PR out to fix as well?
Sorry for reopening but I could still repro in today's build () very likely due to the . !
This is happening because this conditional is entered on ctrl+shift+b after reload: Looks like isn't restored on reconnect: !
The task has the wrong id? !
is persisted as a guid, not the expected string? !
It's the custom task with the same label that gets the uuid:
ends up returning true, that's why _id ends up as a uuid: The task's type is undefined after reconnection. It's mean to be , this is what it's meant to be: !
Note that this only reproduce for compound tasks.
That was a journey and I'm ready to throw in the towel for now. I believe the issue is either compound task state is not restored properly after reconnect here: And/or the recently used tasks cached value does not contain all recently used tasks as I only see the compound and Core - Build, no Ext - Build.
any thoughts would be appreciated. I spent ~ 3 hours on this and Daniel did as well.
I will take some time tomorrow to dig into it.
Some notes from debugging: When comparing tasks that come out of the recently used task list, they must be compared by their recently used key as this is the only stable id value (map key and task id can change). Instead of having a separate code path for reconnect, which is what is causing some state to be lost (like the ), if possible, it would be better to try the reconnect in the same place that we currently create a terminal. This would hook up all the needed state again and re-attach problem matchers. I've made an example PR here that starts to address the above points. Note that this is relatively untested, I just checked whether it fixes the problem described in this issue. Other notes: Using the recent tasks from the task service for re-connecting is problematic since users can use to entirely disable recent tasks. Instead, you will probably need a separate LRU that functions exactly like but is only used for reconnection. Tangentially related: you also need to nudge/rerun problem matchers on terminal lines that have already been written so that they can find their start pattern and the task doesn't have a spinner forever.

}); }); } else { <del> [terminal, error] = await this._createTerminal(task, resolver, workspaceFolder); </del> <ins> [terminal, error] = this._terminalForTask ? [this._terminalForTask, undefined] : await this._createTerminal(task, resolver, workspaceFolder); </ins> if (error) { return Promise.reject(new Error((<TaskError>error).message));


Question:
Steps: some changes on the "continue working on..." command and open in desktop :bug: VS Code opens but nothing loads https://user- Desktop Version: 1.70.0-insider (Universal) Commit: Date: 2022-07-26T05:17:37.262Z Electron: 18.3.5 Chromium: 100.0.4896.160 16.13.2 V8: 10.0.139.17-electron.0 OS: Darwin arm64 21.6.0 Web Version: 1.70.0-insider Commit: Date: 2022-07-26T05:17:04.193Z Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X ) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.114 Safari/537.36
This action should be disabled in since we cannot access the local filesystem from the browser.
I'm still able to run the command from insiders vscode dev in Firefox. My Desktop Insiders then opens the repo using remote repositories but on the main branch instead of the branch I was working on. I'm not sure if this is the expected behaviour
I verified that this now works as expected https://user-

import { EditSessionsDataViews } from 'vs/workbench/contrib/editSessions/browser/editSessionsViews'; import { ITextModelService } from 'vs/editor/common/services/resolverService'; import { EditSessionsContentProvider } from 'vs/workbench/contrib/editSessions/browser/editSessionsContentProvider'; <ins> import { isNative } from 'vs/base/common/platform'; import { WorkspaceFolderCountContext } from 'vs/workbench/common/contextkeys'; </ins> registerSingleton(IEditSessionsLogService, EditSessionsLogService); registerSingleton(IEditSessionsWorkbenchService, EditSessionsWorkbenchService);


Question:
Steps: some changes on the "continue working on..." command and open in desktop :bug: VS Code opens but nothing loads https://user- Desktop Version: 1.70.0-insider (Universal) Commit: Date: 2022-07-26T05:17:37.262Z Electron: 18.3.5 Chromium: 100.0.4896.160 16.13.2 V8: 10.0.139.17-electron.0 OS: Darwin arm64 21.6.0 Web Version: 1.70.0-insider Commit: Date: 2022-07-26T05:17:04.193Z Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X ) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.114 Safari/537.36
This action should be disabled in since we cannot access the local filesystem from the browser.
I'm still able to run the command from insiders vscode dev in Firefox. My Desktop Insiders then opens the repo using remote repositories but on the main branch instead of the branch I was working on. I'm not sure if this is the expected behaviour
I verified that this now works as expected https://user-

id: '_workbench.experimental.editSessions.actions.continueEditSession', title: { value: localize('continue edit session', "Continue Edit Session..."), original: 'Continue Edit Session...' }, category: EDIT_SESSION_SYNC_CATEGORY, <ins> precondition: WorkspaceFolderCountContext.notEqualsTo('0'), </ins> f1: true }; const openLocalFolderCommand: IAction2Options = {


Question:
Steps: some changes on the "continue working on..." command and open in desktop :bug: VS Code opens but nothing loads https://user- Desktop Version: 1.70.0-insider (Universal) Commit: Date: 2022-07-26T05:17:37.262Z Electron: 18.3.5 Chromium: 100.0.4896.160 16.13.2 V8: 10.0.139.17-electron.0 OS: Darwin arm64 21.6.0 Web Version: 1.70.0-insider Commit: Date: 2022-07-26T05:17:04.193Z Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X ) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.114 Safari/537.36
This action should be disabled in since we cannot access the local filesystem from the browser.
I'm still able to run the command from insiders vscode dev in Firefox. My Desktop Insiders then opens the repo using remote repositories but on the main branch instead of the branch I was working on. I'm not sure if this is the expected behaviour
I verified that this now works as expected https://user-

private createPickItems(): ContinueEditSessionItem[] { const items = [...this.continueEditSessionOptions].filter((option) => option.when === undefined || this.contextKeyService.contextMatchesRules(option.when)); <del> if (getVirtualWorkspaceLocation(this.contextService.getWorkspace()) !== undefined) { </del> <ins> if (getVirtualWorkspaceLocation(this.contextService.getWorkspace()) !== undefined && isNative) { </ins> items.push(new ContinueEditSessionItem( localize('continueEditSessionItem.openInLocalFolder', 'Open In Local Folder'), openLocalFolderCommand.id,


Question:
Steps: some changes on the "continue working on..." command and open in desktop :bug: VS Code opens but nothing loads https://user- Desktop Version: 1.70.0-insider (Universal) Commit: Date: 2022-07-26T05:17:37.262Z Electron: 18.3.5 Chromium: 100.0.4896.160 16.13.2 V8: 10.0.139.17-electron.0 OS: Darwin arm64 21.6.0 Web Version: 1.70.0-insider Commit: Date: 2022-07-26T05:17:04.193Z Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X ) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.114 Safari/537.36
This action should be disabled in since we cannot access the local filesystem from the browser.
I'm still able to run the command from insiders vscode dev in Firefox. My Desktop Insiders then opens the repo using remote repositories but on the main branch instead of the branch I was working on. I'm not sure if this is the expected behaviour
I verified that this now works as expected https://user-

constructor() { super({ id: 'workbench.editSessions.actions.resetAuth', <del> title: localize('reset auth', 'Sign Out'), </del> <ins> title: localize('reset auth.v2', 'Sign Out of Edit Sessions'), </ins> category: EDIT_SESSION_SYNC_CATEGORY, precondition: ContextKeyExpr.equals(EDIT_SESSIONS_SIGNED_IN_KEY, true), menu: [{


Question:
<!-- 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.69.2 OS Version: MacOS BigSur and Monterey Steps to Reproduce: Open a terminal editor. a file from Finder into the terminal. This tries to open the file (unlike when the terminal is in the panel, which will paste the path).
I found that if I prevent the following code from executing, it works. So it seems like prevents the following code to handle pasting the file path. I did find that if you hold Shift before starting to drag the file, it will paste due to this code: I'm guessing there's some way to get that to realize it's a terminal editor and return as well.
I submitted PR for this.
File is still opened
did you hold shift? That's the method of passing the file through to the editor
works correctly with shift held

} override get capabilities(): EditorInputCapabilities { <del> return EditorInputCapabilities.Readonly | EditorInputCapabilities.Singleton; </del> <ins> return EditorInputCapabilities.Readonly | EditorInputCapabilities.Singleton | EditorInputCapabilities.CanDropIntoEditor; </ins> } setTerminalInstance(instance: ITerminalInstance): void {


Question:
! The settings to select an codicon for a decoration are not playing well with our product icon theming approach. We want that a product icon theme can style all icons of our UI with a new icons. Each icon that we show should be defined with a component specific name E.g. , , ... That way the theme can come up with a custom icon for each icon location The base icon names (, , ...) should not be used directly, only as defaults, otherwise it gets complicated for a theme to change an icon as it affects many places, unknown to the theme. What might look good with our codicon based product icon theme, might look wrong with a theme that uses a different visual for I suggest to remove the settings as we don't do that at other places. Instead we should refer to product icon themes as the way to change icons.
Requested the aliases in
We do allow switching icons for terminals in this way which I think is fine as they're very temporal: ! I see what you're saying here though, let's remove the setting and leave it up to the icon theme . We have this setting now so it solves that part of what these icon settings allowed:
I was on vacation so I couldn't jump in here. It was not necessary to request new codicons or codicon aliases unless a new icon shape was needed, e.g. for a concept we didn't have yet. There still seems to be a confusion of Codicons vs product icon icons. The Codicon library is a set of default icons that are part of the Codicon font. We use these as default icons in VS Code. See the spec of Codicon: codicon aliases should be component agnostic (no 'terminal', 'debug'). The componnet specific ids go in the product icon registry. These are the ids that wil be used in a product icon theme when styling an icon. Product icon ids are component specific and are defined in the component itself, e.g. as done here: This defines a new product icon , and uses the codicon 'add' icon as the default icon. When using these icons in code, must be used (or in labels by the id ). We never want to reference in components, unless for the default in . Some years ago, all our components directly referenced codicons and their ids. When adding icon theming support we this indirection and I and migrated most components, including terminal. But given the huge number of icon references that work is still not complete and there are still plenty of references to Codicon. That's why a codicon and a product icon () still have the same API and we don't enforce this with the compiler. Also there are some codicon aliases that have component specific names. We can't clean up the aliases in order to not break existing code in extensions. Eventually no one should use there anymore. please do not reference Codicon directly anymore unless in registerIcon please follow the pattern as seen in terminalIcons please don't add component specific Codicon aliases FYI
FYI I was following what seemed to be the thing to do as demonstrated by the icons. Could we remove those and similar examples and/or add a comment with this guidance?
Good point, we should clean these up. The codicons have been around from old times before we did the product icons. There are product icon registration under the same name , so we can remove the codicons that are just aliases, and give the others a different name, to avoid confusion.

ShellIntegrationEnabled = 'terminal.integrated.shellIntegration.enabled', ShellIntegrationShowWelcome = 'terminal.integrated.shellIntegration.showWelcome', ShellIntegrationDecorationsEnabled = 'terminal.integrated.shellIntegration.decorationsEnabled', <del> ShellIntegrationDecorationIcon = 'terminal.integrated.shellIntegration.decorationIcon', ShellIntegrationDecorationIconError = 'terminal.integrated.shellIntegration.decorationIconError', ShellIntegrationDecorationIconSuccess = 'terminal.integrated.shellIntegration.decorationIconSuccess', </del> ShellIntegrationCommandHistory = 'terminal.integrated.shellIntegration.history', SmoothScrolling = 'terminal.integrated.smoothScrolling' }


Question:
! The settings to select an codicon for a decoration are not playing well with our product icon theming approach. We want that a product icon theme can style all icons of our UI with a new icons. Each icon that we show should be defined with a component specific name E.g. , , ... That way the theme can come up with a custom icon for each icon location The base icon names (, , ...) should not be used directly, only as defaults, otherwise it gets complicated for a theme to change an icon as it affects many places, unknown to the theme. What might look good with our codicon based product icon theme, might look wrong with a theme that uses a different visual for I suggest to remove the settings as we don't do that at other places. Instead we should refer to product icon themes as the way to change icons.
Requested the aliases in
We do allow switching icons for terminals in this way which I think is fine as they're very temporal: ! I see what you're saying here though, let's remove the setting and leave it up to the icon theme . We have this setting now so it solves that part of what these icon settings allowed:
I was on vacation so I couldn't jump in here. It was not necessary to request new codicons or codicon aliases unless a new icon shape was needed, e.g. for a concept we didn't have yet. There still seems to be a confusion of Codicons vs product icon icons. The Codicon library is a set of default icons that are part of the Codicon font. We use these as default icons in VS Code. See the spec of Codicon: codicon aliases should be component agnostic (no 'terminal', 'debug'). The componnet specific ids go in the product icon registry. These are the ids that wil be used in a product icon theme when styling an icon. Product icon ids are component specific and are defined in the component itself, e.g. as done here: This defines a new product icon , and uses the codicon 'add' icon as the default icon. When using these icons in code, must be used (or in labels by the id ). We never want to reference in components, unless for the default in . Some years ago, all our components directly referenced codicons and their ids. When adding icon theming support we this indirection and I and migrated most components, including terminal. But given the huge number of icon references that work is still not complete and there are still plenty of references to Codicon. That's why a codicon and a product icon () still have the same API and we don't enforce this with the compiler. Also there are some codicon aliases that have component specific names. We can't clean up the aliases in order to not break existing code in extensions. Eventually no one should use there anymore. please do not reference Codicon directly anymore unless in registerIcon please follow the pattern as seen in terminalIcons please don't add component specific Codicon aliases FYI
FYI I was following what seemed to be the thing to do as demonstrated by the icons. Could we remove those and similar examples and/or add a comment with this guidance?
Good point, we should clean these up. The codicons have been around from old times before we did the product icons. There are product icon registration under the same name , so we can remove the codicons that are just aliases, and give the others a different name, to avoid confusion.

Default = 'default', Codicon = 'codicon', XtermDecoration = 'xterm-decoration', <del> GenericMarkerIcon = 'codicon-circle-small-filled', </del> OverviewRuler = '.xterm-decoration-overview-ruler' }


Question:
! The settings to select an codicon for a decoration are not playing well with our product icon theming approach. We want that a product icon theme can style all icons of our UI with a new icons. Each icon that we show should be defined with a component specific name E.g. , , ... That way the theme can come up with a custom icon for each icon location The base icon names (, , ...) should not be used directly, only as defaults, otherwise it gets complicated for a theme to change an icon as it affects many places, unknown to the theme. What might look good with our codicon based product icon theme, might look wrong with a theme that uses a different visual for I suggest to remove the settings as we don't do that at other places. Instead we should refer to product icon themes as the way to change icons.
Requested the aliases in
We do allow switching icons for terminals in this way which I think is fine as they're very temporal: ! I see what you're saying here though, let's remove the setting and leave it up to the icon theme . We have this setting now so it solves that part of what these icon settings allowed:
I was on vacation so I couldn't jump in here. It was not necessary to request new codicons or codicon aliases unless a new icon shape was needed, e.g. for a concept we didn't have yet. There still seems to be a confusion of Codicons vs product icon icons. The Codicon library is a set of default icons that are part of the Codicon font. We use these as default icons in VS Code. See the spec of Codicon: codicon aliases should be component agnostic (no 'terminal', 'debug'). The componnet specific ids go in the product icon registry. These are the ids that wil be used in a product icon theme when styling an icon. Product icon ids are component specific and are defined in the component itself, e.g. as done here: This defines a new product icon , and uses the codicon 'add' icon as the default icon. When using these icons in code, must be used (or in labels by the id ). We never want to reference in components, unless for the default in . Some years ago, all our components directly referenced codicons and their ids. When adding icon theming support we this indirection and I and migrated most components, including terminal. But given the huge number of icon references that work is still not complete and there are still plenty of references to Codicon. That's why a codicon and a product icon () still have the same API and we don't enforce this with the compiler. Also there are some codicon aliases that have component specific names. We can't clean up the aliases in order to not break existing code in extensions. Eventually no one should use there anymore. please do not reference Codicon directly anymore unless in registerIcon please follow the pattern as seen in terminalIcons please don't add component specific Codicon aliases FYI
FYI I was following what seemed to be the thing to do as demonstrated by the icons. Could we remove those and similar examples and/or add a comment with this guidance?
Good point, we should clean these up. The codicons have been around from old times before we did the product icons. There are product icon registration under the same name , so we can remove the codicons that are just aliases, and give the others a different name, to avoid confusion.

this._hoverDelayer = this._register(new Delayer(this._configurationService.getValue('workbench.hover.delay'))); this._register(this._configurationService.onDidChangeConfiguration(e => { <del> if (e.affectsConfiguration(TerminalSettingId.ShellIntegrationDecorationIcon) || e.affectsConfiguration(TerminalSettingId.ShellIntegrationDecorationIconSuccess) || e.affectsConfiguration(TerminalSettingId.ShellIntegrationDecorationIconError)) { this._refreshStyles(); } else if (e.affectsConfiguration(TerminalSettingId.FontSize) || e.affectsConfiguration(TerminalSettingId.LineHeight)) { </del> <ins> if (e.affectsConfiguration(TerminalSettingId.FontSize) || e.affectsConfiguration(TerminalSettingId.LineHeight)) { </ins> this.refreshLayouts(); } else if (e.affectsConfiguration('workbench.colorCustomizations')) { this._refreshStyles(true);


Question:
! The settings to select an codicon for a decoration are not playing well with our product icon theming approach. We want that a product icon theme can style all icons of our UI with a new icons. Each icon that we show should be defined with a component specific name E.g. , , ... That way the theme can come up with a custom icon for each icon location The base icon names (, , ...) should not be used directly, only as defaults, otherwise it gets complicated for a theme to change an icon as it affects many places, unknown to the theme. What might look good with our codicon based product icon theme, might look wrong with a theme that uses a different visual for I suggest to remove the settings as we don't do that at other places. Instead we should refer to product icon themes as the way to change icons.
Requested the aliases in
We do allow switching icons for terminals in this way which I think is fine as they're very temporal: ! I see what you're saying here though, let's remove the setting and leave it up to the icon theme . We have this setting now so it solves that part of what these icon settings allowed:
I was on vacation so I couldn't jump in here. It was not necessary to request new codicons or codicon aliases unless a new icon shape was needed, e.g. for a concept we didn't have yet. There still seems to be a confusion of Codicons vs product icon icons. The Codicon library is a set of default icons that are part of the Codicon font. We use these as default icons in VS Code. See the spec of Codicon: codicon aliases should be component agnostic (no 'terminal', 'debug'). The componnet specific ids go in the product icon registry. These are the ids that wil be used in a product icon theme when styling an icon. Product icon ids are component specific and are defined in the component itself, e.g. as done here: This defines a new product icon , and uses the codicon 'add' icon as the default icon. When using these icons in code, must be used (or in labels by the id ). We never want to reference in components, unless for the default in . Some years ago, all our components directly referenced codicons and their ids. When adding icon theming support we this indirection and I and migrated most components, including terminal. But given the huge number of icon references that work is still not complete and there are still plenty of references to Codicon. That's why a codicon and a product icon () still have the same API and we don't enforce this with the compiler. Also there are some codicon aliases that have component specific names. We can't clean up the aliases in order to not break existing code in extensions. Eventually no one should use there anymore. please do not reference Codicon directly anymore unless in registerIcon please follow the pattern as seen in terminalIcons please don't add component specific Codicon aliases FYI
FYI I was following what seemed to be the thing to do as demonstrated by the icons. Could we remove those and similar examples and/or add a comment with this guidance?
Good point, we should clean these up. The codicons have been around from old times before we did the product icons. There are product icon registration under the same name , so we can remove the codicons that are just aliases, and give the others a different name, to avoid confusion.

element.classList.add(DecorationSelector.CommandDecoration, DecorationSelector.Codicon, DecorationSelector.XtermDecoration); if (genericMarkProperties) { <del> element.classList.add(DecorationSelector.DefaultColor, DecorationSelector.GenericMarkerIcon); </del> <ins> element.classList.add(DecorationSelector.DefaultColor, ...Codicon.terminalDecorationMark.classNamesArray); </ins> if (!genericMarkProperties.hoverMessage) { //disable the mouse pointer element.classList.add(DecorationSelector.Default);


Question:
! The settings to select an codicon for a decoration are not playing well with our product icon theming approach. We want that a product icon theme can style all icons of our UI with a new icons. Each icon that we show should be defined with a component specific name E.g. , , ... That way the theme can come up with a custom icon for each icon location The base icon names (, , ...) should not be used directly, only as defaults, otherwise it gets complicated for a theme to change an icon as it affects many places, unknown to the theme. What might look good with our codicon based product icon theme, might look wrong with a theme that uses a different visual for I suggest to remove the settings as we don't do that at other places. Instead we should refer to product icon themes as the way to change icons.
Requested the aliases in
We do allow switching icons for terminals in this way which I think is fine as they're very temporal: ! I see what you're saying here though, let's remove the setting and leave it up to the icon theme . We have this setting now so it solves that part of what these icon settings allowed:
I was on vacation so I couldn't jump in here. It was not necessary to request new codicons or codicon aliases unless a new icon shape was needed, e.g. for a concept we didn't have yet. There still seems to be a confusion of Codicons vs product icon icons. The Codicon library is a set of default icons that are part of the Codicon font. We use these as default icons in VS Code. See the spec of Codicon: codicon aliases should be component agnostic (no 'terminal', 'debug'). The componnet specific ids go in the product icon registry. These are the ids that wil be used in a product icon theme when styling an icon. Product icon ids are component specific and are defined in the component itself, e.g. as done here: This defines a new product icon , and uses the codicon 'add' icon as the default icon. When using these icons in code, must be used (or in labels by the id ). We never want to reference in components, unless for the default in . Some years ago, all our components directly referenced codicons and their ids. When adding icon theming support we this indirection and I and migrated most components, including terminal. But given the huge number of icon references that work is still not complete and there are still plenty of references to Codicon. That's why a codicon and a product icon () still have the same API and we don't enforce this with the compiler. Also there are some codicon aliases that have component specific names. We can't clean up the aliases in order to not break existing code in extensions. Eventually no one should use there anymore. please do not reference Codicon directly anymore unless in registerIcon please follow the pattern as seen in terminalIcons please don't add component specific Codicon aliases FYI
FYI I was following what seemed to be the thing to do as demonstrated by the icons. Could we remove those and similar examples and/or add a comment with this guidance?
Good point, we should clean these up. The codicons have been around from old times before we did the product icons. There are product icon registration under the same name , so we can remove the codicons that are just aliases, and give the others a different name, to avoid confusion.

this._updateCommandDecorationVisibility(element); if (exitCode === undefined) { element.classList.add(DecorationSelector.DefaultColor, DecorationSelector.Default); <del> element.classList.add(`codicon-${this._configurationService.getValue(TerminalSettingId.ShellIntegrationDecorationIcon)}`); </del> <ins> element.classList.add(...Codicon.terminalDecorationIncomplete.classNamesArray); </ins> } else if (exitCode) { element.classList.add(DecorationSelector.ErrorColor); <del> element.classList.add(`codicon-${this._configurationService.getValue(TerminalSettingId.ShellIntegrationDecorationIconError)}`); </del> <ins> element.classList.add(...Codicon.terminalDecorationError.classNamesArray); </ins> } else { <del> element.classList.add(`codicon-${this._configurationService.getValue(TerminalSettingId.ShellIntegrationDecorationIconSuccess)}`); </del> <ins> element.classList.add(...Codicon.terminalDecorationSuccess.classNamesArray); </ins> } } }


Question:
! The settings to select an codicon for a decoration are not playing well with our product icon theming approach. We want that a product icon theme can style all icons of our UI with a new icons. Each icon that we show should be defined with a component specific name E.g. , , ... That way the theme can come up with a custom icon for each icon location The base icon names (, , ...) should not be used directly, only as defaults, otherwise it gets complicated for a theme to change an icon as it affects many places, unknown to the theme. What might look good with our codicon based product icon theme, might look wrong with a theme that uses a different visual for I suggest to remove the settings as we don't do that at other places. Instead we should refer to product icon themes as the way to change icons.
Requested the aliases in
We do allow switching icons for terminals in this way which I think is fine as they're very temporal: ! I see what you're saying here though, let's remove the setting and leave it up to the icon theme . We have this setting now so it solves that part of what these icon settings allowed:
I was on vacation so I couldn't jump in here. It was not necessary to request new codicons or codicon aliases unless a new icon shape was needed, e.g. for a concept we didn't have yet. There still seems to be a confusion of Codicons vs product icon icons. The Codicon library is a set of default icons that are part of the Codicon font. We use these as default icons in VS Code. See the spec of Codicon: codicon aliases should be component agnostic (no 'terminal', 'debug'). The componnet specific ids go in the product icon registry. These are the ids that wil be used in a product icon theme when styling an icon. Product icon ids are component specific and are defined in the component itself, e.g. as done here: This defines a new product icon , and uses the codicon 'add' icon as the default icon. When using these icons in code, must be used (or in labels by the id ). We never want to reference in components, unless for the default in . Some years ago, all our components directly referenced codicons and their ids. When adding icon theming support we this indirection and I and migrated most components, including terminal. But given the huge number of icon references that work is still not complete and there are still plenty of references to Codicon. That's why a codicon and a product icon () still have the same API and we don't enforce this with the compiler. Also there are some codicon aliases that have component specific names. We can't clean up the aliases in order to not break existing code in extensions. Eventually no one should use there anymore. please do not reference Codicon directly anymore unless in registerIcon please follow the pattern as seen in terminalIcons please don't add component specific Codicon aliases FYI
FYI I was following what seemed to be the thing to do as demonstrated by the icons. Could we remove those and similar examples and/or add a comment with this guidance?
Good point, we should clean these up. The codicons have been around from old times before we did the product icons. There are product icon registration under the same name , so we can remove the codicons that are just aliases, and give the others a different name, to avoid confusion.

private async _showConfigureCommandDecorationsQuickPick() { const quickPick = this._quickInputService.createQuickPick(); quickPick.items = [ <del> { id: 'a', label: localize('changeDefaultIcon', 'Change default icon') }, { id: 'b', label: localize('changeSuccessIcon', 'Change success icon') }, { id: 'c', label: localize('changeErrorIcon', 'Change error icon') }, { type: 'separator' }, { id: 'd', label: localize('toggleVisibility', 'Toggle visibility') }, </del> <ins> { id: 'a', label: localize('toggleVisibility', 'Toggle visibility') }, </ins> ]; quickPick.canSelectMany = false; quickPick.onDidAccept(async e => {


Question:
! The settings to select an codicon for a decoration are not playing well with our product icon theming approach. We want that a product icon theme can style all icons of our UI with a new icons. Each icon that we show should be defined with a component specific name E.g. , , ... That way the theme can come up with a custom icon for each icon location The base icon names (, , ...) should not be used directly, only as defaults, otherwise it gets complicated for a theme to change an icon as it affects many places, unknown to the theme. What might look good with our codicon based product icon theme, might look wrong with a theme that uses a different visual for I suggest to remove the settings as we don't do that at other places. Instead we should refer to product icon themes as the way to change icons.
Requested the aliases in
We do allow switching icons for terminals in this way which I think is fine as they're very temporal: ! I see what you're saying here though, let's remove the setting and leave it up to the icon theme . We have this setting now so it solves that part of what these icon settings allowed:
I was on vacation so I couldn't jump in here. It was not necessary to request new codicons or codicon aliases unless a new icon shape was needed, e.g. for a concept we didn't have yet. There still seems to be a confusion of Codicons vs product icon icons. The Codicon library is a set of default icons that are part of the Codicon font. We use these as default icons in VS Code. See the spec of Codicon: codicon aliases should be component agnostic (no 'terminal', 'debug'). The componnet specific ids go in the product icon registry. These are the ids that wil be used in a product icon theme when styling an icon. Product icon ids are component specific and are defined in the component itself, e.g. as done here: This defines a new product icon , and uses the codicon 'add' icon as the default icon. When using these icons in code, must be used (or in labels by the id ). We never want to reference in components, unless for the default in . Some years ago, all our components directly referenced codicons and their ids. When adding icon theming support we this indirection and I and migrated most components, including terminal. But given the huge number of icon references that work is still not complete and there are still plenty of references to Codicon. That's why a codicon and a product icon () still have the same API and we don't enforce this with the compiler. Also there are some codicon aliases that have component specific names. We can't clean up the aliases in order to not break existing code in extensions. Eventually no one should use there anymore. please do not reference Codicon directly anymore unless in registerIcon please follow the pattern as seen in terminalIcons please don't add component specific Codicon aliases FYI
FYI I was following what seemed to be the thing to do as demonstrated by the icons. Could we remove those and similar examples and/or add a comment with this guidance?
Good point, we should clean these up. The codicons have been around from old times before we did the product icons. There are product icon registration under the same name , so we can remove the codicons that are just aliases, and give the others a different name, to avoid confusion.

const result = quickPick.activeItems[0]; let iconSetting: string | undefined; switch (result.id) { <del> case 'a': iconSetting = TerminalSettingId.ShellIntegrationDecorationIcon; break; case 'b': iconSetting = TerminalSettingId.ShellIntegrationDecorationIconSuccess; break; case 'c': iconSetting = TerminalSettingId.ShellIntegrationDecorationIconError; break; case 'd': this._showToggleVisibilityQuickPick(); break; </del> <ins> case 'a': this._showToggleVisibilityQuickPick(); break; </ins> } if (iconSetting) { this._showChangeIconQuickPick(iconSetting);


Question:
! The settings to select an codicon for a decoration are not playing well with our product icon theming approach. We want that a product icon theme can style all icons of our UI with a new icons. Each icon that we show should be defined with a component specific name E.g. , , ... That way the theme can come up with a custom icon for each icon location The base icon names (, , ...) should not be used directly, only as defaults, otherwise it gets complicated for a theme to change an icon as it affects many places, unknown to the theme. What might look good with our codicon based product icon theme, might look wrong with a theme that uses a different visual for I suggest to remove the settings as we don't do that at other places. Instead we should refer to product icon themes as the way to change icons.
Requested the aliases in
We do allow switching icons for terminals in this way which I think is fine as they're very temporal: ! I see what you're saying here though, let's remove the setting and leave it up to the icon theme . We have this setting now so it solves that part of what these icon settings allowed:
I was on vacation so I couldn't jump in here. It was not necessary to request new codicons or codicon aliases unless a new icon shape was needed, e.g. for a concept we didn't have yet. There still seems to be a confusion of Codicons vs product icon icons. The Codicon library is a set of default icons that are part of the Codicon font. We use these as default icons in VS Code. See the spec of Codicon: codicon aliases should be component agnostic (no 'terminal', 'debug'). The componnet specific ids go in the product icon registry. These are the ids that wil be used in a product icon theme when styling an icon. Product icon ids are component specific and are defined in the component itself, e.g. as done here: This defines a new product icon , and uses the codicon 'add' icon as the default icon. When using these icons in code, must be used (or in labels by the id ). We never want to reference in components, unless for the default in . Some years ago, all our components directly referenced codicons and their ids. When adding icon theming support we this indirection and I and migrated most components, including terminal. But given the huge number of icon references that work is still not complete and there are still plenty of references to Codicon. That's why a codicon and a product icon () still have the same API and we don't enforce this with the compiler. Also there are some codicon aliases that have component specific names. We can't clean up the aliases in order to not break existing code in extensions. Eventually no one should use there anymore. please do not reference Codicon directly anymore unless in registerIcon please follow the pattern as seen in terminalIcons please don't add component specific Codicon aliases FYI
FYI I was following what seemed to be the thing to do as demonstrated by the icons. Could we remove those and similar examples and/or add a comment with this guidance?
Good point, we should clean these up. The codicons have been around from old times before we did the product icons. There are product icon registration under the same name , so we can remove the codicons that are just aliases, and give the others a different name, to avoid confusion.

default: 'view', description: localize('terminal.integrated.defaultLocation', "Controls where newly created terminals will appear.") }, <del> [TerminalSettingId.ShellIntegrationDecorationIconSuccess]: { type: 'string', default: 'primitive-dot', markdownDescription: localize('terminal.integrated.shellIntegration.decorationIconSuccess', "Controls the icon that will be used for each command in terminals with shell integration enabled that do not have an associated exit code. Set to {0} to hide the icon or disable decorations with {1}.", '`""`', '`#terminal.integrated.shellIntegration.decorationsEnabled#`') }, [TerminalSettingId.ShellIntegrationDecorationIconError]: { type: 'string', default: 'error-small', markdownDescription: localize('terminal.integrated.shellIntegration.decorationIconError', "Controls the icon that will be used for each command in terminals with shell integration enabled that do have an associated exit code. Set to {0} to hide the icon or disable decorations with {1}.", '`""`', '`#terminal.integrated.shellIntegration.decorationsEnabled#`') }, [TerminalSettingId.ShellIntegrationDecorationIcon]: { type: 'string', default: 'circle-outline', markdownDescription: localize('terminal.integrated.shellIntegration.decorationIcon', "Controls the icon that will be used for skipped/empty commands. Set to {0} to hide the icon or disable decorations with {1}.", '`""`', '`#terminal.integrated.shellIntegration.decorationsEnabled#`') }, </del> [TerminalSettingId.TabsFocusMode]: { type: 'string', enum: ['singleClick', 'doubleClick'],


Question:
! The settings to select an codicon for a decoration are not playing well with our product icon theming approach. We want that a product icon theme can style all icons of our UI with a new icons. Each icon that we show should be defined with a component specific name E.g. , , ... That way the theme can come up with a custom icon for each icon location The base icon names (, , ...) should not be used directly, only as defaults, otherwise it gets complicated for a theme to change an icon as it affects many places, unknown to the theme. What might look good with our codicon based product icon theme, might look wrong with a theme that uses a different visual for I suggest to remove the settings as we don't do that at other places. Instead we should refer to product icon themes as the way to change icons.
Requested the aliases in
We do allow switching icons for terminals in this way which I think is fine as they're very temporal: ! I see what you're saying here though, let's remove the setting and leave it up to the icon theme . We have this setting now so it solves that part of what these icon settings allowed:
I was on vacation so I couldn't jump in here. It was not necessary to request new codicons or codicon aliases unless a new icon shape was needed, e.g. for a concept we didn't have yet. There still seems to be a confusion of Codicons vs product icon icons. The Codicon library is a set of default icons that are part of the Codicon font. We use these as default icons in VS Code. See the spec of Codicon: codicon aliases should be component agnostic (no 'terminal', 'debug'). The componnet specific ids go in the product icon registry. These are the ids that wil be used in a product icon theme when styling an icon. Product icon ids are component specific and are defined in the component itself, e.g. as done here: This defines a new product icon , and uses the codicon 'add' icon as the default icon. When using these icons in code, must be used (or in labels by the id ). We never want to reference in components, unless for the default in . Some years ago, all our components directly referenced codicons and their ids. When adding icon theming support we this indirection and I and migrated most components, including terminal. But given the huge number of icon references that work is still not complete and there are still plenty of references to Codicon. That's why a codicon and a product icon () still have the same API and we don't enforce this with the compiler. Also there are some codicon aliases that have component specific names. We can't clean up the aliases in order to not break existing code in extensions. Eventually no one should use there anymore. please do not reference Codicon directly anymore unless in registerIcon please follow the pattern as seen in terminalIcons please don't add component specific Codicon aliases FYI
FYI I was following what seemed to be the thing to do as demonstrated by the icons. Could we remove those and similar examples and/or add a comment with this guidance?
Good point, we should clean these up. The codicons have been around from old times before we did the product icons. There are product icon registration under the same name , so we can remove the codicons that are just aliases, and give the others a different name, to avoid confusion.

export enum Selector { TerminalView = `#terminal`, <del> CommandDecorationPlaceholder = `.terminal-command-decoration.codicon-circle-outline`, CommandDecorationSuccess = `.terminal-command-decoration.codicon-primitive-dot`, CommandDecorationError = `.terminal-command-decoration.codicon-error-small`, </del> <ins> CommandDecorationPlaceholder = `.terminal-command-decoration.codicon-terminal-decoration-incomplete`, CommandDecorationSuccess = `.terminal-command-decoration.codicon-terminal-decoration-success`, CommandDecorationError = `.terminal-command-decoration.codicon-terminal-decoration-error`, </ins> Xterm = `#terminal .terminal-wrapper`, XtermEditor = `.editor-instance .terminal-wrapper`, TabsEntry = '.terminal-tabs-entry',


Question:
! The settings to select an codicon for a decoration are not playing well with our product icon theming approach. We want that a product icon theme can style all icons of our UI with a new icons. Each icon that we show should be defined with a component specific name E.g. , , ... That way the theme can come up with a custom icon for each icon location The base icon names (, , ...) should not be used directly, only as defaults, otherwise it gets complicated for a theme to change an icon as it affects many places, unknown to the theme. What might look good with our codicon based product icon theme, might look wrong with a theme that uses a different visual for I suggest to remove the settings as we don't do that at other places. Instead we should refer to product icon themes as the way to change icons.
Requested the aliases in
We do allow switching icons for terminals in this way which I think is fine as they're very temporal: ! I see what you're saying here though, let's remove the setting and leave it up to the icon theme . We have this setting now so it solves that part of what these icon settings allowed:
I was on vacation so I couldn't jump in here. It was not necessary to request new codicons or codicon aliases unless a new icon shape was needed, e.g. for a concept we didn't have yet. There still seems to be a confusion of Codicons vs product icon icons. The Codicon library is a set of default icons that are part of the Codicon font. We use these as default icons in VS Code. See the spec of Codicon: codicon aliases should be component agnostic (no 'terminal', 'debug'). The componnet specific ids go in the product icon registry. These are the ids that wil be used in a product icon theme when styling an icon. Product icon ids are component specific and are defined in the component itself, e.g. as done here: This defines a new product icon , and uses the codicon 'add' icon as the default icon. When using these icons in code, must be used (or in labels by the id ). We never want to reference in components, unless for the default in . Some years ago, all our components directly referenced codicons and their ids. When adding icon theming support we this indirection and I and migrated most components, including terminal. But given the huge number of icon references that work is still not complete and there are still plenty of references to Codicon. That's why a codicon and a product icon () still have the same API and we don't enforce this with the compiler. Also there are some codicon aliases that have component specific names. We can't clean up the aliases in order to not break existing code in extensions. Eventually no one should use there anymore. please do not reference Codicon directly anymore unless in registerIcon please follow the pattern as seen in terminalIcons please don't add component specific Codicon aliases FYI
FYI I was following what seemed to be the thing to do as demonstrated by the icons. Could we remove those and similar examples and/or add a comment with this guidance?
Good point, we should clean these up. The codicons have been around from old times before we did the product icons. There are product icon registration under the same name , so we can remove the codicons that are just aliases, and give the others a different name, to avoid confusion.

await terminal.assertCommandDecorations({ placeholder: 1, success: 0, error: 1 }); }); }); <del> describe('Custom configuration', function () { it('Should update and show custom icons', async () => { await createShellIntegrationProfile(); await terminal.assertCommandDecorations({ placeholder: 1, success: 0, error: 0 }); await terminal.runCommandInTerminal(`echo "foo"`); await terminal.runCommandInTerminal(`bar`); await settingsEditor.addUserSetting('terminal.integrated.shellIntegration.decorationIcon', '"zap"'); await settingsEditor.addUserSetting('terminal.integrated.shellIntegration.decorationIconSuccess', '"zap"'); await settingsEditor.addUserSetting('terminal.integrated.shellIntegration.decorationIconError', '"zap"'); await terminal.assertCommandDecorations(undefined, { updatedIcon: "zap", count: 3 }); }); }); </del> describe('terminal.integrated.shellIntegration.decorationsEnabled should determine gutter and overview ruler decoration visibility', function () { beforeEach(async () => { await settingsEditor.clearUserSettings();


Question:
<!-- 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: V1.70.0 OS Version: Ubuntu 20.04 Steps to Reproduce: to latest V1.70.0 version of VSCode starship prompt for the bash shell. I have my starship prompt configured to update if the previous command execution failed for unknown reasons. After the latest update, every command execution seems to fail only in VSCode's terminal. Below is the expected behaviour, in a bash terminal: The screenshot of the same with colors: ! Now in the VSCode's terminal (running bash): (It shows the error condition even in a brand new instance of the terminal) A screenshot of the same with colors: ! This behaviour of always erroring out even for a successful command execution started today after VSCode auto updated to V1.70.0 Below is the information I got from menu: Version: 1.70.0 Commit: Date: 2022-08-04T04:38:48.541Z Electron: 18.3.5 Chromium: 100.0.4896.160 16.13.2 V8: 10.0.139.17-electron.0 OS: Linux x64 5.15.0-43-generic snap
Did you notice
, thanks for the prompt response! Yes, by disabling shell-integration, starship prompt started behaving as expected. Shall I close this issue or consider this a bug with shell-integration ?
I don't see why there was a need to enable Shell Integration by default, spent the last 2 hours trying to figure out what was wrong
This probably has nothing to do with starship (I have the same issue without starship). This is just a specific case of and should probably be closed as a duplicate

__vsc_update_prompt <ins> __vsc_restore_exit_code() { return $1 } </ins> __vsc_prompt_cmd_original() { __vsc_status="$?" # Evaluate the original PROMPT_COMMAND similarly to how bash would normally


Question:
<!-- 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: V1.70.0 OS Version: Ubuntu 20.04 Steps to Reproduce: to latest V1.70.0 version of VSCode starship prompt for the bash shell. I have my starship prompt configured to update if the previous command execution failed for unknown reasons. After the latest update, every command execution seems to fail only in VSCode's terminal. Below is the expected behaviour, in a bash terminal: The screenshot of the same with colors: ! Now in the VSCode's terminal (running bash): (It shows the error condition even in a brand new instance of the terminal) A screenshot of the same with colors: ! This behaviour of always erroring out even for a successful command execution started today after VSCode auto updated to V1.70.0 Below is the information I got from menu: Version: 1.70.0 Commit: Date: 2022-08-04T04:38:48.541Z Electron: 18.3.5 Chromium: 100.0.4896.160 16.13.2 V8: 10.0.139.17-electron.0 OS: Linux x64 5.15.0-43-generic snap
Did you notice
, thanks for the prompt response! Yes, by disabling shell-integration, starship prompt started behaving as expected. Shall I close this issue or consider this a bug with shell-integration ?
I don't see why there was a need to enable Shell Integration by default, spent the last 2 hours trying to figure out what was wrong
This probably has nothing to do with starship (I have the same issue without starship). This is just a specific case of and should probably be closed as a duplicate

eval "${cmd:-}" done else <ins> __vsc_restore_exit_code "${__vsc_status}" </ins> eval "${__vsc_original_prompt_command:-}" fi __vsc_precmd


Question: I noticed this in smoke test runner logs leading me to think that the type of the exit code is not a but an now?

disturl "https://electronjs.org/headers" <del> target "19.0.11" </del> <ins> target "19.0.12" </ins> runtime "electron" build_from_source "true"


Question: I noticed this in smoke test runner logs leading me to think that the type of the exit code is not a but an now?

"git": { "name": "electron", "repositoryUrl": "https://github.com/electron/electron", <del> "commitHash": "a5cafd174d2027529d0b251e5b8e58da2b364e5b" </del> <ins> "commitHash": "b05ccd812e3bb3de5b1546a313e298961653e942" </ins> } }, "isOnlyProductionDependency": true, "license": "MIT", <del> "version": "19.0.11" </del> <ins> "version": "19.0.12" </ins> }, { "component": {


Question: I noticed this in smoke test runner logs leading me to think that the type of the exit code is not a but an now?

"cssnano": "^4.1.11", "debounce": "^1.0.0", "deemon": "^1.4.0", <del> "electron": "19.0.11", </del> <ins> "electron": "19.0.12", </ins> "eslint": "8.7.0", "eslint-plugin-header": "3.1.1", "eslint-plugin-jsdoc": "^39.3.2",


Question: I noticed this in smoke test runner logs leading me to think that the type of the exit code is not a but an now?

constructor(modulePath: string, args?: string[] | undefined, options?: UtilityProcessOptions); postMessage(channel: string, message: any, transfer?: Electron.MessagePortMain[]): void; kill(signal?: number | string): boolean; <del> on(event: 'exit', listener: (code: number | undefined) => void): this; </del> <ins> on(event: 'exit', listener: (event: Electron.Event, code: number) => void): this; </ins> on(event: 'spawn', listener: () => void): this; } }


Question: I noticed this in smoke test runner logs leading me to think that the type of the exit code is not a but an now?

this._register(Event.fromNodeEventEmitter<void>(this._process, 'spawn')(() => { this._logService.info(`UtilityProcess<${this.id}>: received spawn event.`); })); <del> this._register(Event.fromNodeEventEmitter<number | undefined>(this._process, 'exit')((code: number | undefined) => { code = code || 0; </del> <ins> const onExit = Event.fromNodeEventEmitter<number>(this._process, 'exit', (_, code: number) => code); this._register(onExit((code: number) => { </ins> this._logService.info(`UtilityProcess<${this.id}>: received exit event with code ${code}.`); this._hasExited = true; this._onExit.fire({ pid: this._process!.pid!, code, signal: '' });


Question: I noticed this in smoke test runner logs leading me to think that the type of the exit code is not a but an now?

resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.4.207.tgz#9c3310ebace2952903d05dcaba8abe3a4ed44c01" integrity sha512-piH7MJDJp4rJCduWbVvmUd59AUne1AFBJ8JaRQvk0KzNTSUnZrVXHCZc+eg+CGE4OujkcLJznhGKD6tuAshj5Q== <del> electron@19.0.11: version "19.0.11" resolved "https://registry.yarnpkg.com/electron/-/electron-19.0.11.tgz#0c0a52abc08694fd38916d9270baf45bb7752a27" integrity sha512-GPM6C1Ze17/gR4koTE171MxrI5unYfFRgXQdkMdpWM2Cd55LMUrVa0QHCsfKpsaloufv9T65lsOn0uZuzCw5UA== </del> <ins> electron@19.0.12: version "19.0.12" resolved "https://registry.yarnpkg.com/electron/-/electron-19.0.12.tgz#73d11cc2a3e4dbcd61fdc1c39561e7a7911046e9" integrity sha512-GOvG0t2NCeJYIfmC3g/dnEAQ71k3nQDbRVqQhpi2YbsYMury0asGJwqnVAv2uZQEwCwSx4XOwOQARTFEG/msWw== </ins> dependencies: "@electron/get" "^1.14.1" "@types/node" "^16.11.26"


Question: Type: <bBug</bnotebook an image from the workspace into a markdown cell Bug this inserts the full uri, such as It should insert the relative path instead VS Code version: Code - Insiders 1.71.0-insider (Universal) (, 2022-08-10T05:18:38.020Z) OS version: Darwin x64 21.6.0 Modes: Sandboxed: Yes <details<summarySystem Info</summary </details<!-- generated by issue reporter --

import * as path from 'path'; import * as vscode from 'vscode'; import * as URI from 'vscode-uri'; <ins> import { Schemes } from '../util/schemes'; </ins> const imageFileExtensions = new Set<string>([ '.bmp',


Question: Type: <bBug</bnotebook an image from the workspace into a markdown cell Bug this inserts the full uri, such as It should insert the relative path instead VS Code version: Code - Insiders 1.71.0-insider (Universal) (, 2022-08-10T05:18:38.020Z) OS version: Darwin x64 21.6.0 Modes: Sandboxed: Yes <details<summarySystem Info</summary </details<!-- generated by issue reporter --

return; } <ins> const docUri = getParentDocumentUri(document); </ins> const snippet = new vscode.SnippetString(); uris.forEach((uri, i) => { <del> const mdPath = document.uri.scheme === uri.scheme ? encodeURI(path.relative(URI.Utils.dirname(document.uri).fsPath, uri.fsPath).replace(//g, '/')) </del> <ins> const mdPath = docUri.scheme === uri.scheme && docUri.authority === uri.authority ? encodeURI(path.relative(URI.Utils.dirname(docUri).fsPath, uri.fsPath).replace(//g, '/')) </ins> : uri.toString(false); const ext = URI.Utils.extname(uri).toLowerCase();


Question: Type: <bBug</bnotebook an image from the workspace into a markdown cell Bug this inserts the full uri, such as It should insert the relative path instead VS Code version: Code - Insiders 1.71.0-insider (Universal) (, 2022-08-10T05:18:38.020Z) OS version: Darwin x64 21.6.0 Modes: Sandboxed: Yes <details<summarySystem Info</summary </details<!-- generated by issue reporter --

return snippet; } <ins> function getParentDocumentUri(document: vscode.TextDocument): vscode.Uri { if (document.uri.scheme === Schemes.notebookCell) { for (const notebook of vscode.workspace.notebookDocuments) { for (const cell of notebook.getCells()) { if (cell.document === document) { return notebook.uri; } } } } return document.uri; } </ins>


Question:
Testing As mentioned in the title it should be in this modal: <img width="405" alt="image" src="https://user-"
Thanks

const actions: string[] = [ localize('saveWithConflict', "Save with Conflicts"), <del> localize('discard', "Don't save"), </del> <ins> localize('discard', "Don't Save"), </ins> localize('cancel', "Cancel"), ];