Clojurians Log v2

@ericdallo I've raised: https://github.com/clojure-lsp/clojure-lsp/issues/396 Weird if I'm the only one experiencing this lol Thanks

so I think there's a pretty big issue with caching we need to solve - imo an important constraint to uphold is that when the server starts, its state should reflect the state of the filesytem. pre-kondo we used checksums to see if dependencies changed and only cached those; project sources were never cached. With kondo we are now also caching project sources. The problem is most prevalent when I git pull in the morning and start up vim. New functions and namespaces are reported as unresolved and the analysis is missing. So I think we either have to rm files from the kondo cache on startup, or ideally if kondo can be given a flag to ignore the cache for any files being analyzed.

thoughts @ericdallo @borkdude?

Hum, I understand the issue but I don't recall having this issue, did you mean new functions and namespaces are reported as unused or unresolved? I'm not sure I have this issue

here's an example

$ cat src/a.clj src/b.clj
(ns a (:require b)) (b/foo) (b/bar)
(ns b) (defn foo [] 1)

echo " (defn bar [] 2)" >> src/b.clj

I see now, it makes sense indeed

but wait, https://github.com/clojure-lsp/clojure-lsp/blob/master/src/clojure_lsp/crawler.clj#L218 will always be called and should lint project everytime, right?

I think in kondo caching always wins but I think it would be nice to say if i lint a.clj and b.clj - that the cache will not be used by the files

right but the kondo cache, afaict won't pick up that b.clj changed as it lints a.clj

so what we need is on that analyze-paths accept a use-cache? that will not use the :cache flag on clj-kondo

no, cause the cache for deps still needs to be used

Because ATM https://github.com/clojure-lsp/clojure-lsp/blob/master/src/clojure_lsp/config.clj#L25

yes, I meant, only on that line call, because we call the analyze-paths on both classpath analysis and project source-paths analysis

this way we could use the cache for deps/classpath analysis and don't use the cache on the next call, the source-paths analysis

You can say :cache false but I don't understand why you would not use the cache, as clj-kondo won't learn about new arities etc for the linted functions?

Oh, I thought the :cache false would just don't use some cached previous analysis, I didn't know would affect the analysis features

right, we want definitely want it to learn.

I see, so whenever some sources have changed outside of clj-kondo's visibility, you effectively want to re-lint the entire project

or at least all of your own sources probably

as libraries don't tend to change

yes, unless a change on deps.edn/project.clj deps

right, and we can checksum and reset if those do

ok, I think clj-kondo supports all you need right now, but if not, feel free to post an issue

on the a/b example above, what args would you pass kondo if you relint the two files?

if you re-lint both files, no special args are needed - why do you think this is the case?

So we are already linting project source-paths on every startup, but still this is not working, is that right @snoe?

yeah, I'm not sure if it's on the kondo side or ours tho - having trouble taking the time to figure it out

if you re-lint sources, clj-kondo should have a consistent view of interactions between those files. no special options needed

you could maybe log which files are linted or something, to find out what happens

Hey team, does someone have a config a nvim or some such config I could look at, for commands like “add missing require/import”? (I know https://github.com/snoe/dotfiles/blob/master/home/.vimrc, but I don’t think the “add-missing-require” call is there) Will play with it soon, but if there are more files I could look at for inspiration would appreciate it!

c/c @dharrigan @rafaeldelboni

<https://github.com/dharrigan/vimconfig>

Maybe we should link your config https://clojure-lsp.github.io/clojure-lsp/clients/#vim @dharrigan if you agree 🙂

Sure, as an example of course 😉

ah! looks like add-missing-libspec is what I wanted. Thanks team

@stopachka I suggest you always use the code actions as if there is a available way to import the ns, it will be there

Check add-missing-require https://clojure-lsp.github.io/clojure-lsp/features/#code-actions

Thanks Eric. Apologies for the noobie question here, but am not quite sure I understand the codeaction bit. Would you mind expanding a bit deeper?

(in dharrigan’s vimrc, I see:

call CocRequest('clojure-lsp', 'workspace/executeCommand', {'command': 'add-missing-libspec', 'arguments': [Expand('%:p'), line('.') - 1, col('.') - 1]})

Okay, one more noob question. Looks like add-missing-libspec command can auto-import namespaces. It seems to fail with java classes though. (i.e if I hover over FlexmarkHtmlConverter, and run add-missing-libspec, would love it do: (:import (com.vladsch.flexmark.html2md.converter FlexmarkHtmlConverter)) ) Is something like this supported with clojure-lsp yet? If yes, what’s the way to trigger it?

Ah, I think I understand. code-actions are the commands listed here (https://clojure-lsp.github.io/clojure-lsp/features/#code-actions) — and I guess coc may already have mappings to them. Will check coc to see how to invoke the correct code action to add missing require.

yes, the server return the available code actions, and you, user, select what you want to execute

if that function could be required/imported, then the server will return a code action for that on that line 🙂

I have some keymaps for code-actions if you need a second source for your vim config https://github.com/rafaeldelboni/dotfiles/blob/master/config/nvim/init.vim#L206

ATM clojure-lsp don't know too much about java, it doesn't know about the available java on classpath, but you can manually import it with add-import-to-namespace

oo I see!

Okay, one more noob question: Say I have

nnoremap <silent> crml :call CocRequest('clojure-lsp', 'workspace/executeCommand', {'command': 'move-to-let', 'arguments': [Expand('%:p'), line('.') - 1, col('.') - 1, input('Binding name: ')]})<CR>

:call CocActionAsync('codeAction',          'move-to-let')

if the move to let action show on code actions, it should work for the current buffer cursor

oh, not sure clojure-lsp suggest the move to let as a code action

if not, only calling manually indeed

(indeed, it does not seem to show) Okay, I think I understand this much better. Thanks team!

I think that's the only one missing on code actions :thinking_face: we could add that

Cool! May have mistunderstood a bit more. What about something like “extract-function”? If I hover over a form, and run coc-codeaction, I still only see these suggestions:

yeah, that one too 😂

xD — indeed could be nice add! if you like can make an issue on GH. I don’t know when I’ll have time, but could add to my someday to write a pr. Great work on lsp team — my vim setup has become object of envy from friends — it’s so darn cool now.

glad to hear 😄 Yeah, feel free to open an issue or PR 🙂

done!

Okay, one final noob q for the day:

whenever I run code-action, it seems like I only get these 4 results. For example, in this one I expected to find thread-first or something like this

are you with the cursor inside the ( ?

was outside. Interestingly, inside ( does not show any codeactions.

howeever, if I visually select the form, it shows up!

yeah, that depends on how vim sens that buffer position, on emacs it works on both

@stopachka visual select is also where the "move to let" is hiding. You just need to select something inside of a let-block

ah, awesome @clojurians-slack100! Thanks

@ericdallo I opened https://github.com/Yomguithereal/clj-fuzzy/issues/49for clj-fuzzy. It doesn't feel appropriate to put this algorithm into clj-fuzzy. So, I'm thinking I just publish a separate lib (like https://github.com/lewang/flx, so maybe call it clj-flx or something). Then I'll make a PR to clojure-lsp so that {:workspace-symbol-filter :flx} uses the lib?

Oh, seems good 🙂

If the algo is better than the current one, I think we could just replace the clj-fuzzy with that new one

Right, ok. I'll write extensive unit tests to show how intuitive (or otherwise) it is