Please consider an option to disable plugin warnings, at least temporarily #8152
Comments
|
I really think that eslint package should capture those errors and handle them in a nice way. Turning off notifications is masking the actual issue which is that the package is not behaving. Can you open an issue on your eslint package's repo? |
|
@benogle -- Closing this dismissively is masking the issue ;) My point is this -- Atom itself becomes annoying when a plugin is mis-behaving. The plugins are throwing errors, but Atom is the cause behind a giant red box that takes up a large portion of my screen. And the reason that it's misbehaving isn't always critical enough to say "HEY, PAY ATTENTION THIS PLUGIN IS BROKEN!!!!". In my specific case, I know why it's mis-behaving and am fine with it (I'm working on a branch of eslint itself that is incompatible with the version that the plugin is using, so there is a mismatch in config files, but only in that directory). In a different case, I was seeing errors because a plugin was trying to access something via the internet and I was working offline. Yes, the plugin shouldn't be throwing errors for that, but I as a user also shouldn't be forced to go into config, disable the plugin, then later remember to re-enable it. What you're saying is akin to "put up with the warnings, or disable the plugin until it's fixed". I'll reiterate that although the warnings are from plugins, the giant red boxes are not. I'm not suggesting turning warnings off. I'm suggesting an option that says "Yes, I realize there's an error here, I don't want to be notified of it for a while". |
|
Are they all the same error? Maybe something like atom/notifications#12 would help? Can you paste one of the errors into this issue (a screenshot is fine)? |
|
In this case, yes. And as long as the "group by" has the ability to dismiss issues "permanently", I'm fine with it. But the issue I'm concerned with is a bit different, as with the issue you linked I foresee:
So you're still left with "deal with this giant red box or disable the plugin" |
|
I'm 👎 on disabling notifications globally for the following reasons:
I can, however, see a button to disable specific notifications for the current session, which you seem to be getting at (in that vein, could you please make an enhancement request to atom/notifications?). |
|
@50Wliu -- Agreed, I suppose specific notifications are the more important point. I wasn't aware of a plan to group them :) |
|
Any progress on this? Omnisharp has non-critical errors out the wazoo. |
|
These warnings are seriously the most annoying thing in the world. I can't hide them because the plugin causing them keeps throwing them up until there are no more errors in my code, but it's hard to fix my code when these frustrating bubbles keep popping up. For the love of all that is holy, provide a config option to disable them! And I'm not talking about just one plugin. |
|
I know that disabling notification is not right solution for the real problem (broken plugins), but sometimes it would be very useful to suppress errors from some plugins. It may be just an option. Even hidden behind developer console. |
|
Perhaps instead of disabling them or hiding them, a config option could be provided to easily decrease/increase the scale of them. Unless that already exists, but it doesn't look like it does. |
|
Would be really nice to have. This is an editor. I don't really care if a plugin isn't working. At least make it a small icon somewhere... |
|
While hiding the errors certainly isn't the right solution, it can help preserve our sanity ;) You can do this with a custom stylesheet (instructions for Mac):
Voila, no more errors! (don't blame me if you miss something important though - sadly there's no information I can see in the markup to allow you to only hide notifications for a certain plugin) |
|
What about giving the errors their own tab rather than overlaying them? |
|
Agreed, if you really wont provide or allow a way of disabling them, they need to be a lot less intrusive. A big red box on top of your code is unacceptable. Either an icon in the bottom bar, or maybe a small box on the bottom of the sidebar would be much less annoying. As an end user, it shouldn't be my concern or problem if a plugin's causing Atom to flip out, especially if its working fine. Case in point, the PHPCS plugin - it causes errors to flag up a lot because if you start typing code, it's constantly running phpcs and naturally will cause a failure if you're in the middle of writing something. Yes, the plugin author needs a better way of doing that, but at the same time Atom needs a better way of handling when this does happen. |
|
👍 PLEASE allow a way to disable plugin errors. This has been driving me crazy. I'm about to disable all errors, but I worry that I may actually miss something important and it'll cause more harm. |
|
The earlier idea of using a CSS override was fantastic, although I'd suggest using something like the following so that you can still see that there is an error (hover over to make it more visible), but you are not restricted from working past it. atom-notification.error {
opacity: 0.05;
}
atom-notification.error:hover {
opacity: 1.0;
}These boxes absolutely kill me on packages such as linter-reek where the author seems t 8000 o think they should be used for notifying users of errors in their own (non-plugin) code, obscuring said code in the process: AtomLinter/linter-reek#35 (comment) Another tip: Clicking inside one of the boxes and then hitting [Esc] on your keyboard will close all the currently open alerts. |
|
Yeah the issue is linters. Every time I press any key, a new error pops up because the linter tries to lint (the error message has to do with some rule being configured incorrectly, but it's not a rule I've defined, it's within AirBnb's eslint package). It's incredibly frustrating, and if someone can point me in the right direction (disabling warnings from specific plugins) I'm happy to solve the problem myself. |
|
Here's my style solution: atom-notification.error {
width: 32px;
height: 32px;
}
atom-notification.error:hover {
width: auto;
height: auto;
}This will make the show up as consecutive small red boxes in the top-right. If you hover over them they become full-size. Out of the way but still catch your eye to let you know something's up. |
|
My temporary solution is disabling "Lint As You Type" checkbox (in linter plugin). It stopped those annoying alerts unless I really make an error and save the file. |
|
My solution was that I stopped using Atom and switched to VS Code anywhere I would have used Atom. |
|
Can vs code have vim-style hot keys?
…On Thu, Dec 8, 2016, 8:22 PM Chris ***@***.***> wrote:
My solution was that I stopped using Atom and switched to VS Code anywhere
I would have used Atom.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#8152 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAMJahYEc3MFkHJ19BqrUos4_UhgtTbwks5rGK1lgaJpZM4Fidzk>
.
|
|
It has a vim extension, yes. It's also built on Electron, written in TypeScript, probably anything that's possible in Atom can be done in VS Code. But it seems to perform way faster and has less intrusive notifications. |
|
Hmm, I'll have to give it a go. I have my atom customized pretty heavily.
Shortcut keys I use:
https://github.com/NullVoxPopuli/dotfiles/blob/master/home/.atom/keymap.cson
(the big thing for me is being able to customize everything to fit my
style, and I just am not aware of vs code's capabilities)
…On Thu, Dec 8, 2016, 8:57 PM Chris ***@***.***> wro
8000
te:
It has a vim extension, yes. It's also built on Electron, written in
TypeScript, probably anything that's possible in Atom can be done in VS
Code. But it seems to perform way faster and has less intrusive
notifications.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#8152 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAMJarY0DUWWSzpvW1UKFuWZokwT_tG6ks5rGLV7gaJpZM4Fidzk>
.
|
|
@manuelmhtr as @benogle said in his original comment you should really open an issue on whatever linter is throwing those errors. Linters shouldn't be using Notifications to present lint errors (linter already has its own UI/UX for that). |
|
@50Wliu We have. Apparently this expectation is not well communicated to Linter plugin authors: AtomLinter/linter-reek#35 (comment) |
|
Yeah, that's definitely not what Notifications was designed for. linter-reek should be taking advantage of linter's UI components, like linter-coffeelint does. Notifications should be one-time, "hey, look at this!" alerts. |
|
First of all, let me thank the Atom contributors from building such a hackable, open editor. It is my editor of choice because of the integrations and its use of web tech. That said, the notifications are the most annoying thing about Atom. Makes me really unproductive. The feeling is strong to want to switch editors. |
|
For a workaround, here's some updated styles based on @hiddentao's solution: atom-notification.error {
width: 30px !important;
height: 42px;
.close:before {
display: none;
}
}
atom-notification.error:hover {
width: 32em !important;
height: auto;
.close:before {
display: inline-block;
}
} |
|
The top solution out of what I've seen is:
A further list of issues that may end up panning out:
|
|
A great option would be:
Selecting it would hide all errors from that package until the next time Atom is restarted. It lets people hide unhelpful/annoying errors, but also addresses the "what if there's an important error" problem, because on the next restart you'll see the error the first time it happens. |
I think that this may be a good option for developers who want to always know when something goes wrong (at least when they first start the editor). However, for myself and I would guess others, I would propose to having an editor that doesn't scream at the user with errors (kind of like the concept of graceful degradation on the web). Often I need to open and finish something quickly, and don't want to have to deal with or even see the errors that come up. If something doesn't work, then I will work around it in the moment. When I am not in a rush, I would like to be able to go back and fix any issues the editor has (with packages or with core or anything). This is why I think that a small notification on the status bar (like the "10" in the image below) is enough for this: |
|
Hard luck, bye bye notifications until they fix this. |
|
atompls |
|
FYI, I just did the "disable notifications completely" CSS hack - I haven't seen a single notification that was relevant to me, and lots that were not. |
|
I really think a lot of this could be avoided if linter packages simply provided a button when you wanted to Lint rather than Linting continuously. Even if the linter only ran on Save, this would be better than the continuous memory leeching, resource intensive Linting that a lot of these packages use. |
|
As I've said previously, Notifications are not meant to convey linting errors. There are dedicated UIs for that. If you are using a linter package that is using Notifications to display errors and warnings, I would encourage you to open an issue on that package asking them to move to the standardized linter UI instead. |
If you look at the screenshots shared by @markkahn, you'll see that the issue isn't that lint plugins are using the notifications system for lint warnings; the issue is that the lint plugin is failing because of a dependency issue, and triggering a new notification about it on every keystroke (so, constantly). The problem is that this is a legitimate error, but it's unimportant. I don't care that my linter package is being finicky today, I just want to get back to coding. The desired solution is an ability to selectively disable the permissions for the notification on a package-by-package basis. Some way to block To be clear, I have immense respect for OSS maintainers (I'm one too!), and I wholeheartedly believe that I am not "owed anything" by folks who spend their free time building tools to make my job easier. But, I also feel like folks who bring up an issue should be able to have a discussion about it (even if that discussion just leads to "I understand the issue, but this isn't a priority for us at all right now"). EDIT: well, a few minutes have passed, and I feel bad for the tone of this message. I can totally understand that with so many issues, it's impossible to give each a thorough discussion, and it's entirely possible that there are much larger fires to put out than this. If I were to re-write this, I would focus on just clarifying the misunderstanding without impugning any responsibility on maintainers to address it. |
I think this can maybe be explored if we can find a good UI for C173 it. If you can flesh that idea out you should file a new issue on atom/notifications. |
|
The UI here should be pretty simple - on the error notifications, next to
where it currently says ‘hide all notifications of this type’, add a button
that says ‘disable all of this type’ (at least for a day)
As is, I’ve had to just CSS hide all notifications completely to make Atol
useable.
…On Sun, Feb 11, 2018 at 6:32 PM Wliu ***@***.***> wrote:
The desired solution is an ability to selectively disable the permissions
for the notification on a package-by-package basis.
I think this can maybe be explored if we can find a good UI for it. If you
can flesh that idea out you should file a new issue on atom/notifications
<https://github.com/atom/notifications>.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#8152 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ADGKdmRUMIkm9WrqsyNHydb7oDwWqpUHks5tT6LDgaJpZM4Fidzk>
.
|
|
This issue has been automatically locked since there has not been any recent activity after it was closed. If you can still reproduce this issue in Safe Mode then please open a new issue and fill out the entire issue template to ensure that we have enough information to address your issue. Thanks! |
My eslint plugin is currently throwing warnings every time I hit a key, but only when working in the eslint project itself.
I'm fine with the plugin being broken, I'm not fine with it taking up half of my screen with a giant red warning box that I can't ever dismiss (because whenever I type anything another one just pops up).
I'm not sure what the best solution is here, or if there is one in place already (I couldn't find it), but I'd suggest something along the lines of chrome's "prevent additional alert messages" option that would disable all warnings from that plugin until the editor is restarted, projects switched, or some other trigger.
The text was updated successfully, but these errors were encountered: