I'm seeing different linter errors on the CLI and in Spacemacs. On the CLI I'm running clj-kondo v2019.10.04-alpha; in spacemacs, I'm running (clojure :variables clojure-enable-linters 'clj-kondo ...)

How can I verify / debug what flycheck is actually running in emacs?

you can try flycheck-compile

ah, that looks more correct! So it looks like the default runner for flycheck is incorrectly configured

if I run flycheck-select-checker and set it to clj-kondo-clj I'm seeing the correct thing; any idea what to add to my .spacemacs to make sure it loads by default for clj/cljs/cljc/edn files?

I just chose the nuclear option, and temporarily removed joker from the path. Looks like it was always selecting joker over clj-kondo, even though I removed joker from my .spacemacs

@borkdude is it a known issue where emacs is apparently eating the last character of the error message?

I haven't seen this behavior before. There is spacemacs documention for kondo here: https://github.com/borkdude/clj-kondo/blob/master/doc/editor-integration.md#spacemacs And in the #spacemacs there are several kondo users.

Thanks, I've followed the wiki instructions per the develop branch; 🤷 I guess I'll look more into it later.

The people in #spacemacs have been very helpful to these kinds of issues before.

Re this issue: https://github.com/borkdude/clj-kondo/issues/514 The motivating examples are parsing this:

{) ; => Unmatched delimiter: ) [at line 1, column 2]

[ ; => Unexpected EOF. [at line 1, column 2]

as discussed: maybe it's an idea to keep a reference to last opened delimiter. when Unmatched or Unexpected happened, we can include the row and col of that last opened delimiter (if there is one).

What should the error messages actually be in this case? For the second example, if I forget to close a ) in a function on line 5 of a 300 line file, the error is currently that there was an unexpected EOF on line 300, not that was an unclosed paren on line 5. So there error message is 295 lines away from the error.

In the first case I'd say: an extra unmatched delimiter for the opening {

In the second case: does it work to also report the last opened delimiter position?

( <-so this one foo (.....) (....)

so as soon we encounter a closing delimiter, we forget about the last opened one

but as soon as we encounter one of the above errors, we also report the last opened delimiter that wasn't closed yet