This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-03-20
Channels
- # announcements (5)
- # asami (162)
- # babashka (15)
- # beginners (1)
- # bitcoin (1)
- # calva (10)
- # chlorine-clover (3)
- # cider (1)
- # clj-kondo (4)
- # cljfx (10)
- # cljs-dev (1)
- # cljsrn (7)
- # clojure (38)
- # clojure-europe (69)
- # clojure-germany (2)
- # clojure-serbia (1)
- # clojurescript (22)
- # community-development (2)
- # conjure (1)
- # core-async (2)
- # cursive (14)
- # datahike (4)
- # fulcro (7)
- # graalvm (34)
- # helix (13)
- # honeysql (3)
- # lsp (134)
- # meander (56)
- # membrane (1)
- # off-topic (35)
- # practicalli (31)
- # releases (4)
- # rewrite-clj (5)
- # tools-deps (3)
- # vscode (6)
- # xtdb (8)
Weird, I always get this:
LSP :: keys.cljs not in project or it is blacklisted.
when I load a (doom) emacs session that my clojure project is in. Possible race condition between (doom) emacs session loading and LSP initialization?
When I open the project directly (via projectile), it's fineI 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 @U5B6G208G 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
Update on this: I found the cause: • I had treemacs sync mode on • In treemacs I had an inner folder registered as a project. Treemacs doesn't allow projects that overlap. • Removed it, now works fine
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 @U9A1RLFNV)
I was discussing with @U5B6G208G (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
.
@U04V15CAJ 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?
@UKFSJSM38 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
but it also depends on the :config-dir
argument to clj-kondo/run!
so it's call-dependent
I think 99% of the time the config is in .clj-kondo/config.edn
but maybe not in monorepo projects
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
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)))))))))
@U04V15CAJ 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
@UKFSJSM38 clj-kondo never creates a .clj-kondo directory
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
@U04V15CAJ 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
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
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?
yeah, that would not be totally reliable as I imagine there is some common macros clj-kondo support by default?
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
you can request it from jetbrains, but you can even run cursive with the CE free edition
I don't have strong feelings about this, as I'm likely to edit the config manually
and always show the code action, even if you already chose one before, exactly as you said @U04V15CAJ 🙂
and I would probably remove ->
since I have almost never encountered this in lint-as
> So how did it end with the incremental diffing? reverted it? I still need to find the out-of-sync corner case issue, it's behind a feature-flag
yes, it could help indeed, I think we could improve the integration tests to be able to do that
Btw, I will probably make a new clj-kondo release tonight with a bunch of bug fixes in it
good to know! I'll include in this feature release if don't find any issues with that bump 🤞
Nice, I'm finishing the resolve macro as, then I'll bump clj-kondo, if everything goes fine, I'll release it later tonight
I love this bot 🙂 https://github.com/clojure-lsp/clojure-lsp/pull/375