TL;DR; Kinda. The concepts within AtomLinter should be split in two, for this to move into the core:
- Run these function(s) on save for files of these grammar(s)
- Display these messages, and allow interaction with them.
Read on for the explanation:
Generalizing the notion of
linting a little: my package (
go-plus) does many things when a file is saved, and then optionally displays messages to the user (e.g. info, warning, error) associated with each tool I run. These include things like:
go build /
go test (yes, we can compile on save in go because compilation times are wonderfully fast)
(Back to generalizing:) When you think about it, linting really is about:
- Call a function (which might invoke a tool)
- Display output to user in a formatted way
This necessitates having a pipeline of functions to run on save, and then having a consistent user experience for viewing the output, and optionally taking action (e.g. source, filename, line, column, message + gutter marker + optionally a highlight of the actual range associated with the issue).
AtomLinter addresses both items above by providing a common API for integration of functions to call on save, and by providing a panel for the display of output.
atom-message-panel also addresses the
display output aspect, and I’ve integrated it into
omnisharp-atom has also provided an interesting implementation of a message panel, which - while it could be improved - more closely aligns with what I’d like to see (and @park9140 agrees).
should Atom have a linter as part of Atom core?
No (but bear with me ). It sure would be nice if the following were in the core:
- A registry of functions to run when files of a particular grammar are saved
- An API for publishing “messages” associated with tools that have been run
error messages, with source, filename, line, column, message + gutter marker + click on error to go to the message’s location in an editor
- tool output (i.e. stdout / stderr from running a tool) - this could also be used for build output, or to allow package authors to print informational text about their package
- errors from atom itself (i.e. the ones that pop up on the right - now (
0.166.0) - when an unhandled error occurs
In discussing with @park9140, the latter is something that begins to approximate “IDE” features. So it might be seen as an overreach of scope for the core.
But why haven’t I integrated
go-plus with AtomLinter (
golang is notably absent from the list of
AtomLinter plugins, and it’s almost certainly because
- Because it would further restrict my audience and increase the barrier to successful use of my package (they already have to install
autocomplete-plus but we’re working on upstreaming that right now)
go-plus does much more than just linting
So there is value in having this functionality in the core (or rather, installed as a default package). Having functionality like this in the core with an API for each that I can integrate with ensures that I stop doing this in a custom way (and throw away a bunch of code!, particularly with regard to my
What’s the right way forward? Split apart the two problem spaces? Build a truly fantastic package for a message panel that is an Atom package (as opposed to a node package, like
atom-message-panel is), and then contribute it back to the
atom organization? Evolve AtomLinter and contribute it back to the
atom organization? Do nothing? We’ll only know if @nathansobo, @probablycorey, @kevinsawicki, @thedaniel, and others chime in.