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.

[bukephalos]

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.

Still possible since I have quite a software stack I install on most of my systems. Could be the same trouble maker on both. I once had a really long debugging session where the problem only appeared with a specific version of the "Want" module that was somewhere deep within the dependency chain.

I still have a laptop I can try and perhaps set up a totally clean VM (will take some time)

[bukephalos]

@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.

I am using plain vim not nvim and doing the first case (first cd then open without a path:

cd
vim test.pl

And as I said, it also happens in VScode but there only with my test script, it works within the Perl::LanguageServer source code

[bmeneg]

I still have a laptop I can try and perhaps set up a totally clean VM (will take some time)

No need, I might have an idea on what's happening.

it works within the Perl::LanguageServer source code

Does it?! And in your test code it isn't? hahaha.. ok.. I'll check something, might take some time though.

[bukephalos]

it works within the Perl::LanguageServer source code

Does it?! And in your test code it isn't? hahaha.. ok.. I'll check something, might take some time though.

That's why my first suspition was that I had a misunderstanding on my side, like that it only works with methods or such.

I'll wait for your findings with lots of hope... :-)))

[bmeneg]

@bukephalos, hi again.

If you move your test.pl to any other folder other than your home dir, something like cd && mkdir test/ && mv test.pl test/, then run vim test/test.pl or cd test/ && vim test.pl, does the gd work?

[bukephalos]

We are getting closer :-)

with "cd test/ && vim test.pl" gd does indeed work!
"vim test/test.pl" still does not work.

gd on a variable still doesn't work in neither variant. Is it supposed to work, too? In the meantime I also did a few tests with PerlNavigator and there it also works with variables.

[bmeneg]

Ok, so I might have found the culprit, but not sure how to solve yet. The issue is on the server.
And with variables: it should work. At least I was able to get it working when cd test/ && vim test.pl 😞

[bukephalos]

Here my test script, opened with "cd test && vim test.pl":

#!/usr/bin/perl
 
 use strict;
 use warnings;
  
 my $somevar = 112;
  
 dosomething();
  
 sub dosomething {
     print $somevar;    
 }

Then move the cursor on the "s" of "print $somevar;" press "gd" => "definition not found"
gd on "dosomething();" now moves the cursor to the "s" of "sub dosomething".

[bmeneg]

It just works here, lol.
But wait, lets debug one thing at a time.
First, I'll keep diving into server code to figure out the issue we're seeing when gd'ing from home dir.
Then, we check what's going on with your variable definition goto's.

[bukephalos]

Addition: just tested with VScode: even after cd test gd doesn't work for subs (the exact test that works with vim).

To make things even more weird (new test):

mkdir /tmp/foobar
cp test.pl /tmp/foobar
cd /tmp/foobar
code .
# also works:

=> both(!) gd variants work (sub and var)
In this variant it also works with vim (both gd)

????????

[bmeneg]

Where's the "table flip" emoticon/gif when I need it? lol!

So, just to give you a perspective on what I've found on the server: richterger/Perl-LanguageServer/issues/186
That's not the culprit of our issue here, which seems related to passing workspaceFolders = null during initialization and thus not parsing any file (not even the one we're editing), but when following the parsing code I found the issue I linked above. Funny things are happening on the server.

[bukephalos]

Do you think there is a chance for a fix or is the only solution to keep the workspace out of the home dir?

[bmeneg]

@bukephalos I'm really sorry, this week things got a bit crazy around here and had no time to check the fix for this situation. For now, I suggest keeping the workspace out of home dir. But I'll do my best to get a fix for it until/during weekend.

[bmeneg]

@bukephalos, even though I didn't get to the bottom of this issue, coc-perl now officially support PerlNavigator :-)
Feel free to use it via coc-perl while we don't make Perl::LanguageServer to work correctly.