-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No responses coming on STDOUT when starting jedi-language-server from cli #152
Comments
I think jedi-language-server doesn't support input from stdin, see #51. Maybe it's a good idea to add stdin support, even if only to do quick'n'dirty testing. |
For use-cases involving embedding Jedi-language-server in a web application, I believe you should use tcp instead of stdio. You can do this by passing the tcp option at the command line and then communicating with Jedi-language-server with tcp.
As far as specifics of what requests to use, it's somewhat beyond my current understanding. If you'd like to dig deeper, I suggest looking into pygls's tcp support and how that framework handles tcp. |
Thank you for your responses. |
Hmm, stdio is currently the default (used when you don't pass any options at the cli). Based on the linked issue above, looks like you might need "\r\n" at the end of your requests? jedi-language-server relies on pygls, which provides the foundation for both stdio and tcp support. Any difference in behavior between jls and python-language-server regarding stdio probably involves pygls. @danixeee do you have any suggestions here for interactive usage at the command line over stdio? |
The trick is to make sure that you are sending carriage returns; and you also need to remember to put an empty line between message headers and body. eg non-interactively, you want a file like
making sure that you have windows line endings, then:
Interactively, typing the carriage returns is not so easy. At first I thought that
|
Resolved by documenting steps here: befaecd |
You might consider adding an option to start |
Hello. I'm building a backend of a web app that's supposed to provide python editor with autocomplete feature on the frontend.
I wanted to use jedi-language-server as (what seems to me to be) more lightweight alternative to python-language-server.
I'd like to start jedi-language-server process in the background and communicate with it using stdin/stdout.
However when trying on command line, I'm unable to elicit any responses on STDOUT.
My environment:
OS: Fedora 34
python --version: Python 3.9.5
Here's the steps demonstrating this issue:
At this point I'm pasting some LSP messages on STDIN, like
Content-Length: 1062 {"jsonrpc":"2.0","id":0,"method":"initialize","params":{"capabilities":{"textDocument":{"hover":{"dynamicRegistration":true,"contentFormat":["plaintext","markdown"]},"synchronization":{"dynamicRegistration":true,"willSave":false,"didSave":false,"willSaveWaitUntil":false},"completion":{"dynamicRegistration":true,"completionItem":{"snippetSupport":false,"commitCharactersSupport":true,"documentationFormat":["plaintext","markdown"],"deprecatedSupport":false,"preselectSupport":false},"contextSupport":false},"signatureHelp":{"dynamicRegistration":true,"signatureInformation":{"documentationFormat":["plaintext","markdown"]}},"declaration":{"dynamicRegistration":true,"linkSupport":true},"definition":{"dynamicRegistration":true,"linkSupport":true},"typeDefinition":{"dynamicRegistration":true,"linkSupport":true},"implementation":{"dynamicRegistration":true,"linkSupport":true}},"workspace":{"didChangeConfiguration":{"dynamicRegistration":true}}},"initializationOptions":null,"processId":null,"rootUri":"file:///home/ubuntu/artifacts/","workspaceFolders":null}}
or
But there are no responses coming on STDOUT. Actually it seems that no matter what I enter on STDIN there are no responses on STDOU nor STDERR.
When I try similar steps with other language servers (like python-language-server) I'm getting responses on STDOUT.
Could you please advise if I'm doing something wrong or if this is a bug?
The text was updated successfully, but these errors were encountered: