Clojurians Log v2

Does anyone using flycheck-clj-kondo want to take a look at this PR? https://github.com/borkdude/flycheck-clj-kondo/pull/10

i don't use cider, but the actual code doesn't look like it is tied to cider. does that seem right?

that's right

ok, i'll take a look then

thanks!

@borkdude ok, i've looked and tested a bit. i'd like to confirm that i understand the background of the situation. iiuc, in its current state, when one sends .cljc content to clj-kondo via stdin, using --lang clj or --lang cljs is likely to fail if there are any reader conditionals. does that sound right? so when using cider, there can be two repl connections, one to a clj repl and another to a cljs repl. i guess based on the current major-mode, which repl is used for evaluation is determined. so flycheck-clj-kondo also looks at the major mode to decide what value to use as the value for --lang. but this is a problem for .cljc content because if one is switched to either clojure-mode or clojurescript-mode, --lang will end up being passed clj or cljs, basically making it likely that clj-kondo cannot cope, getting something typically like this:

<stdin>:0:0: error: Can't parse <stdin>, Unparsable namespace form

true

ok, so i think this pr tries to cope with this.

it provides a buffer local variable that overrides things -- one can set it to "cljc".

That's right. I wondered about the use of eval, if this was legitimate there

he he -- i am not so sure either.

there is some other refactoring too which i wondered whether was necessary.

@borkdude so i tried modifying the code a bit -- pulling the command construction back out into a let like before and not using eval. you might have guessed this, but that doesn't seem to work. may be it is because the value of flycheck-clj-kondo-lint-lang is then captured at macro compile time and consequently what one sets it to later is not reflected when constructing the command line to execute. does that sound plausible?

yes.

maybe the macros can all be turned into functions?

i can investigate that

fwiw, it appears that using eval within the context of :command is a thing: https://github.com/flycheck/flycheck/issues/1515 this issue had to do with extending that to work for the first part of :command -- the one place it didn't (doesn't) work. which is not our case.

@borkdude i'm not sure i quite follow about turning macros into functions. i did find that there is a function alternative (https://github.com/flycheck/flycheck/blob/master/flycheck.el#L5681) to the macro flycheck-define-checker, but i'm not sure how using that would help here. however, as far as constructing the command is concerned, there might be an alternative to using eval. i found a list here of the kinds of things one can use when constructing an arg for the command: https://github.com/flycheck/flycheck/blob/master/flycheck.el#L5899 (eval FORM) is one of the listed options, but there are also things like: https://github.com/flycheck/flycheck/blob/master/flycheck.el#L6002-L6004

ooh option-flag might be what we want here

am looking for example usages

https://github.com/favadi/flycheck-gometalinter/blob/master/flycheck-gometalinter.el#L101-L113

https://github.com/weijiangan/flycheck-golangci-lint/blob/master/flycheck-golangci-lint.el#L79-L88

https://github.com/purcell/flycheck-ledger/blob/master/flycheck-ledger.el#L44-L53

go http://grep.app

will give it an attempt now

can we accomplish the desired behavior with that?

@borkdude hmm, i think we want to fall back to lang if there is no value defined for flycheck-clj-kondo-lint-lang. i am not sure if option-flag will be enough.

option-flag takes not a default?

it doesn't look like it to me. may be i misunderstood?

fwiw, when searching for uses of option-flag i did find that it wasn't uncommon for flycheck things to be using eval.

ok, maybe it's alright then

so we have done due diligence at least 🙂

yes, thanks for the review!

np!

Maybe a bit bikesheddy, but maybe flycheck-clj-kondo-lang is a better name than flycheck-clj-kondo-lint-lang

i did think the lint-lang version was a bit on the long side

otoh this is emacs lisp 😛

I left a comment.

it's emacs lisp, but also kondo which emphasizes cleaning up things you don't need ;)

ha ha ha -- good point