First of all, hi. Long time no see.
So I’ve skimmed through and I have a bit of a concern about new panel design. Tables are fine and all, but what about long multi-line messages? I believe some providers still use that (including atom-haskell stuff, provided user chose to use linter as a frontend). I’ve seen long messages in the tooltips, but for keyboard-oriented workflow this seems somewhat awkward.
Also a minor nitpick, but information about what provider generated a message is usually irrelevant, since there are usually one or two providers for a given filetype, so displaying it this prominently seems a little too explicit, don’t you think?
Forgive me if you addressed these in the video, I’m in a bit of a hurry and sound on my system is kinda borked atm, so I’m writing this based on the video only, which I only skimmed.
I hope things have been well for you. I agree that displaying the name of the provider is usually irrelevant because there’s only one or two providers for a given file type. Thing is, it’s configurable, you can turn it off if you want!
I’ve demoed the multi-line messages at the end of the video where you can see a provider make an HTTP request to the eslint docs github repo and fetch a doc for the specific rule and show it inline, providers can provide raw markdown string instead of a callback that does an http request or something.
I have thought about it thoroughly and found that multi-line messages expanding in linter panel is not a good idea, because everytime they expand the scroll position becomes irrelevant and the user has to screen again unless they always look at the top issue. Not only that but it disallows showing the messages in a frame, we are limited to show them as a text list. Showing them in the editor however is a good idea.
At the time of writing, we do not have an atom command that expands the description of the tooltip but I’ll be adding it soon enough. Thanks again for reminding, have a great day
These look nice. But I use a few different linter interfaces and I’m not sure what features are new here. Can you point me to a list?
Nuclide has their own linter-incompatible diagnostics displays. Is there an opportunity here to incorporate their weirdness into a core plugin so they won’t be so weird anymore?
The clang compiler has a syntax that offers “fix ups” some problems. So when the error is “Can’t use ‘.’ with a pointer. Did you mean ‘->’?”, it also knows exactly how to fix the code to apply the suggestion if you want. It’s nice to have an autofix button on the linter. (atom-rtags-plus supports this interface now). It would be nice to have these sort of things built-in to the core.
The new features are
- Tree view decorations
- Mouse over to see errors
- Lots of new commands to bind to keys
- Completely redone bottom status bar
- Message panel with sorting and a table shape
- Async description fetching capability for providers
- Builtin ability to jump to an external resource
- Ability for providers to provide markdown in description instead of hacky html
- Ability for providers to provide solution for issues (that I applied in the demo video)
among many others. Nuclide has had some of these features but I believe it’s a big ball of bloatware, the new linter architecture even splits out the UI so you can have a choice between the UI (we provide linter-ui-default as the default one).