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 #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 #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.

[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 #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.

[vscodenpa]

🙂 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.

[nonoash]

I'm facing a problem where this option would solve it.
When using code runner extension and having the output opened in a new window (instead of a tab in vscode panel) whenever i run a script it will automatically open the output tab on top of my output window.
Which gives me 2 mirrored outputs and kind of ruins the purpose and goal of opening output as external window

edit: i've opened an issue on extensions repo too:
formulahendry/vscode-code-runner#1177

[gjsjohnmurray]

@benibenj any more thoughts on this? I'm willing improve my PR if it's deemed to need changes, e.g. greater configurability.

[benibenj]

We are not 100% sure yet how this should work. We are currently thinking it could behave the same way notification does. This would mean:

• enable/disable per extension
• not having a setting for this but storing in storage
• have a UI action to see the toggles
• block the reveal on the API level

Currently we are thinking not to have a global toggle but just per extension (no action like do not disturb for notifications)

Let me know if you have any thoughts about this approach. I still need to discuss this with @bpasero. Let me get back to you next week. Please ping me if I forget.

Edit:
Will take one more week to get back, due to limit availability this week, apologies.

[StringEpsilon]

@benibenj

enable/disable per extension

See #105270 (comment)

not having a setting for this but storing in storage
have a UI action to see the toggles
block the reveal on the API level

I'd much prefer a general solution that keeps my desired bottom panel afixed than one where I have to chase down every offending extension and check how I can disable the behavior. For instance sometimes I have to disable the extra terminal and the opening of the Debug Panel for debugging because they obstruct my workflow. I know how to do that, but it is a little annoying. If I could tell VS Code just to keep the most important panel for more than half of my work in place and in focus, that would be better than having half a dozen individual ways to keep it where I want it.

At the very least, I'd prefer If I don't have to remember to check every single extension I install and make sure to add it to the "no output panel" list.

[benibenj]

Ok, lets start off with a single setting for the ouput channel, similar to what is suggested in the PR #205225;