Mark error on failure to lint

[nospam2998]

With ale's default configuration it enables every known linter and opportunistically attempts to run them all, silently failing in most cases. While this yolo approach might be a reasonable out of the box, a more trusted ale experience can be obtained by explicitly configuring working linters only on known filetypes.

When using such a tightly controlled ale configuration, one might want to get immediate visual feedback whenever any linter fail to execute. Preferably a linter-like error on the first line of the buffer. Such functionality must be hidden behind a configuration option defaulting to disabled, of course. I made an attempt at https://git.netizen.se/ale/commit/?h=wip/lint_fail_err, but gave up and settled with the following work-around in my vimrc instead:

function! ALELinterProblem()
  let l:history = ale#history#Get(bufnr(''))
  if match(l:history, "'status': 1")
    echom l:history
    sign define missing_linter text=!! texthl=Error
    exe ':sign place 1 line=1 name=missing_linter'
  endif
endfunction

augroup ALEMissingLinter
  autocmd User ALELintPost unsilent call ALELinterProblem()
augroup END

While the triggering on the ALELintPost event kind of addresses the problem, having support in ale for reporting linter failure in a noticeable manner would be preferred.

Does the ALE team agree this functionality could at all be desired? If so, would anyone be able to give any hints on how to add it more completely and cleanly than on my branch linked above?

[nospam2998]

No comment at all for the first thirteen months?

It should really be the responsibility of ale to report failures when failing to act as configured. I'm now tempted to claim this is a bug, rather than an enhancement. Linting becomes very unreliable when ale silently ignores this fatal error.

I've rebased the branch on top of current master, and am opening a PR for this.

[w0rp]

No comment at all for the first thirteen months?

It should really be the responsibility of ale to report failures when failing to act as configured. I'm now tempted to claim this is a bug, rather than an enhancement. Linting becomes very unreliable when ale silently ignores this fatal error.

I've rebased the branch on top of current master, and am opening a PR for this.

I generally leave maintainence of ALE to hsanson, apart from when I randomly look at things. (It would be great to have another maintainer too, but it's hard to find someone good who I trust. I've had a message asking for another in the README for a while.) My response time varies from around 2 minutes to around a year sometimes. I hope that doesn't sound sarcastic. Sarcasm isn't really a thing I do. We tend to response faster to PRs than issues.

I'll comment on the PR.

[nospam2998]

Varying response times is something I can relate to on a very personal level, and I do know that you're good at life @w0rp. You're rightly making time for other interesting things apart from ale.

PR #4474 got killed by stale it seems (and reading #719 horrified me!).

My patching got halted a bit due to unneeded complexity. In the past I had no problems running Vader with ale, but following the current instructions requires all contributors to use Docker. While I do believe to understand why, I do not agree putting up such barriers to contribution is optimal. Sure, I have been known to be able to both use and create Docker solutions, I'd rather spend my time on constructive work than to be a part in creating unmaintainable technical debt (which I would argue is practically unavoidable with Docker). I've published the branch topic/docker-free_testing to my git server and it seems to get the job done, even if some tests currently fail on my host (likely due to environment setup reasons. Maybe I should try hiding the details in a container or something, duh‽).

There's also a fix/broken_golang_links branch which would be more relevant to merge, but I'm not bothering with opening PR:s for either of these branches today.

Regarding finding more maintainers, maybe it could be worth making a few steps towards becoming more approachable and then let a community form? Github is and will be Github, a platform of mainly drive-by requests by randoms. As far as I understand, the only other existing channel is a chatroom is on Discord, a walled garden which will not even allow account creation unless providing a verified phone number? How about setting aside say 45 minutes regularly recurring every three months for an open community video call (on e.g. Jitsi)? My experience is that meeting verbally and visually is of great help when it comes to getting people to transition from considering into actually committing to a responsibility. Could that be worth giving a try, maybe at least as a one-shot test?

[nospam2998]

Maybe implementing #3000 would be a better approach than what was previously tried here. Parsing those lists output by ALEInfo would enable not only detecting broken linter configs, but also when new linters become available upon upgrading ale.