Add an option to prevent side panel from opening

[rgarrigue]

I've this kind of messages that keep popping up the side panel

I guess it's a linter or whatever having small issues. There are multiples culprit, here it's "YAML Support", but I saw other ones. My issue is, I don't give a damn, and it's taking space, and popping up again and again if I close it. So far I could only stick it to the bottom and reduce it to the smallest size before closing... but now and then I like to open an integrated terminal, which lives in the same panel. Then the focus keep being stolen by those same messages.

So I'ld like a VS way to get rid of those. Asking plugin by plugin will never work, even if I knew where to report about those.

[sbatten]

request makes sense but really extensions should not aggressively show the channel. a setting would help the user now but any extensions behaving responsibly may not be able to reliably convey info.

[shankara-n]

Issue seems to be closed now but I can't find any setting to disable the output window from showing up

[StringEpsilon]

I would really like to know why this was closed as "out of scope". The reasoning provided by @sbatten seems incomplete to me. If extension authors should not re-open the panel anyway, why not give the users more control over the panels. What exactly is at risk of breaking, and why is a badly designed extension breaking more important than the overall user experience?

The only reason I use the Panel is the terminal. I sometimes look at the "Output" Panel for triaging an issue I am having but every single time an extension has opened the output panel it was to the immediate detriment of my experience while providing absolutely no positive value in return. To the point that whenever the Output panel opens itself I immediately dismiss it again without looking at the contents - because it is never relevant or informative.

Also worth noting that all the extensions I have had this displeasure with are authored by Microsoft.

[JRodez]

"out-of-scope" they said... So I'm going CLion if this kind of annoyance is OK for Microsoft.

[gjsjohnmurray]

@sandy081 please reopen this.

[jstm88]

@sandy081 please reopen this.

I opened https://github.com/microsoft/vscode/issues/203478 with an extremely thorough explanation on why the issue is still relevant. @sandy081 closed it too, and appears to also be the one closing many of the others.

@sandy081 Do you have some sort of a vendetta against this specific feature? You've been closing these as duplicates even though it's very clear that the issue is not resolved. Users are trying to make their voice heard and you're almost single-handedly shutting down the discussions.

[jstm88]

The first time this issue was reported (that I can find) was https://github.com/microsoft/vscode/issues/33262 from August 2017. Over 6 years ago.

The fact that one was (incorrectly) closed has been used as a justification to close every other ticket addressing the problem, even though it has still not been resolved.

[jstm88]

So I guess that's it then?

Multiple people point out a major issue, write up detailed reports, and suggest good solutions, and one person can just come along and just shut down the report because of a failure to understand the issue?

And then that person just ignores all requests to reopen the ticket for multiple days, despite closing it instantly and without any sort of review?

You know, I really thought VS Code was better than that. But now the Microsoft-ness is coming through loud and clear.

[gjsjohnmurray]

Is #199946 going to mitigate this by allowing Output to be detached into its own window?

[jstm88]

@gjsjohnmurray No. That just shifts the problem elsewhere, and making an entire window pop up constantly would be even worse.

The issue is plugins being able to force the output panel to open. Many of them abuse (or misuse) the API to dump output constantly that is not useful. It's been said that the fault is with those plugins (and that's technically true) but in that way it's just like pop-up windows on the internet. We added pop-up blockers because they were so annoying. VS Code effectively needs the same thing for its own "pop-up output window" nuisance.

The argument has been made that "the output is important so we must allow it" - to which I say who are you to decide what the user wants? That's an insult to the users, who generally do, in fact, know better than Microsoft how they want their editor configured.

[gjsjohnmurray]

allowing Output to be detached into its own window?

Actually I misinterpreted what the referenced change does. It merely opens a static live copy of the output channel's contents. The ability to detach the entire Output view into its own window isn't with us yet.

[jstm88]

Still calling on @sandy081 (who closed this and then just completely abandoned us) to reopen one of these tickets.

The issue still exists. It happens dozens of times per day. It is not possible to fix it any other way.

[gjsjohnmurray]

It is not possible to fix it any other way.

@jstm88 which of your installed extension is/are causing this? Have you raised issues with the extension author(s)? Or considered not using the extension(s)?

Somewhat ironic that your frequent comments on multiple issues are starting to feel to me like the kind of unwanted "spam" you're apparently getting from extensions you choose to install.

[jstm88]

@gjsjohnmurray There are multiple extensions that do this. One of the most common (and the worst offender on my setup) is Microsoft's own C extension.

The argument that we shouldn't do anything is flawed, and it's frustrating that a very small number of developers are using it as a weapon against users to shut down discussion.

I completely understand that, yes, this is technically the extensions' fault. However, with thousands of extensions and who knows how many of them misusing the API, it is absolutely hopeless to get everyone to fix every extension.

That's why we absolutely need an option to prevent focus-stealing on the Output window. There is no other way to fix this problem. I outline in my ticket how this could be done as a per-extension setting, which would allow the user to have control over which of these extensions are allowed to interrupt workflow. A global option would just be easier to implement.

[jstm88]

@gjsjohnmurray Also worth noting that the only reason there are so many duplicates is because multiple issues were improperly closed, and people had to keep opening new tickets and wasting time trying to convince the mods to reopen them.

Given how many "duplicates" have been opened, it's pretty obvious that the users consider this to be a real problem despite what Microsoft might want to pretend.

[jstm88]

To reiterate a few points on the merits of blocking focus-stealing since they've been somewhat lost in closed tickets:

• It will only apply to users who enable the option, so there is no downside to having the option available.
• Badges will still indicate changes, as they do for other tabs. So there won't be a problem with errors being "hidden" as some have suggested. And even then, Microsoft has no right to tell me what errors I want to see or hide... that's Windows 11 thinking.
• Output will still be available and the panel will still behave exactly as it did before, it simply will not force itself to the front against the user's wishes. In fact, badging the output window (and, perhaps as a compromise, displaying a corner notification when the panel attempted to focus) results in a much cleaner experience without reducing user awareness.
• It does not prevent extensions from fixing their own problems. These solutions can be done in parallel.
• To repeat the most important point, Microsoft has no right to tell me how to lay out my editor and what panels I need to see at any given moment. That's for me to decide and for VS Code to respect.

[gjsjohnmurray]

@jstm I think it is worth distinguishing "focus-stealing" from "showing the Output view". I think the latter can already be mitigated (word chosen carefully, as I support the broad direction of your proposal but want to be realistic about the development resources available in the core team, and the competing priorities).

An extension unilaterally showing the Output view is disruptive when that view is a tab on the Panel, because it steals visibility from whichever other tab the user had selected, and was perhaps actively working on.

By relocating the Output view this will no longer happen.

One of the most common (and the worst offender on my setup) is Microsoft's own C extension.

Is there an linkable open issue on that extension's repo?

[jstm88]

@gjsjohnmurray

I'm not sure the distinction between "focus stealing" and "showing" matters that much here.

• If the output panel is not open, any output from extensions will reopen it (usually in the last place it had been before it was closed). In this case, it immediately takes focus away from the previous panel which was shown.
• If the output panel is currently open, but hidden (i.e. not the active tab in a given pane) then it switches the pane to that tab, effectively stealing focus.

Both cases look just about identical to the user.

What I've ended up doing for years is putting the Output panel in the Explorer tab and shrinking it down as small as possible. That way, when the Output panel inevitably steals focus it will at least end up on the most commonly used tab. Of course, whenever I'm working with the Git tab and this happens, I get closer and closer to printing out a VS Code icon, painting a bullseye on it, and hurling my keyboard at it as hard as possible. 😆

By relocating the Output view this will no longer happen.

I'm not sure how that's supposed to help. The default location for the Output panel is in the same tab group as the Terminal. And stealing focus from the Terminal is far, far worse. That's why I moved it in the first place. The Terminal is the single most important view besides the editor itself, and nothing should override either of those. Switching tabs in the main sidebar just ended up the least bad option.

Is there an linkable open issue on that extension's repo?

In fact, yes, the Microsoft C/C++ extension has these issues:

• https://github.com/microsoft/vscode-cpptools/issues/8366 (closed as duplicate)
• https://github.com/microsoft/vscode-cpptools/issues/7234 (closed, will not fix, almost 3 years ago)

If Microsoft can't even fix their own extension (especially one as widespread as this one) then I think we can firmly consider this problem to be in the "never going away" category. I also find it amusing that one of the suggestions in the first issue is to suggest a fix in VS Code itself... so we've got that covered!

Two more quick items:

• You tagged the wrong username in your previous post. I guess if @JSTM wants to participate in the discussion, welcome! 🤣
• Can we officially reopen this issue? The whole initial point of this exercise was to have an open issue, which allows it to be visible and gather additional feedack. (And eventually to actually fix it, of course, but the first step in fixing the problem is acknowledging that it exists. 😉)

[gjsjohnmurray]

At the API level the preserveFocus parameter of the show method can be used by an extension.

My reading of https://github.com/microsoft/vscode-cpptools/issues/7234 is that the developers were open to adding a setting to cover the case raised by the OP, but other changes were subsequently thought to have mitigated/resolved that case, and the OP didn't contest this view, so the issue was closed and is now locked.

I think if you opened a new issue in a non-confrontational way you might be able to make progress with regard to this particular extension.

More generally, it is useful to know that you have already moved Output view off Panel. I haven't yet investigated whether a show(true) call by an extension changes focus in this scenario. I wouldn't expect it to.

[StringEpsilon]

At the API level the preserveFocus parameter of the show method can be used by an extension.

That does not prevent the effective focus stealing in some scenarios.

I had that issue with the 1.x versions of the csharp extension and resorted to patching the shipped js files myself to get rid of the issue, as a bug in the LSP resulted in frequent output panel show() calls. No matter where I put the output panel, it would inevitable disrupt my work. If I put it in any of the sidebar tabs, it would yank me out of whatever panel I was using. If I left it in the bottom panel it would yank me out of the terminal. I have no place I can put the output panel where a forceful show() does not create a disruption of some kind.

What the preserveFocus parameter does , if I recall previous issue discussions correctly, is to prevent focus stealing from the editor. Which is good, but not enough.

It should be noted that the current version of the C# extension does show() the output panel in some cases still. Though I am unable to reproduce that behavior (that's why I haven't filed an issue - it happens randomly maybe once or twice a month for no discernible reason).

[gjsjohnmurray]

If it always calls show() rather than show(true) then it might be worth trying to get those calls changed.

[StringEpsilon]

It doesn't matter if it calls show() or show(true). The very act of forcing the output panel to become visible is disruptive.

For example I may have the editor focused but reading the output from my terminal to debug the section of code I am editing. If the output panel pops up during that it is not technically stealing focus - but it still disrupts what I am doing at the time. If I put the output in the sidebar and and it pops up as I am writing a commit message it will force me out of the source control tab and show the output panel tab, thus disrupting my work (and actually steal focus).

If I put the output panel into the source control tab, the output panel show may force me into the source control tab while I am working with the explorer view. And vice versa.

There is no escaping the thing unless every single extension I use follows protocol and not use the show() api under and circumstance whatsoever. And it can be quite tedious to make sure that is the case. The relevant issues for the C# extension were open for over a year, IIRC.

Edit: Issue 2556 on the vscode-csharp repo was opened in 2018. It is still open (as it affects the still somewhat used and maintained 1.x versions of the extension). Issue 4608 was opened in 2021 and is still open.

[gjsjohnmurray]

Would it help any to move your Terminal into an editor tap, then move that into a floating window, and move Output back to Panel?

[StringEpsilon]

I use a tiling window manager. I don't want any of my vs code stuff to float. So, no that is not an option for me.

I could use a regular terminal under vs code as a tile, but then if the output panel pops up it would eat my editor screen space. That setup would also reduce the real estate for the explorer panel which is kind of annoying.

[jstm88]

@StringEpsilon That's a good point, perhaps the API needs to change preserveFocus to default to true. The no-arg version of something like should always default to the least intrusive mode.

That still leaves the possibility that extensions can abuse it and specify false where it's not warranted - in that scenario we still would need a way to disable the output on a per-extension basis.

In fact, maybe if we think about the focus option as a permission, here's an even more comprehensive solution:

• The show() API defaults to true (i.e. the Output panel does not take focus by default)
• Extensions may specify show(false) in order to specifically override this and focus the panel
• Upon calling show(false) for the first time, VS Code requests permission from the user to allow the output panel to take focus for that extension only
• If the user denies permission, all calls from that extension act as if preserveFocus was set to true
• All extensions gain an option (true/false/unset=false): "Allow this extension to focus the Output panel"

It's a little more involved than a simple "disable" option, but I see some benefits:

• It defaults extensions to not being able to focus, which is actually even better
• It naturally exposes the option at the moment a new extension attempts to display "focused" output
• It fits better with current types of permission systems so it may be easier for some people to understand

I use a tiling window manager. I don't want any of my vs code stuff to float. So, no that is not an option for me.

Likewise. Floating panels (especially ones that appear arbitrarily) are horrible for tiling setups. Especially with Electron apps, which already have enough problems with tiling modes and window properties.

What the preserveFocus parameter does, if I recall previous issue discussions correctly, is to prevent focus stealing from the editor. Which is good, but not enough.

This just caught my eye and it sounds like it also may be necessary to make preserveFocus a little more powerful to prevent the sort of focus stealing we've been discussing. But if it does do what we hope, the above proposal (default true + permissions) would work.

[StringEpsilon]

For me the only acceptable solution is an option to disable the effects of OutputChannel.show() entirely, as that is the only way to avoid the disruptions I explained above, for the reasons I gave (because show() without focusing is disruptive no matter what). I would even take an option to just flatly disable the entire output panel if that is technically easier (= no logging, no ability to even open it manually).

Edit: Compare also #87993 which was another feature request for exactly that: Options to prevent panels from being force-opened. It was dropped for a lack of upvotes.

[gjsjohnmurray]

Pending an acceptable solution (which is beyond my powers) I have been suggesting mitigations.

If you are not already using the Secondary Side Bar, or if you are using only one tab there, perhaps consign Output to its minimum size there.

Or an alternative non-floating home for your Terminal could be in an Editor Group below your main editor area.

[jstm88]

At a technical level, a temporary toggle should be effectively a one-liner. Something like this pseudocode:

if not (config.getBoolForKey("window.blockOutputPanelFocus") {
    ... proceed to focus the panel ...
}

In fact, even if the more complete permission-based system is adopted in the future, we could still use this in the meantime. Just do it like this:

1. Add the option to the next release. Users can add the option manually to our configs and get the benefits immediately.
2. Change the API default to true as soon as possible. Document this change, explain in the documentation that extensions should be extremely careful to limit usage of the focusing mode, and also document that a future change will require permissions before using that mode.
3. Work on the permissions system at whatever pace is warranted.
4. Release the permissions system and simultaneously deprecate the "window.blockOutputPanelFocus" key, which will now be unnecessary with the permissions controls in place.

Regarding disabling Output completely, I know there was resistance to the idea before because it was still considered to be important that there's somewhere for output to go. The one thing we haven't really discussed here is whether it should be possible to close Output and have it not reappear at all. For me, having the tab present isn't an issue. It's only a problem when the tab brings itself to the front. In fact, I'd prefer to have it in a wider area (the same space as the Terminal where it is by default). Then, I could manually switch between Terminal/Output.

[StringEpsilon]

@gjsjohnmurray

I appreciate the creativity, but for me personally I found that the only workaround that does not create other annoyances is to manually patch the extensions by going to the shipped .js files and doing a search-and-replace. And remember to repeat that after the extensions updated. It's great user experience :)

[StringEpsilon]

And to reiterate my earlier comment ( https://github.com/microsoft/vscode/issues/105270#issuecomment-1751671478 ), I would also be happy if the vs code team provided a good explanation for why they do they think adding the option to disable this behavior is undesirable.

We have had, by my count, 12 issues filed on the matter. One (this one) was closed as out of scope. 1 was closed for a lack of upvotes. The rest have been closed as duplicates, including the very first one, #33262, which was closed as a duplicate of this issue for some reason. The only explanation we have are these 2 sentences:

request makes sense but really extensions should not aggressively show the channel. a setting would help the user now but any extensions behaving responsibly may not be able to reliably convey info.

For the amount of disruption the behavior causes, I find that lackluster.

[jstm88]

@gjsjohnmurray Are you going to reopen the issue?

[gjsjohnmurray]

@gjsjohnmurray Are you going to reopen the issue?

As a contributor, not a team member, I don't have that power.

[jstm88]

I guess then that would be @sbatten or @sandy081 then?

Do we have to open (yet another) new ticket, or are we just being ghosted now?

[jstm88]

The January 2024 update came in and contains "Fine-grained control for disabling notifications per extension". It only makes logical sense, then, that we should also have the same control for Output from extensions. Addressing notifications is fine, but notifications are transient and can be ignored. The Output panel is worse because it disrupts the user by breaking the layout that has been specified.

Once again, @sbatten / @sandy081 someone needs to re-open this issue. It's been over 2 weeks without a single peep. You're obviously getting notifications, so the only explanation is that we're being intentionally ignored.

[gjsjohnmurray]

I have submitted PR #205225 that I hope will be considered by the team.

[jstm88]

@gjsjohnmurray That looks great!

From what I can see I think that covers everything, and it looks like the notification will be actionable as well. I can't imagine anyone objecting to this.

I'm still miffed that the VS Code team refuses to even acknowledge the discussion. Being closed means these tickets were effectively hidden (since nobody really browses closed tickets unless they're looking for something specific). We're lucky @gjsjohnmurray was here with the knowledge needed. 👍

So.. since there's an actual MR now, is that sufficient to reopen the ticket? Or do flying pigs need to be implemented first? 🤣

[jstm88]

@sbatten @sandy081

Any updates? I know you're both on the PR but I'm not familiar with how long they usually take to get attention by a reviewer.

Also, while we're waiting on the PR to get reviewed, we still should re-open this issue. Then once the fix goes through the process it can be closed as complete, instead of permanently leaving it in this state. I know it's been left closed throughout this whole process but it really should be open so people can actually see that the issue is being addressed and aren't tempted to submit yet another duplicate.

[Gbox4]

This feature would be fantastic if added. Just adding my temporary fix was to drag the Output panel over to the secondary side bar on the right and making that as small as possible. Still annoying that it steals focus though, this silly annoyance should be easily fixable.

[jstm88]

@Gbox4 https://github.com/microsoft/vscode/pull/205225 by (the amazing!) @gjsjohnmurray fixes this, but Microsoft appears to be actively burying it.

If you look back through the years-long history of issues mentioning this problem, there are a handful of Microsoft employees doing their best to bury any reference to the issue and trying to tell everyone that it's not something that should be fixed The same two who have been hiding, closing, and ignoring all of the bug reports on this also appear to be doing the same with the PR now. I don't know why there's such a vendetta against a simple fix, but there you go.

Honestly, this episode (and particularly the insulting disregard for @gjsjohnmurray 's work) has shown me that VS Code is too far gone.

For a while Microsoft looked to be going in a good direction (Azure had good Linux support, and VS Code was a good editor with a strong open source community). Unfortunately the direction VS Code has been going is way too close to the other side of Microsoft. Just look at what Microsoft is currently doing with Windows 11 for definitive proof of who Microsoft really is as a company. If Microsoft is still willing to do that, then it's hard even to rely on any "open source" projects by that same company. The behavior of Microsoft where they can get away with it makes any related project suspect as well.

Honestly, though, it's all down to @sandy081 and @sbatten failing to address the PR that has enlightened me to the state of VS Code. If this issue had just been open to discussion I really wouldn't have thought much of it. But by actively fighting the users (and even gaslighting them by trying to deny the issue exists) VS Code (as a project) has revealed its true colors.

Given all of that, I've decided it's too risky to continue to rely on VS Code. I've always had my eye on learning Vim motions properly (and I had planned on using them inside VS Code) but after seeing what's happened here I've decided to start the process of moving to Neovim instead. It's going to take some effort but in the long run I don't want to be relying on something that treats users like this. And as a bonus I won't have to deal with fixing things every month when the new update inevitably breaks something.

@gjsjohnmurray We appreciate the contribution you made here... even if Microsoft doesn't.

[starball5]

Related on Stack Overflow: How to block a VS Code extension from opening output window on every parse error

[benibenj]

I would like to see this problem resolved, whether by us directly addressing it or by encouraging the extension(s) responsible to implement a solution.

First, I want to fully understand the core issue. Specifically, I am trying to determine if this problem is confined to the Output view or if it affects revealing views in general. Could you please provide more details on which extensions you have encountered this problem with? I am aware of this being an issue with the C++ extension (as noted in microsoft/vscode-cpptools#7234). Are there other extensions experiencing the same issue?

Regarding potential solutions, the PR by @gjsjohnmurray (#205225) seems promising. However, there might be alternative approaches, possibly akin to the notification settings. Let's explore all viable options to find the best resolution.

[LucasOe]

Are there other extensions experiencing the same issue?

I have the same issue with the .NET Install Tool extension. Every time I open a project it shows the Output panel with the message "Using configured .NET path", even if it has previously been closed.

143657 also mentions the C# extensions and the GitLab extension.

33262 reports this problem for the ESLint extension.

[StringEpsilon]

@benibenj

First, I want to fully understand the core issue. Specifically, I am trying to determine if this problem is confined to the Output view or if it affects revealing views in general.

Theoretically, this applies to all view revealing. Personally I have only experienced this with Output and Debug Console. The latter is far less annoying tho, as it only pops up in response to direct user action and one can disable the opening of the debug console in the launch profile.

Could you please provide more details on which extensions you have encountered this problem with?

The C#-Extension still does this after updating. Not quite as annoying, as it happens infrequently, but it still is a small interruption.

Prior reports indicate:

• Gitlab extension
• C++ extension
• vscode-neovim
• Makefile Tools (161257)
• vscode-server-connector (116107)
• Prettier (112345)
• Ansible VS Code Extension (112345) - at least I think. It's not quite clear from the screenshot.
• YAML Support (105270)
• Java Extension (32872)
• Angular extension (31474)
• vscode-ember (31474)
• vscode-elixir-ls (31474)

Many of those have been fixed or have added a setting that fixes the issue. But it is intensively frustrating as a user to run around all the individual extensions when it could easily be handled with a central setting. In the case of the Omnisharp based C# extension, I even had to go so far as to patch the extension by hand because the GH issue for the behavior was not addressed.

And it's not even a new concept. VS Code already allows me to disable toast notifications for individual extensions or even as a whole ("Do not disturb mode").

As an alternative idea to the current PR: Being able to pin the terminal in place and not have any view reveal action move from away and/or obscure the terminal would fix the issue as well (at least for me). At least as long as input focus is also retained.

[StringEpsilon]

I did some more searching for affected and/or previously affected extensions:

In brackets is the date of the fix.

AvaloniaVSCode (still open crystal-lang-tools (still open) vscode-cmake-tools (still open) vscode-code-runner (still open) lua-language-server (unclear status, see issue 194962 in this repo) aws-toolkit-vscode (october 2022) code-settings-sync (june 2022) Dart-Code (march 2020) metals-vscode (august 2019) platformio-vscode-ide (february 2022) salesforcedx-vscode (april 2019) svelte-vscode (may 2019) vscode-css-peek (2018) vscode-dotnettools (august 2023) vscode-go (april 2019) vscode-graphql (september 2020) vscode-intelephense (april 2019) vscode-ocaml-platform (changelog entry for version 0.6.0) vscode-php-intellisense (february 2017) vscode-phpunit (changelog entry for version 3.1.0) vscode-python (fixed in 2018, 2020 and 2022) vscode-stylefmt (may 2017) vscode-terraform (july 2020) vscode-yaml (august 2020)

Edit: Some more

vscode-idris (still open, since 2018) vscode-textlint (still open) sourcery-vscode (february 2020) vscode-markdownlint (may 2022) vscode-jest (january 2023) vscode-kubernetes-tools (january 2022) vscode-rsp-ui (december 2020) vsc-prolog (november 2018) vscode-solargraph (unclear status. Issues from february 2019)

There are probably a bunch more, but my google-fu is not super strong.

[VSCodeTriageBot]

:slightly_smiling_face: This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[JonKrone]

Could you please provide more details on which extensions you have encountered this problem with? I am aware of this being an issue with the C++ extension (as noted in microsoft/vscode-cpptools#7234). Are there other extensions experiencing the same issue?

To add on to StringEpsilon's list, the Salesforce CLI Integration also focuses the Output channel when you use its various right-click menu menu actions in the file explorer such as Deploy This Source to Org which pushes that file to your Salesforce Org. It does this even for simple success messages.

I appreciate that the extension's UX is largely the responsibility of the extension authors, but as I am effectively forced to use this extension to work in that ecosystem I also want to have control of behavior that's so impactful to my experience of using VSCode itself. I'd love a setting for this.

[benibenj]

Thanks for all your input! I think combining this with the Do not Disturb mode would make sense and so would not require adding a separate setting. It would also allow disabling the behaviour just for a specific set of extensions.

[gjsjohnmurray]

@benibenj I can see some sense in combining this with Do Not Disturb, but I don't think everyone who's interested in this issue (Panel appearing suddenly because extension forces its output channel to display) will want to set Do Not Disturb (i.e. suppress all non-error notifications) for an extension as the only way of suppressing Panel-popup.

Related - the only doc references I've been able to find for Do Not Disturb are in release notes:

• https://code.visualstudio.com/updates/v1_69#_do-not-disturb-mode
• https://code.visualstudio.com/updates/v1_86#_allow-disabling-notifications-per-extension

Perhaps its also time this feature got into the regular doc.

[StringEpsilon]

I would agree. Ideally I would just set a setting once and never ever be bothered again by any extension. But having a way of dealing with individual bad extensions would definitely a huge wine.

That is, if setting the extension to do not disturb does not get rid of all toast notifications. While I don't like those either, they are not nearly as disruptive and more often than not actually informative. Having less information because I don't want to get ripped out of my terminal is not quite optimal.