Skip to content
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

Initial/simple handling of Server notifications/requests #26

Closed
wants to merge 2 commits into from

Conversation

IndianBoy42
Copy link

  • log::trace more messages
  • Naive handling of server requests

@IndianBoy42 IndianBoy42 changed the title Initial/naive handling of Server notifications/requests Initial/simple handling of Server notifications/requests Jun 14, 2023
Should work for one client connected at a time

Needs auditing of what server requests may exist and how they should be handled for multiple clients. Currently we just only forward the first result
@IndianBoy42
Copy link
Author

I've been using this for rust programming for the last week and it is correctly getting all my configuration and hasn't crashed otherwise. To be fair I am not really multiplexing and just using it to make restarting my editor faster.

@IndianBoy42
Copy link
Author

Fixes #15

@Ddystopia
Copy link
Contributor

Ddystopia commented Jul 10, 2023

Thank you for your work! It seems to work well, but there is one little issue: it does not react to the changes in editor's configuration until ra-multiplex is fully restarted and with multiple projects opened.

@IndianBoy42
Copy link
Author

Hmm thats pretty strange, on my machine I see all the configuration messages/requests/responses going through correctly, and a simple testing with trying to change between cargo clippy and cargo check works (no restart of ra-multiplex server required, just the editor). Could you give an example where the editor configuration change doesn't apply? preferable with the logs (use RUST_LOG=trace ra-multiplex server to see all requests and responses)

pr2502 added a commit that referenced this pull request Oct 17, 2023
this is a prerequisite for implementing #22 and possibly #26 in a way
i'd be happy merging. the advantage is that we'll be able to do more
manipulation of LSP when we understand it, the disadvantage is possibly
breaking some language servers with slightly broken LSP implementation.
@pr2502 pr2502 mentioned this pull request Oct 17, 2023
pr2502 added a commit that referenced this pull request Oct 17, 2023
this is a prerequisite for implementing #22 and possibly #26 in a way
i'd be happy merging. the advantage is that we'll be able to do more
manipulation of LSP when we understand it, the disadvantage is possibly
breaking some language servers with slightly broken LSP implementation.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants