I noticed lately that ale no longer highlights lint errors for me (Python source, using flake8). I've no idea how to debug what's going wrong.
I'm thinking it would be nice to have a :ALEStatus command that would provide some insight into what's going on. Things like
One addition that would help with this would be some way of outputting an error for a linter which ran and produced errors without the errors being in the regular error format. flake8 can return stack traces when it fails, for example.
A couple of commands I found useful while investigating my issue
com! ALECheckNow call ale#Queue(0)
com! ALEShowCommand echo ale_linters#python#flake8#GetCommand(bufnr('%'))
but now I see that the 2nd is not very universal...
e0928d099116e27f0203b0a365506bfecbe1a6e3 is at fault with above problem. Have no idea where he got --stdin-display-name option from. flake8 has no such thing.
Sorry for now being helpful the right way, I'm too lazy to open issues or investigating properly.
@mgedmin reverting that one line fixes the problem you had with flake8.
It's a valid option in more recent versions of flake8. http://flake8.pycqa.org/en/latest/user/options.html#cmdoption-flake8--stdin-display-name
Perhaps some version detection is needed.
sudo pip install --upgrade flake8 fixed flake8 linter for me.
I believe the :ALEInfo command was added since this issue was opened.
I think it should be enhanced with a command history. So ALE would track the command history for each linter run, and then print the commands out again when :ALEInfo is used.
I just enhanced :ALEInfo so it attempts to output linter variables. This should be useful for getting information for bug reports, etc.
Also now some of the global options.
I just added some recent command history to :ALEInfo, and an extra command :ALEInfoToClipboard for quickly copying everything to your clipboard.
Now the history should print the exit codes for commands which ran.
There's an option now g:ale_history_enabled for turning the history completely off. If it's off, ALE should skip whatever processing is needed for the command history, so it might run faster.
Now, if g:ale_history_log_output is set to 1, which is set to 0 by default, ALE will store the complete output of every command in the history List, and output that information from :ALEInfo.
I think that's enough information for now. Logging the time taken might be something to add in future.
I found that with linters (specifically eslint and standard) that print lint output on stdout, but genuine linter errors on stderr, that I had to add 'output_stream': 'both' to the linter definition to allow the logger to capture the stderr output. Only then could I understand what was going wrong.
For e.g.
call ale#linter#Define('javascript', {
\ 'name': 'standard',
\ 'executable_callback': 'ale_linters#javascript#standard#GetExecutable',
\ 'command_callback': 'ale_linters#javascript#standard#GetCommand',
\ 'callback': 'ale_linters#javascript#standard#Handle',
\ 'output_stream': 'both',
\})
Is there a better way to report linter failures?
Happy to make a PR if you have suggestions
There's no straight answer. It depends on the linter. For eslint, it should be reporting all but one problem, for invalid configuration files: https://github.com/w0rp/ale/issues/398
I've considered capturing stderr output anyway when g:ale_history_log_output is on, just for ALEInfo. That might be safe to do for everything, but would complicate the code slightly.
Most helpful comment
I just enhanced
:ALEInfoso it attempts to output linter variables. This should be useful for getting information for bug reports, etc.