Error on notification jumpDefinition

[bukephalos]

As mentioned in another issue (#19) the "go to definition" command doesn't work. As suggested I did some logging
and (hopefully) attached the log file:
coc-perl.log

Funny, it says the language server doesn't support it, though it certainly should (and the server installation worked without error)

[bukephalos]

Also pasted the contents to https://l.perl.bot/

[bmeneg]

Also pasted the contents to https://l.perl.bot/

You pasted the direct link to the perlbot instead of your pasted content :P Can you try it again?
The coc-perl.log file worked and I can see that coc-perl was launched just fine, but something might have broke during server runtime, thus reporting the "jumpDefinition" error. The other log will give more insights.

[bukephalos]

Sorry I don't understand. I pasted the exact same contents into the text field that is also in the attachment.
I did not paste just a link but the text you already got. This is why I also don't understand why you need it twice.

I think I did exactly what you told me

• open coc-perl.log in vim
• copy the contents to the clipboard
• open https://l.perl.bot/ in browser
• past the clipboard into the text field
• click submit

As I said it is the same log contents you got in the coc-perl.log. Sorry again but what else can I do? I do not have other contents than that in coc-perl.log but I really didn't paste just a link.
I am really puzzeled, sorry.

Also: the perl bot seems to expect perl code. But the log file contens is just plain text, no code ?!? Or should I paste my test script? But how can the perl bot connect to my language server?

[bukephalos]

I think I know now what contents you mean. I pasted it into the text field within the perl bot but it is still complaining after the commit about missing semicolons which is understandable because it is log contents, not perl code.
Since I obviously do not know what really happens on perl bot, what if I just send you the log file as an email attachment?

[bukephalos]

Perhaps this one helps: https://l.perl.bot/p/leamif ?

What I noticed while fighting with the config and the log: After I added the two line to the config (log file and level) the language server doesn't give any visual sign of its existance. No error message, no marking of syntax errors. Only CocInfo shows that it is running. After I removed the logging from the config everything is back to "normal" (still no working gd but with a message again).
I hope, the log still has everything you need.

[bmeneg]

Perhaps this one helps: https://l.perl.bot/p/leamif ?

Yes!! This data! :-D @bukephalos, I should've explained better, sorry. It's indeed the content I was expecting :)
Also, to avoid the Perl errors in the perl bot you can just change the "language" drop-down menu to plaintext.

However, I was expecting errors, but things seems fine.
Can you try once again to generate a new log?

1. close all Perl files open in vim/neovim
2. erase the log file
3. open the test file
4. move the cursor on top of dosomething() call and press gd (it should fail as you mentioned).
5. copy log file contents to perl bot and give me the link :)

Something similar to the following:

LS: end aio read cnt=192, buffer len = 192
LS: line=<Content-Length: 169>
LS: line=<>
LS: read data={"jsonrpc":"2.0","id":1,"method":"textDocument/definition","params":{"textDocument":{"uri":"file:///home/bmeneg/test/perl/test.pl"},"position":{"line":8,"character":2}}}
LS: read header={ "Content-Length" => 169 }
LS: ---> Request: {
   "id" : 1,
   "params" : {
      "textDocument" : {
         "uri" : "file:///home/bmeneg/test/perl/test.pl"
      },
      "position" : {
         "character" : 2,
         "line" : 8
      }
   },
   "method" : "textDocument/definition",
   "jsonrpc" : "2.0"
}

LS: handle_req id=1
LS: method=_rpcreq_definition
LS: line 8: <dosomething();>
LS: word: <dosomething> pos: 11 len: 11
LS: ok
LS: start aio read, buffer len = 0
LS: start aio read, buffer len = 0
LS: <--- Response: {
   "result" : [
      {
         "range" : {
            "end" : {
               "line" : 10,
               "character" : 0
            },
            "start" : {
               "character" : 0,
               "line" : 10
            }
         },
         "uri" : "file:///home/bmeneg/test/perl/test.pl"
      }
   ],
   "id" : 1,
   "jsonrpc" : "2.0"
}

LS: done handle_req id=1

However, since your setup is misbehaving something else might appear.

[bukephalos]

Here it is: https://l.perl.bot/p/6pmhha
But as I said, the it looks different with logging enabled. "gd" doesn't work but I do not see error message I get when logging is off.

[bukephalos]

Another try: https://l.perl.bot/p/lkhnqo
This time I made sure :CocOpenLog shows the error ("definition provider not found for current buffer")

I did a text search on "dosomething" -- it was not found in the log. Since I also do not see the error message ("definition not found") when pressing "gd" with logging enabled: is it possible that the whole call is ignored for whatever reason when logging is enabled???

I will give it another try on a different machine (the tests very done on an up to date Linux Mint) but I also have some Ubuntu 22.04 server VMs around.

Update: Tried it. Almost the same result. Only difference I could see is that even without logging the "definition not found" message is not shown on the Ubuntu server.
But I get another status line error now when pressing "gd":
[coc.nvim]: Error on notification "jumpDefinition": definition provider not found for current buffer, your language server doesn't support it.

[bmeneg]

Things are really odd.

is it possible that the whole call is ignored for whatever reason when logging is enabled???

No, the logging has no effect on the results of an operation.

[coc.nvim]: Error on notification "jumpDefinition": definition provider not found for current buffer, your language server doesn't support it.

This error happens when the language server underneath isn't running for some reason (or if the server doesn't support the operation, which isn't true in our case).

But ok, lets try something else:

1. Can you confirm the coc.nvim version you are using (:CocInfo)?
2. Can you confirm the Perl::LanguageServer version you have installed (cpan -D Perl::LanguageServer)?
3. Can you paste here, or send a new file of :CocOpenLog you tested in the other machine (VM) where you had the same issue?

EDIT: I'm asking these new information because I just noticed that in your first comment (in this issue) the command executing the server after the extension initialization had a typo, which would cause the server to initialize, but not keep running as expected by the client (coc.nvim), matching with the content you pasted in all your tests:

1. coc.nvim send an initialization request
2. perl server responds just fine
3. perl server closes
4. coc.nvim loses connection with the server and report ... definition provider not found for current buffer ....

The typo I saw was Perl::LanguageServer::ru n, there is a space in the run function call passed to Perl interpreter with -e options directly in coc-perl code. The full and correct calling to the server is as follows (considering your variables from previous :CocLogOpen):

perl -MPerl::LanguageServer -e Perl::LanguageServer::run -- --log-level 2 --log-file /tmp/coc-perl.log --version 2.4.0 --port 13603

But in case run is being called ru n instead, the perl language server will in fact start, initialize, but will not reach run as expected and passed by coc-perl extension. If that's really the case, also happening in other systems of yours, the question then should be: "how this typo appeared?"

[bukephalos]

Things are really odd.

Indeed. Thanks for your patience!

I also noticed what you identitied as a typo but attributed it to a cut and paste issue. After all the syntax check works and it also has to call run, doesn't it?

Also I doubt that it really is a coc-nvim/coc-perl issue since I got the same problem in VScode. This is why I tried (on the Ubuntu VM) to downgrade Perl::LanguageServer to 2.4.0 but with the same result.

[bmeneg]

After all the syntax check works and it also has to call run, doesn't it?

🤦 Yeap, you're right.

I would even ask if you don't have anything in your @INC path that could interfere, so coc-perl could be calling a different version of language server. But you tested in another machine, so it should not have the same issue.

... let me think ...

[bukephalos]

But ok, lets try something else:

1. Can you confirm the coc.nvim version you are using (`:CocInfo`)?

coc.nvim version: 0.0.82-b7375d5f 2023-01-30

2. Can you confirm the Perl::LanguageServer version you have installed (`cpan -D Perl::LanguageServer`)?

G/GR/GRICHTER/Perl-LanguageServer-2.5.0.tar.gz (with the first commit of your fix applied by hand)

3. Can you paste here, or send a new file of `:CocOpenLog` you tested in the other machine (VM) where you had the same issue?

This VM I downgraded to 2.4.0 (s. --version). The run looks fine:

2023-07-11T17:23:55.324 INFO (pid:257999) [extension:coc-perl] - extension "perl" is now active
  2023-07-11T17:23:55.324 INFO (pid:257999) [extension:coc-perl] - try if port 13603 is available
  2023-07-11T17:23:55.329 INFO (pid:257999) [plugin] - coc.nvim initialized with node: v18.16.1 after ^[[33m223^[[39m
  2023-07-11T17:23:55.330 INFO (pid:257999) [extension:coc-perl] - use 13603 as debug adapter port
  2023-07-11T17:23:55.330 INFO (pid:257999) [extension:coc-perl] - cmd: perl args: -MPerl::LanguageServer -e Perl::LanguageServer::run -- --log-level 2 --log-file /tmp/coc-perl.log --version   2.4.0 --port 13603
  2023-07-11T17:23:55.395 INFO (pid:257999) [language-client-index] - Language server "perl" started with 258012
  2023-07-11T17:24:01.536 INFO (pid:257999) [attach] - receive notification: highlight []
  2023-07-11T17:24:04.204 INFO (pid:257999) [attach] - receive notification: jumpDefinition []
  2023-07-11T17:24:04.210 ERROR (pid:257999) [attach] - Error on notification jumpDefinition Error: definition provider not found for current buffer, your language server doesn't support it.
      at Rb.checkProvider ^[[90m(/home/ansible/^[[39m.vim/pack/coc/start/coc.nvim/build/index.js:281:34291^[[90m)^[[39m
      at gb.request ^[[90m(/home/ansible/^[[39m.vim/pack/coc/start/coc.nvim/build/index.js:269:5370^[[90m)^[[39m
  ^[[90m    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)^[[39m
      at async gb.gotoDefinition ^[[90m(/home/ansible/^[[39m.vim/pack/coc/start/coc.nvim/build/index.js:269:6781^[[90m)^[[39m
      at async _b.cocAction ^[[90m(/home/ansible/^[[39m.vim/pack/coc/start/coc.nvim/build/index.js:281:46242^[[90m)^[[39m
      at async EventEmitter.<anonymous> ^[[90m(/home/ansible/^[[39m.vim/pack/coc/start/coc.nvim/build/index.js:281:47836^[[90m)^[[39m
  2023-07-11T17:24:04.508 INFO (pid:257999) [attach] - receive notification: highlight []
  2023-07-11T17:24:13.337 INFO (pid:257999) [attach] - receive notification: openLog []

[bmeneg]

@bukephalos are you trying to open a file in the same directory you're cded? For instance:

$ cd test/perl/
$ nvim test.pl

or are you trying to open the file somewhere else? Like:

$ pwd
/home/bmeneg/
$ nvim test/perl/test.pl

I was able to "partially" reproduce the error you're seeing, when editing a file outside the workdir I'm currently in.