kibit warnings not navigable by next-error?

[expez]

squiggly lines created by kibit are not navigable with flycheck-next-error, it just reports "no more errors".

[pnf]

Odd. This is specific to kibit, to flycheck-clojure, or general across flycheck? Since flycheck controls both the highlighting and the navigation of the error list, I have trouble imaging a cause that would be idiosyncratic to clojure.

On Feb 8, 2015, at 08:27, Lars Andersen notifications@github.com wrote:

squiggly lines created by kibit are not navigable with flycheck-next-error, it just reports "no more errors".

— Reply to this email directly or view it on GitHub.

[expez]

Hard to say, I can't reliably reproduce anything. squiggly-clojure doesn't work most of the time for me. I just get nothing or stuff like this:

Error from syntax checker clojure-cider-kibit: Form #[257 \300\301\302\303 !#\207 [format (do (require 'squiggly-clojure.core) (squiggly-clojure.core/check-kb '%s %s)) flycheck-sexp-to-string buffer-file-name] 6 

(fn NS)] of checker clojure-cider-kibit failed: class java

(fn NS)] of checker clojure-cider-kibit failed: class java.lang.StackOverflowError
Error from syntax checker clojure-cider-kibit: Form #[257 \300\301\302\303 !#\207 [format (do (require 'squiggly-clojure.core) (squiggly-clojure.core/check-kb '%s %s)) flycheck-sexp-to-string buffer-file-name] 6 

(fn NS)] of checker clojure-cider-kibit failed: class java.lang.StackOverflowError

[expez]

I don't use core.typed but if I also disable kibit and run flycheck-buffer nothing happens. Should that trigger eastwood?

[pnf]

There's a fairly deep stack of components here - flycheck, flycheck-clojure.el, cider, squiggly-clojure/core.clj and kibit - with squiggly-clojure encompassing the 2nd and 4th. If you want to track down the problem (and you might reasonably not) it's going to be a little involved.

First, it does sound as though kibit is failing. We should try to isolate that by running the checker directly from the repl, using the form reported in *nrepl-messages*. If there is a bug, the kibit maintainers will probably want you to further narrow it down by testing the code with their lein plugin too.

The next question is why, since the error you report is only generated when the checker 'errors, clojure-cider-kibit isn't automatically chucked into flycheck-disabled-checkers. (@lunaryorn - isn't that what's supposed to happen?) (Actually, could you verify that it's not?)

The flycheck-next-error problem is, as I noted, hard to understand. What the 3 squiggly checkers do ultimately is generate a list of flycheck-error objects. Since flycheck can apparently extract highlighting information from them, they couldn't be completely garbled, though I suppose it's possible that they're malformed in a way that confuses flycheck. It would be helpful to verify that you can navigate flycheck errors produced in some other way (e.g. from an elisp buffer - the elisp checker is sufficiently pedantic that generating more than one error should be trivial).

To your last question, I don't quite know what you mean by "trigger". By default, all three checkers are added to flycheck-checkers; you can disable one or more by adding them manually to flycheck-disabled-checkers, so flycheck will never attempt to launch them. When they run, they issue nrepl-requests, which you can observer in *nrepl-messages*, so you can tell if the eastwood checker ran. (If you disable checkers instead using namespace metadata, then flycheck still runs them, but the squiggly-clojure/core.el return an empty list. ) Even if eastwood runs, it is possible that it didn't find any problems. You can of course verify that directly too.

[expez]

This stackoverflow bug is a known issue with kibit which was reported a year ago. It's making kibit entirely unusable for me so I'm just gonna close this.