You can save it in .clj-kondo for sure
Clj-kondo v2020.10.10 ✨ New: shadowed var linter and various improvements and fixes Release notes: https://github.com/borkdude/clj-kondo/blob/master/CHANGELOG.md#v20201010 This release is funded by Clojurists Together.
5Hi Maybe this is an existing feature but I cannot find information about it. Would it be possible to annotate a macro, using metadata, with lint-as rule so that I can have out-of-box linting support? And if not is there a technical limitation or would it be a bad practice to do this? Thanks for all great work.
@luis559 Hi. This is not supported, since that would rely on clj-kondo linting the source of your macro in the right order, or at all and clj-kondo is not designed in such a way: it's designed to deal with incomplete information. A better way is to PR your config here: https://github.com/clj-kondo/config and then install the config using that lib.
I'm still considering something like picking up config from the classpath, but it's not yet clear
I think the config library could also be made to handle that
So then users could provide a clj-kondo.config/your.org/your.lib/config.edn directory on the classpath
and this will then be copied, or something like that
The issue for that is this one: https://github.com/clj-kondo/config/issues/1
The classpath option sounds promising as well. Thanks for explanation. Looking forward to see how it evolves. Thanks.
I guess I was thinking more in terms of a database with an API that tools can be written against. I'd like to be able to query for code construvts with datalog or SQL, for example.
Anyways, my grand vision for programming is more smalltalk-image shaped and less file shaped
totally possible to make a tool which puts clj-kondo's data into a SQL db: https://github.com/borkdude/babashka/blob/master/examples/hsqldb_unused_vars.clj
The downsides of that is for an Emacs editing environment you now have to manage long lived subprocesses and that comes with its own issues.
@didibus babashka + hsqldb is pretty fast, and not long lived, milliseconds
I haven't tested the feasibility of this, but you can try out the example in your own machine to see how it performs
Hum... like if I didn't maintain a cache? It means clj-kondo would need to re-analyse all files every edit and re-initialize hsqldb and insert all vars and then run the query.
I don't know maybe clj-kondo and hsqldb are that fast
this is just an example of how to use hsqldb. I mean: you could maintain your own cache in a hsqldb
I'm not sure either
Right, that's what I meant by long lived process
no, it's persisted to disk?
If I maintain my cache in a DB, that's a seperate process that Emacs as to start and manage
Oh, is it?
So you start hsql run some query over a a file based table and then kill it?
yeah. you can use it with babashka to create ad hoc databases on your file system, just like sqlite
sqlite is also an option btw, if emacs has support for that somehow
Ok, that's interesting then, I'll think about it. Could make my code easier, querying data-structures in Emacs is alright but that would make it much nicer
so, the support for hsqldb from within babashka comes from here: https://github.com/babashka/babashka-sql-pods/
There's the downside of having users need to install one more binary, but I guess they are already expected to install clj-kondo
That's for sure. Of course you could also make your own anakondo binary with GraalVM and use clj-kondo from there.
and include whatever database / EDN / EQL stuff you want
Postgres and HSQLDB (embedded) are the only databases I've gotten to work with GraalVM
Hum, ya that could be an option as well. I'll hammock on it all. Though at this point I wouldn't really see myself making a major refactor of that sort unless it really helped me down the road. But I like the ideas.