This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (5)
- # babashka (23)
- # beginners (3)
- # business (6)
- # clj-kondo (40)
- # clojure (81)
- # clojure-berlin (1)
- # clojure-france (12)
- # clojure-nl (1)
- # clojure-norway (1)
- # clojurescript (4)
- # cursive (7)
- # data-science (1)
- # datascript (1)
- # emacs (9)
- # events (1)
- # fulcro (37)
- # malli (3)
- # meander (5)
- # membrane (2)
- # nrepl (1)
- # parinfer (1)
- # pathom (9)
- # re-frame (31)
- # reitit (10)
- # sci (2)
- # shadow-cljs (3)
- # sql (3)
- # tools-deps (16)
- # uncomplicate (4)
- # vrac (1)
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?
@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
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
it provides a buffer local variable that overrides things -- one can set it to "cljc".
@borkdude so i tried modifying the code a bit -- pulling the command construction back out into a
let like before and not using
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?
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
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
@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.
fwiw, when searching for uses of
option-flag i did find that it wasn't uncommon for flycheck things to be using
Maybe a bit bikesheddy, but maybe
flycheck-clj-kondo-lang is a better name than
it's emacs lisp, but also kondo which emphasizes cleaning up things you don't need ;)