Clojurians Log v2

I have jump-to-definition on my to-do. That and eldoc are my next two, but I got kind of stuck with trying to make the analysis async so it doesn't freeze emacs first time you open a file from a project 😝 and that was a lot of work, so then I chocked and I put the whole thing on back burner haha. Thinking of getting back into it soon

Could you piggieback on the data produced during the linting run @didibus? I figure the .clj-kondo cache directory ought to have all sorts of useful data that I just don’t have an interface into.

This project looks great, by the way.

Yup, clj-kondo analysis data has everything I'd need. The row/col location of each var in each file and their name and doc is all there

And I maintain my own cache of it on a per-project basis in Emacs

Is there a way to configure it to just re-use the cache I already have? It's not a huge deal, but it'd be a bit nicer to only actually compute that data once

anakondo uses its own cache. the format in .clj-kondo/.cache is an implementation detail which is not supposed to be used by other tools since it can change (it doesn't change often, but it could happen)

That makes sense, it'd be nice if there was a canonical database of analysis data that other tools could hook into.

I think it's better if tools keep their own caches, caching is hard enough as it is

But it's likely that when you use anakondo to build up its cache, clj-kondo's cache will be populated as a side effect as well

I can also say that in practice, I've not seen any performance impact even on a 10 year old laptop that can't even run Google Chrome without crashing. The biggest issue for me right now is the initial time to analyse a project, and the fact that it blocks Emacs while doing that initial analysis. Most of the time there is taken by the Java analysis, not clj-kondo, so even then I don't think from clj-kondo's perspective its that big a problem for now.

Also, syncing Emacs with a file based cache wouldn't be that simple, probably requiring its own cache for it 😛

What I have wondered though is more, if I decide to save my own cache to a file, so on Emacs restart you don't need to re-analyse the project, if I should re-use the clj-kondo's folder, or have my own folder, or store it within Emacs's own folder, etc.

You can save it in .clj-kondo for sure

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.

My ideal would be a standardized “database” of analysis information that could be populated by tools like clj-kondo and cider and used by various editor plugins as well as by ad-hoc user queries

Of course, as someone who isn’t writing code (and doesn’t have time to) I'm grateful for the work y'all do

there is also this project: https://github.com/jpmonettas/clindex