This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-07-27
Channels
- # babashka (35)
- # beginners (85)
- # cider (14)
- # clojure (115)
- # clojure-europe (15)
- # clojure-norway (2)
- # clojure-portugal (9)
- # clojure-uk (3)
- # clojurescript (28)
- # conjure (35)
- # data-science (10)
- # datomic (4)
- # graalvm (28)
- # holy-lambda (7)
- # hyperfiddle (2)
- # jobs (2)
- # joker (4)
- # malli (9)
- # meander (6)
- # nbb (6)
- # off-topic (23)
- # pathom (3)
- # remote-jobs (1)
- # shadow-cljs (158)
- # sql (15)
- # tools-deps (35)
- # vim (5)
Why is ,gd
not immediate?
In CIDER it works immediately (non-noticeable delay) and in Conjure it takes probably 200+ms (I notice that I jump to other source file or location).
Is it because LSP does something laggy or is it something else?
Example:
(def my-var :hi)
my[CURSOR]-var
If I press ,gd
then I wait something similar to 500ms until it jumps (very noticeable). And when it jumps it also repositions the buffer. So it lags even if I jump to the same buffer. It does too much work somewhere.
It's when I run Clojure REPL.i have gd
mapped to vim.lsp.buf.definition()
and for me it lags the first time as lsp is extracting the clojure/lib jar file which is a zip file in nvim. that takes few 100s of ms but subsequent jumps are quick. this repeats when i close down nvim and the zip buffer is gone. jumps within the same file/project are always quick. this is my experience when exclusively using lsp to jump.
Ah nice. I already set up LSP jumping but didn't use that for Clojure as I thought it's unstable in some way. It works really fast. Nice.
yeah i use only lsp to jump regardless of the language 😄
I found that in nvim's way of handling LSP I can jump into Java imported classes. This is something that I can't do in CIDER (the way it's set up (probably I could've used jump if I used LSP though)).
Also I found that vim has C-t
to get back to previous file. This is something that I wanted to find because previously I was trying to use C-o
and it didn't work as I wanted.
I'm having a convo with the LSP maintainer over in #lsp about this issue I've been seeing: https://clojurians.slack.com/archives/CPABC1H61/p1658879091339269
I'm curious if other conjure + coc.nvim users have the same thing. Basically I'm not getting lsp
autocompletion for certain things like
but I occasionally get spotty support for it through I think conjure or coc.nvim (the suggestions are from [CLJ] vs [LS])
I tested just now, and the behavior on my machine is the same as you've described.
In a namespace with
required :as io
, if I type io/
there is no autocompletion, but if I type
there is.
The behavior is the same both with and without a REPL running.
Worth noting that (even without a REPL running), I can type something like io/copy
and when I tab to that result in the completion list (which is the only option, since I'm not getting the autocompletion results, as I mentioned above), I do at least get the docstring and examples in the popup. So the issue seems to just be around not getting autocompletion results.
I'm trying to give him the client/server logs which is a huge json file. I'm following the directions from here: https://github.com/neoclide/coc.nvim/wiki/Debug-language-server#using-output-channel (`:CocCommand workspace.showOutput` ) and it opens up a huge file in nvim showing it at: output:///languageserver.clojure-lsp
but where do I find that file?
Yeah, if I am at (io/|
and hit TAB
I actually get the list of completion items but only under the [CLJ]
provider, whatever that is, not [LS]
. But then if already have something in that file using io like (io/reader ...)
then I don't even get that TAB
completion because it defaults back down to only reading the file itself so it suggests io/reader [A]
it might be related to a recent update to coc.nvim, if I go back to an older version (e7d5d359) it works again
Looks like f30087ffe9cf8c6a0b86433b836a8c074e0c5818
is the commit of coc.nvim that breaks it for me
commit f30087ffe9cf8c6a0b86433b836a8c074e0c5818
Author: Qiming Zhao <[email protected]>
Date: Sat Apr 2 19:14:47 2022 +0800
commit d6a665bb13044d4899e2a3529c3ca68104d9b2f5
d6a665bb refactor(completion): rework pum refresh
4e1b4ba3 feat(util): use notification window instead of echo
1f258ca9 perf(sources): not parse words on insert mode
95a5e4dc feat(documents): check buffer rename on save
39578c3b fix(bufferSync): consider text change after buffer write
f67fdb66 chore(test): fix timeout tests
autoload/coc/float.vim | 3 +
autoload/coc/util.vim | 2 +-
build/index.js | 289 ++++++++++++++++++++++++-------------------------
data/schema.json | 23 ++--
doc/coc.txt | 7 +-
history.md | 10 ++
plugin/coc.vim | 4 +-
Nicely caught. The devs are pretty responsive so you could let them know in a github issue
So it keeps reverting you to an old commit and then you try it out and see if you still have the bug? And once that happens, it guides you through a process to make sure you find the exact commit that did it?
Yeah, you start out by running git bisect start
and then mark a commit as bad by running git bisect bad
. Then mark a commit in the past as good with git bisect good [sha]
. Git will pick a commit in the middle and check that out. If you try it out and it works, run git bisect good
. If it doesn’t work, run git bisect bad
. Each time you tell it good or bad it continues to bisect the remaining commits till it finds the one that breaks. I think I ended up with 8 steps for this one.
don't wanna further derail the thread, but git bisect is a live saver when trying to find exactly some code broke.
I have to keep derailing, sorry. How do I revert back to that last good commit? I'm using vim-plug.
Just for closure, this problem seems to have fixed itself when updating to the latest version of coc.nvim
. (Also note that that update does include some frustrating breaking changes to the autocompletion workflow but it was decently easy to fix by using the changed example config on the main repo README.md. https://github.com/neoclide/coc.nvim/releases/tag/v0.0.82)
Awesome, thanks for the heads up. What was the config you had to change for autocompletion?
The TAB for autocompletion stuff. I had to take out my old stuff and put in this which I got from the repo readme:
inoremap <silent><expr> <TAB>
\ coc#pum#visible() ? coc#pum#next(1):
\ CheckBackspace() ? "\<Tab>" :
\ coc#refresh()
inoremap <expr><S-TAB> coc#pum#visible() ? coc#pum#prev(1) : "\<C-h>"
inoremap <silent><expr> <CR> coc#pum#visible() ? coc#pum#confirm()
\: "\<C-g>u\<CR>\<c-r>=coc#on_enter()\<CR>"
function! CheckBackspace() abort
let col = col('.') - 1
return !col || getline('.')[col - 1] =~# '\s'
endfunction
function! ShowDocumentation()
if CocAction('hasProvider', 'hover')
call CocActionAsync('doHover')
else
call feedkeys('K', 'in')
endif
endfunction
See discussions here: https://github.com/neoclide/coc.nvim/pull/3862 and here: https://www.reddit.com/r/vim/comments/v5bzyh/custom_popup_menu_will_be_launched_on_cocnvim/
Also encountered this unwanted behavior (in Clojure as well): https://github.com/neoclide/coc.nvim/issues/3981#issuecomment-1201987002
The fix is to put: "suggest.enablePreselect": false,
in your coc-settings.json
thanks again for this information. the setting that tripped me up is suggest.noselect
flipping from true to false by default. I set it back to true and the behavior is what I was used to before.
Yeah that one caught me off guard too.
Haha, same. I meant to come back and mention that one too when it bit me. Kind of made me think of all the convos and cultural thinking in the Clojure community about introducing breaking changes (or the avoidance thereof). But I think this is the only time this has happened with coc.nvim
for me so hopefully it was a one off because they really were going off in a different direction with their own homemade solution