Clojurians Log v2

I think the reasoning for keeping it all in a single entry is because the interpretation of a keyword as a def is up to userspace.

> And the editor needs to support listing multiple choices when you do `go to definition`. I can do that in Anakondo easily, not sure if LSP supports this? The protocol seems to allow for multiple definition results it will depend on the clients, as always, to support it.

> I think the reasoning for keeping it all in a single entry is because the interpretation of a keyword as a def is up to userspace. Ok, but I mean we're talking in either case, userspace needs to configure clj-kondo for it no? But, ya ok, I see the point, like it might look weird for the map to be empty most of the time, unless userspace configured some keyword defs

I guess from a consumer perspective, it seems like you'd have a different way to parse symbols from keywords for "go to def" and "find references". Which is why I was wondering like if that made sense.

@didibus the idea is that a keyword in and of itself doesn't mean anything. e.g.:

(defn foo [x])
(foo :bar)

;; vs

(defn reg-something [k])
(reg-something :bar)

(def x 1)

This is something that isn't fully clear to me yet, that's why I propose keeping this analysis output private until it's been used by LSP for a while

we could make them separate, but having a list of all occurring keywords seems useful to have anyway for renaming purposes

I feel like either or, we're still adding the concept of keywords can be considered as having a definition no? Even though by default they don't in Clojure, but then per-library or user usage they might. I feel for me its more what's easiest to parse in the analysis structure for the common use. I guess its a small detail, either or you can parse out the information. But say someone runs: "go to definition" on a keyword, now you'd filter through the keyword usage for that keyword for the one with "def = true".

Where as if it was a separate map, you'd look it up in keyword-usage map

Actually, sorry, maybe that's more a general critique. I remember now. When I implemented anakondo, I think I wished that things were pivoted, instead of vector of maps, it be maps of vectors of maps

Where the map is keyed on the name

I found needed to actually parse everything back into maps indexed on names for the different constructs.

Anyways, might have missed the boat on that now.

I'll be happy either way, if :def is on the keyword map or in a separate one.

> I feel for me its more what's easiest to parse in the analysis structure for the common use. That's a good point

@didibus the reason you get everything as a list is that it's not always clear what the index should be. either clj-kondo does this for you (and has to guess what is the right format), or you do it yourself. if clj-kondo would do this for you and you wanted a different index, then it would be hairy to go from one index to another. the work has to happen somewhere and it's most flexible if that somewhere is the end user

people might also want to index on filename, for example, or namespace and then name, etc

Ya, that's true. Actually I can't remember fully, but I probably did end up indexing in a slightly more custom to my needs way.

I think had it been in Clojure, I wouldn't have feel the pain 😛, but transforming datastructures in Emacs Lisp is not as simple haha

write a graalvm binary ;)

I think now you could do this part using babashka

using clj-kondo as a pod

Ya, I've been considering it. The thing is, with any separate process option, now I need to figure out a protocol to communicate between the editor and that, and the editor needs to manage a long running process, maybe multiple if you have multiple project, etc. And I think there's a lot of brittleness there, and also I'm just re-inventing LSP at this point.

we could even let clj-kondo take some processing function that is executed using sci, since it already has sci

Hum... like pass it a post-processor on the analysis map, that could be nice.

yeah

So you could use Clojure to re-structure it however is best for your use case, and then your editor gets a JSON in that new structure.

right

I think the function could be applied to the :findings as well, just one function that gets the end result before it's written to EDN or JSON

Ok, well, it would be cool. I don't know if I'd say its at the top of the Wishlist though 😛 Even though I'm here complaining about how painful it is to do in Emacs Lisp, that's pain I chose for myself haha

I think we have to rewrite emacs to clojure one day ;P

The only thing I can give props to Emacs Lisp, its use of memory is quite impressive, like its very memory efficient

in clojure-lsp, we probably have 4 or 5 things to index on, so I just flatten everything into a singular list and search. if perf becomes. a problem we can reify the indexes we need.

Even for auto-complete?