[Idea] Native Language Server Protocol API for Daemon #440
Replies: 2 comments 2 replies
-
|
Hey @3timeslazy! Thanks for working on this! This is a very cool idea, and it'd be really awesome to give many editors Teamtype capabilities all at once! zormit and I tried your LSP-to-Teamtype bridge today, and wanted to give you some feedback/share experiences in various areas! ScopeIn the interaction flow you're suggesting, we noticed that you're discussing two features that we could pull apart a bit, or develop one after the other:
While these two feature would play well together, maybe we could tackle them independently of each other. My gut feeling is that maybe focusing on the LSP wrapper here is a good goal! How to deal with non LSP-compliant editorsWhen I tried to get my Ruby LSP bridge to work, I tried it with Kate. However, I eventually learned that Kate doesn't take document versions into account at all, which will make stable synchronization impossible, I think. So this LSP bridge approach might indeed not work for all editors, but I think that's okay! We could document for which editors we'd recommend this approach! To support other editors, I think we'll still use the "custom" Teamtype editor protocol for a while, which we're in complete control over. File ownershipTo my knowledge, in LSP, when an editor sends a So these concepts are a bit different. By default, several editors are unhappy when the files are changed behind their backs... but we could have an option for the daemon not to write into opened files, I think? Two editors which open the same fileIdeally, this would not result in two daemons, but only one. But there would be two instances of The Pitfall, take 2When we develop an LSP bridge, this bridge would need to figure out which edits the editor sends to it are from the user, and which one the LSP caused itself. We saw that in your attempt, you try to compare the incoming edits against the "expected" edits in order to tell these apart. Unfortunately, this may not be enough; I can see two things go wrong:
Unit testingAlso, it occurred to me that the LSP bridge might be pretty easily testable! That could help in development, by making sure that it does exactly what we want! For editor plugins, we usually have the problem that it'd be difficult to unit test, because we'd need to "remote control" the UI. (We do have an integration test involving Neovim, however!) That's all I can think of right now! I'd be exited to see you explore this idea more!! Let us know if you have more questions or encounter any blockers that we could help with! |
Beta Was this translation helpful? Give feedback.
-
|
Hi @blinry , Thank you for the elaborate answer! I have a few comments here. Scope
I agree!
GitHub gives me 404, it seems like the repo is private. How to deal with non LSP-compliant editors
I managed to run it with the LSP, it works but with some caveats. It real-time only when the auto-reload is enabled and feels slow. kate-helix.mp4File ownsership
I didn't put into my original message, but in the LSP mode, the daemon should not edit the files directly (because not all editors are dealing fine with it, like Zed or Kate), but send changes through The Pitfall, take 2
I didn't know about that VS Code behavior, interesting. Thanks!
In the current teamtype-lsp implementation, the logic is:
I think there should be no problems with that particular case, but there might be others With the rest I agree |
Beta Was this translation helpful? Give feedback.
-
|
Quickly coming by here, https://github.com/teamtype/teamtype-lsp should now be public. |
Beta Was this translation helpful? Give feedback.
-
Non-compliant editorsIn Kate, because it doesn't properly handle document versions, I would expect the synchronization to break once edits are made to Kate and Neovim in parallel. I sometimes tried "simulating" Neovim edits using this line of Lua, which inserts an "x" at the beginning of the file every 0.5 seconds: :lua t = vim.uv.new_timer(); t:start(0, 500, vim.schedule_wrap(function() vim.api.nvim_buf_set_text(0, 0, 0, 0, 0, {"x"}) end))The solution would be to open issues against Kate, or even help properly implementing it, I guess! OwnershipI think it would be totally feasible not to have the daemon write to files in an LSP-mode! The only downside is that we won't get "live preview" that way, in automatic linters for example, or when working on a web application. In practice, we've found that very helpful – but I guess you could always configure your editor to do auto save! We'd need to be a bit careful not to trigger the file watcher of Teamtype when the editor saves a file after sending the close message (not sure whether that can happen)? PitfallI'm afraid there is a problem with the approach of "store the expected edit and remove it when it arrives":
That's why I think the approach of storing expected "resulting buffer content" might be required. Do you get what I mean by that? (Maybe there are even other solutions for this problem?) Would be very happy to think about this more with you or attempt refining your prototype! If this approach works out, it would be super helpful for giving collaboration features to so many editors! :O |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi everyone,
First of all, thanks for the project. It is really cool!
Just for fun, I made an LSP server backed by Teamtype here: https://github.com/nonscalable/teamtype-lsp. It is very small and simple, and while I've been making it, I've got an idea. I thought that would be interesting to share and hear the dev's thoughts
The idea is a native LSP interface for the daemon.
Why? I think it could serve as a backend for editors plugins. It would make the plugins thinner and let them focus on the UI rather than re-implementing common logic, such as updating the local buffer and handling the pitfall.
For that, the daemon would need to have two groups of RPC endpoints:
By UI I mean all of kinds of popups making the UX better and potentially solving #422 and #411
An example of two users interaction flow.
Let's assume the Teamtype daemon has the LSP interface AND sharing and launching the daemon are two independent steps.
In that case, when a file (or workspace) is opened, the editor starts the daemon (which is just a language server from its point of view). At this point, the daemon only starts the Plugin/Daemon loop. When two users (A and B) want to start a sharing session, the following happens:
teamtype sharedoes now (creating the wormhole, .teamtype directory, etc.)teamtype join <code>part, starts its LSP loop and replies with the status.I have questions that are not clear to me:
But still curious what you think
Beta Was this translation helpful? Give feedback.
All reactions