Clojurians Log v2

Weird, I always get this:

LSP :: keys.cljs not in project or it is blacklisted.

I can make a repro project tomorrow, if necessary. So essentially all I do is: • Open a project, add it to LSP known projects • Save session as "blah" • Close emacs • Load session "blah" • I get asked this:

I use doom-emacs but never saw this, but yeah, it could be some race condition, I'd suggest asking for help on lsp-mode or doom discord as @yyoncho is more familiar with that than me

Thanks, I'll try those

Oh, just FYI, this only started happening recently

So maybe I'll look at recent emacs lsp commits too

Hum, yeah, good start

So, I'd like to give a try later on implementing https://cursive-ide.com/userguide/macros.html#customising-symbol-resolution on clojure-lsp 🧵

This is the only one big feature I see it's missing from non-cursive IDEs, and if we could add that, it'd improve a lot the UX. it could be really nice for other editors as well like Calva (c/c @brandon.ringe) I was discussing with @yyoncho (lsp-mode maintainer) and we could do that via code actions, like: 1. clojure-lsp detect a unresolved macro and return a code action "Resolve macro as..." 2. LS client (for now, lsp-mode), wrap that code action asking to user how it should resolve, for now we can show only the common clojure ones: def , defn , let -> etc 3. clojure-lsp receive that and somehow update user/project clj-kondo config lint-as . @borkdude I'd like you opinion/suggestion on how we can achieve the 3 step. In a ideal world, clojure-lsp could call a clj-kondo function to update the user config and clojure-lsp trigger a re-lint of that file. Or clojure-lsp could ask to clj-kondo the clj-kondo config-path and change that itself manually, WDYT?

@ericdallo That seems good to me. You can use https://github.com/borkdude/rewrite-edn or just rewrite-clj to update the clj-kondo config.

Nice, any suggestion if this logic should be on clj-kondo side or clojure-lsp? I think that on clj-kondo we could use existing functions to know what is the user clj-kondo config

clj-kondo has only a forked version of rewrite-clj currently, so it isn't able to do any code editing

is there something in the response of clj-kondo/run! that points at the config dir?

Not that I recall

I'll take a look

we can add a core function for this

in clj-kondo.core

Yeah, that would help :)

but it also depends on the :config-dir argument to clj-kondo/run! so it's call-dependent

can users configure this in lsp?

I think 99% of the time the config is in .clj-kondo/config.edn but maybe not in monorepo projects

No, only if it's available via the .clj-kondo/config.edn file

Yeah, I thought we could use the same logic clj-kondo use to find the config

The core function would just call that logic I imagine

I think what you should do is look up from the current file towards the first .clj-kondo dir and pick the config.edn from there

So, On clojure-lsp side?

I have this function in clj-kondo.impl.core:

(defn config-dir
  ([] (config-dir
       (io/file
        (System/getProperty "user.dir"))))
  ([start]
   (let [start (io/file start)
         ;; NOTE: .getParentFile doesn't work on relative files
         start (.getAbsoluteFile start)
         start (if (.isFile start)
                 (.getParentFile start)
                 start)]
     (when start
       (loop [dir start]
         (let [cfg-dir (io/file dir ".clj-kondo")]
           (if (.exists cfg-dir)
             (if (.isDirectory cfg-dir)
               cfg-dir
               (throw (Exception. (str cfg-dir " must be a directory"))))
             (when-let [parent (.getParentFile dir)]
               (recur parent)))))))))

so I think you can call that one, but we should maybe make it public

Yes, that makes sense

feel free to make a PR to make a public wrapper around it

but first you can call it from impl.core

just for testing

Sure! Thanks for the guide, I'll make that later today

@borkdude it seems that function almost always will return the project .clj-kondo since clj-kondo creates it for the .clj-kondo/.cache

maybe clojure-lsp should check if there is a config.edn file from the return of that function?

still it'd be logic to check the home dir on clojure-lsp side, it'd be better if clj-kondo return the project .clj-kondo only if there is a config.edn file there

but user may have no config.edn on ~/.clj-kondo as well :thinking_face:

@ericdallo clj-kondo never creates a .clj-kondo directory

I think it may be better to show the user a list of possible candidates

I see, presenting from the current folder until home I suppose

candidate config.edn files

like:

- /home/user/mono-repo/project-a/.clj-kondo/config.edn
- /home/user/mono-repo/.clj-kondo/config.edn
- /home/user/.clj-kondo/config.edn

yeah

well, in that example on the first and last are relevant

it seems better indeed, so we don't need to use the clj-kondo config-dir, right?

since clj-kondo doesn't reach the middle one when it encounters the top one

I think in most cases people want to use it to the project config (the top one)

since it fixes it for their teammates as well

I see, so I think we can present either the home one or the project, right?

yes

ok, so we don't need to touch clj-kondo code I think

alright

I'll check if we are missing anything, but looks good to me

@borkdude I realized that when we have a unknown macro, we don't necessarily have a lint/diagnostics on the macro, but on other places inside the macro usage that may be because of a unknown macro

The only way I see that working is clj-kondo return in the analysis if that macro is known or not

otherwise I can't see clojure-lsp suggesting correctly a Resolve macro as code action

clj-kondo does report whether a var is a macro

yes, but it reports if that macro is known? like is defined via lint-as or some common macros that are coded on clj-kondo?

for example, it should not return a unknown macro for defflow if I have it correctly configured with hooks etc

only specifying as :macro true is not enough

"known macro" is not a thing since not all macros use syntax that gives problems

yeah, I wonder how cursive handles that

where does cursive give this hint?

good question

but when you resolve it, Cursive save that config to not ask later again, so the way we handle that should consider that as well

I think cursive just shows this when you are on the macro call name: https://cursive-ide.com/userguide/macros.html

and from the analysis you can infer you are calling a macro, so maybe you could do the same

I'm not sure if cursive always suggests this or only in the presence of warnings, but this you can also check, since you know the start and end location

ok, we can suggest it if it's a macro, but how we'd know if it was already resolved as before?

by looking at the config in :lint-as maybe?

I guess that part doesn't have to be that intelligent

yeah, that would not be totally reliable as I imagine there is some common macros clj-kondo support by default?

the user can think for himself when changing this

Hum, yeah, it could be a start

yeah, but for supported macros the user would probably not reach for this

So I can always return the code action if cursor is inside a macro function

on the macro name I would say?

this is how Cursive seems to do it from the screenshot in the docs

have you got a running version of Cursive?

it'd be now warnings/lints on the macro definition, it may not be clear to user that there is a action only when hovering the macro name I think

> have you got a running version of Cursive? Nope, only saw teammates using

I do have an intellij license, for free, open source

you can request it from jetbrains, but you can even run cursive with the CE free edition

and cursive also has open source licenses

good to know, I'll setup it later so

maybe also ask some feedback from other people in the channel

I don't have strong feelings about this, as I'm likely to edit the config manually

but maybe people don't know this option exists, so it would be good to have it

I know it's something commonly used by cursive users

I got to install and repro:

so, cursive always show as a code action only when on macro name indeed

and always show the code action, even if you already chose one before, exactly as you said @borkdude 🙂

So I think we can do the same