bug#62694: 30.0.50; eglot-tests fails with recent pylsp

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi,

> A version test doesn't have to mean literally testing the version.  It
> can be a different test, specifically for the problematic behavior.
> If we understand the problematic behavior, we can test for it.  (If we
> don't understand the problem, how do we know it is in the server and
> not in Eglot or elsewhere in Emacs?)

I have done the homework (not mine!) and compared passing and failing
eglot-tests. For that I have compared the failing tests from Emba, and
the passing tests on my laptop, running Fedora 37. I have compared test
case eglot-test-basic-completions.

The initialization handshake is identical, except the server info. On
Emba, the server reports

--8<---------------cut here---------------start------------->8---
[server-reply] (id:1) Fri Apr  7 01:05:39 2023:
(:jsonrpc "2.0" :id 1 :result
          (:capabilities
           (:codeActionProvider t :codeLensProvider
                                (:resolveProvider :json-false)
                                :completionProvider
                                (:resolveProvider t :triggerCharacters
                                                  ["."])
                                :documentFormattingProvider t 
:documentHighlightProvider t :documentRangeFormattingProvider t 
:documentSymbolProvider t :definitionProvider t :executeCommandProvider
                                (:commands
                                 [])
                                :hoverProvider t :referencesProvider t 
:renameProvider t :foldingRangeProvider t :signatureHelpProvider
                                (:triggerCharacters
                                 ["(" "," "="])
                                :textDocumentSync
                                (:change 2 :save
                                         (:includeText t)
                                         :openClose t)
                                :workspace
                                (:workspaceFolders
                                 (:supported t :changeNotifications t))
                                :experimental nil)
           :serverInfo
           (:name "pylsp" :version "1.7.1")))
--8<---------------cut here---------------end--------------->8---

On my laptop, there is an older server version:

--8<---------------cut here---------------start------------->8---
[server-reply] (id:1) Fri Apr  7 13:30:45 2023:
(:jsonrpc "2.0" :id 1 :result
          (:capabilities
           (:codeActionProvider t :codeLensProvider
                                (:resolveProvider :json-false)
                                :completionProvider
                                (:resolveProvider t :triggerCharacters
                                                  ["."])
                                :documentFormattingProvider t 
:documentHighlightProvider t :documentRangeFormattingProvider t 
:documentSymbolProvider t :definitionProvider t :executeCommandProvider
                                (:commands
                                 [])
                                :hoverProvider t :referencesProvider t 
:renameProvider t :foldingRangeProvider t :signatureHelpProvider
                                (:triggerCharacters
                                 ["(" "," "="])
                                :textDocumentSync
                                (:change 2 :save
                                         (:includeText t)
                                         :openClose t)
                                :workspace
                                (:workspaceFolders
                                 (:supported t :changeNotifications t))
                                :experimental nil)
           :serverInfo
           (:name "pylsp" :version "1.4.1")))
--8<---------------cut here---------------end--------------->8---

The interesting difference is the following dialogue. The client request
is identical on both machines (expcept the temporary file name):

--8<---------------cut here---------------start------------->8---
[client-request] (id:2) Fri Apr  7 13:30:45 2023:
(:jsonrpc "2.0" :id 2 :method "textDocument/completion" :params
          (:textDocument
           (:uri "file:///tmp/eglot--fixturepBX5M9/project/something.py")
           :position
           (:line 1 :character 7)
           :context
           (:triggerKind 1)))
--8<---------------cut here---------------end--------------->8---

The server reply on my laptop is

--8<---------------cut here---------------start------------->8---
[server-reply] (id:2) Fri Apr  7 13:30:46 2023:
(:jsonrpc "2.0" :id 2 :result
          (:isIncomplete :json-false :items
                         [(:label "exit(status)" :kind 3 :sortText "aexit" 
:insertText "exit" :data
                                  (:doc_uri 
"file:///tmp/eglot--fixturepBX5M9/project/something.py"))]))
[client-notification] Fri Apr  7 13:30:46 2023:
(:jsonrpc "2.0" :method "textDocument/didChange" :params
          (:textDocument
           (:uri "file:///tmp/eglot--fixturepBX5M9/project/something.py" 
:version 1)
           :contentChanges
           [(:range
             (:start
              (:line 1 :character 7)
              :end
              (:line 1 :character 7))
             :rangeLength 0 :text "t")]))
--8<---------------cut here---------------end--------------->8---

But on Emba, we see only

--8<---------------cut here---------------start------------->8---
[server-reply] (id:2) Fri Apr  7 01:05:39 2023:
(:jsonrpc "2.0" :id 2 :result
          (:isIncomplete :json-false :items
                         []))
[server-notification] Fri Apr  7 01:05:40 2023:
(:jsonrpc "2.0" :method "textDocument/publishDiagnostics" :params
          (:uri "file:///tmp/eglot--fixture5UoqLl/project/something.py" 
:diagnostics
                []))
--8<---------------cut here---------------end--------------->8---

So a different reply, with less information.

> Well, how about coding the test Michael asked, and I seconded, then?
> I agree that it will be a much better use of our time than keeping
> arguing about it.

I have absolutely no idea about the language server protocol, and
whether both server replies are valid communication. If both are valid,
eglot shall support this.

If not, I believe eglot shall raise an error like "protocol mismatch",
and eglot-tests could catch this error and use it as indication that the
test has to be skipped, with a respective skip message.

> TIA

Best regards, Michael.