Andy Fingerhut

Copies some comments from Slack channel to here, for reference: Often when writing linters I do not know all of the cases that the tools.analyzer.jvm analyzed data structures might contain,...

Do you have a sample Leiningen project to demonstrate this behavior? I don't recall off the top of my head what the corner cases are here.

See this Clojure ticket for some potential related issues with map destructuring, although if Clojure 1.9 catches some of them as errors via clojure.spec, there is not much reason to...

Arguably the warning should be more severe if there are characters like Unicode's non-breaking space (or other whitespace characters other than the ASCII whitespace characters), because those can lead to...

There are currently a few options for selecting the format of the output text. See the description of the :warning-format key here: https://github.com/jonase/eastwood#editor-support If you would prefer a different text...

Would adding another value for :warning-format be sufficient, e.g. {:warning-format :junit} ?

Ah, I see now. Yes, you are correct that the existing code for the :warning-format option makes it straightforward to change the format of individual warnings, one by one, but...

See ticket http://dev.clojure.org/jira/browse/CLJ-1613 for an alternate way to provent this within Clojure itself.

There are ways we could syntactically detect at least some cases when a function is used as a HOF, but it wouldn't necessarily catch all cases that occur at run...

That is better than what I was thinking of, in that it should catch everything, although with perhaps a very few false positives if there is ever code that passes...