sweeet will definitely do so π
still thinking about an idea how macro writers can expose this kind of config in their libs so it can be detected by clj-kondo using some classpath scanning logic
maybe that should be left out of scope for the initial release of this
how do i install the version of clj-kondo that has this capability, @borkdude?
@robert-stuttaford I can provide you a link to a binary or you can check out the source + branch and run it with clojure -A:clj-kondo --lint ...
ok great i'll try the source thing first
shot!
@robert-stuttaford The branch is macros-sci
which branch is it π
zing!
hmm i think i may need to try the binary, @borkdude
why's that?
so that i can test it the way i use it, in emacs, for the whole project, to eliminate unrelated issues due to testing it this way
is that straightforward to do?
i should be able to put that config into .clj-kondo/config.edn right?
makes sense. you can also try to build it. it's relatively straightforward if you download GraalVM, but I can also save you the trouble by providing new links every time you want to try new commits
if there's a how-to i can follow, i'm happy to try do that myself π
yes. the code goes to :macroexpand {macrons/macroname "(fn ....)"
but the string can also contain the path of a file that's in the .clj-kondo dir.
@robert-stuttaford https://github.com/borkdude/clj-kondo/blob/master/doc/build.md
Let me update it with the latest used GraalVM version. It should be java8-19.3.1
great thanks - i'll probably only get to this over the weekend!
updated
thank you π
We have a namespace with two vars like this:
(defn- identity->Identity
...
(defn- Identity->identity
This causes problems with AOT and calling compile
as far as I can tell, since the class files generated have the same names. This might be a nice lint warning for Kondo.ok, issue welcome
That seems like a clojure bug
@marc-omorain https://cemerick.com/2010/08/19/case-insensitive-filesystems-vs-aot-compiled-clojure/ looks like you need to have a case sensitive filesystem. This won't affect a lot of people.
It's an operating system issue somewhat.
Donβt macOS and Windows have case-insensitive filesystems by default? My mac certainly does.
$ touch foo; touch Foo; ls | grep -i foo
foo
My work macos has APFS (Encrypted)
, even tho there should be an option for APFS (Case-sensitive, Encrypted)
. So looks like they are by default case-insensitive https://support.apple.com/en-gb/guide/disk-utility/dsku19ed921c/mac
Any users that experienced a problem in VScode / Calva + clj-kondo's config when opening files from other projects external to the main project directory, this should now be resolved in extension version 2020.5.90
.
Hi everyone,
I'm trying to integrate clj-kondo
into Spacemacs,
In the docs there are two sets of instructions for develop
and master
branch
(but there is no such branch anymore). Which is the default way now to integrate it into spacemacs ?
probably asking in the #spacemacs channel is the best, since there's the most people using it
although there might also be some of them here
Thanks
hmm ... do you mean that by branch in that section of docs they mean spacemac's clojure layer's branch not clj-kondo's?
spacemacs runs clj-kondo as a binary, so there is not a branch of clj-kondo that's applicable to that config
I don't remember the docs, I didn't write those
@ho0man I strongly recommend using Spacemacs develop
branch, it has all the fixes and enhancements over the last couple of years. If you look at the Spacemacs home buffer, SPC b h
it will show you which Spacemacs version you are on. If you are on 0.200, its master and 0.300 it is develop.
If you want to switch over to develop, here are my recommended steps https://practicalli.github.io/spacemacs/install-spacemacs/switch-to-develop.html
Thanks a lot @jr0cket
Thanks @borkdude
@borkdude in macros-sci
does the analyzer get insight into the macro forms? i.e would it be able to determine the position of the declaration of x
is? (mydef x 1) x
=> {:col 8}
?
@snoe yes, it's metadata on the symbol
@snoe how it works: the rewrite-clj nodes are converted into sexprs, location metadata gets stored onto the sexprs. so for lists, symbols, that works. for numbers, it doesn't.
and then you generate a new sexpr and fix the metadata accordingly. e.g. when you return a new list, you use with-meta to put the original location on that