Ale: Tools to trouble-shoot when ALE stops working

Created on 12 Jan 2017  路  13Comments  路  Source: dense-analysis/ale

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

  • when ALE last tried to validate the file ("30 seconds ago", or just a full YYYY-MM-DD HH:MM:SS timestamp if that's simpler)
  • what file type and what linter it used
  • what external command it ran
  • how long the command took to run (or if it's still running)
  • what exit status that command returned
  • how many lines of output that command returned (and maybe first 5 + last 5)
enhancement

Most helpful comment

I just enhanced :ALEInfo so it attempts to output linter variables. This should be useful for getting information for bug reports, etc.

All 13 comments

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

sublee picture sublee  路  3Comments

garand picture garand  路  4Comments

alexlafroscia picture alexlafroscia  路  4Comments

aressler38 picture aressler38  路  3Comments

lervag picture lervag  路  3Comments