Fork me on GitHub
#conjure
<
2022-07-27
>
Martynas Maciulevičius07:07:31

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.

lispyclouds08:07:36

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.

Martynas Maciulevičius08:07:50

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.

lispyclouds08:07:34

yeah i use only lsp to jump regardless of the language 😄

Martynas Maciulevičius16:07:42

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.

Chase17:07:37

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

Chase17:07:06

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])

dave17:07:51

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.

Chase17:07:52

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?

Chase17:07:53

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]

nate22:07:26

I am experiencing the same issue, wonder if there's a coc.nvim caching issue

nate22:07:44

if I eval the file, it sometimes works again

nate22:07:15

yeah, the completions are only under [CLJ]

nate22:07:15

what versions of neovim are you using? I'm on v0.8.0-dev-648-gd15a66d80

nate23:07:05

it might be related to a recent update to coc.nvim, if I go back to an older version (e7d5d359) it works again

nate23:07:27

might have to do a git bisect to see what commit introduced the issue

nate23:07:48

Looks like f30087ffe9cf8c6a0b86433b836a8c074e0c5818 is the commit of coc.nvim that breaks it for me

nate23:07:48

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 +-

nate23:07:46

77e54fd82a35043440df8a6271aa5780d1757007 is the last good commit

Noah Bogart00:07:00

Nicely caught. The devs are pretty responsive so you could let them know in a github issue

👍 1
Chase00:07:16

This is the first I've heard of git bisect. Seems super useful obviously haha

Chase00:07:43

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?

nate01:07:58

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.

Noah Bogart14:07:56

don't wanna further derail the thread, but git bisect is a live saver when trying to find exactly some code broke.

Chase00:07:43

I have to keep derailing, sorry. How do I revert back to that last good commit? I'm using vim-plug.

Chase20:08:09

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)

nate21:08:49

Awesome, thanks for the heads up. What was the config you had to change for autocompletion?

Chase23:08:06

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  

nate23:08:33

ah cool, thank you for the information

Chase00:08:45

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

nate00:08:39

oh interesting

nate16:08:57

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.

🎉 1
Noah Bogart16:08:03

Yeah that one caught me off guard too.

Chase18:08:34

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