Support rmate protocol

[dwt]

Check for existing issues

• [X] Completed

Describe the feature

This was already mentioned as part of the remote development ticket but the feature is much too important to be sidelined by that discussion.

The rmate protocol is very simple, it means listening on localhost on a specific port, and supporting a very small protocol to receive textiles to edit over it. This allows very simple remote work via ssh while editing the files in the comfort of the local editor with local plugins / shortcuts / everything.

• The original implementation is here
• A shell only implementation is here
• The VSCode rmate plugin lists several more versions of rmate

If applicable, add mockups / screenshots to help present your vision of the feature

[byronrode]

+1 for this for me.

Textmate used to have a feature to enable it, but as above, VSCode has an extension that allows you to start/stop the server (which just turns off the tunnelling listener I believe). I'd be willing to give this a bash as an extension, perhaps.

[hywhuangyuwei]

Wish this too! Having this will make it incredibly fast to edit remote files without needing to launch the entire app.

[dwt]

I would also like to add that it is much easier to implement than full ssh remote editing or any other protocol where part of the editor actually runs on the remote as all that is needed is a port forward to the target machine and some incredibly small programs (that already exist) to be running on the remote.

[dwt]

To be honest, I would really like for the rmate-protocoll to get a slight bit more functional, in that it allows opening directories on the remote host, but that is probably best left as an enhancement for later.

[zuckschwerdt]

To get things going I made a simple proof-of-concept rmate server for Zed. It handles incoming rmate TCP connections and then uses Zed with tmp files.

It could be a lot more robust, feature full, safer, prettier. Error handling is a mess. There are unwraps. It will basically panic on any problem.

But it should work just fine as the intended short-term stop-gap until proper support is added in Zed.

Find it at https://github.com/zuckschwerdt/zed-rmate-server with some binaries at https://github.com/zuckschwerdt/zed-rmate-server/releases

[byronrode]

This is a great first step. I haven't even had a chance to look at an extension, so thanks!

Sent via Superhuman ( @.*** )

On Wed, Jul 17, 2024 at 13:39:19, Christian W. Zuckschwerdt < @.*** > wrote:

To get things going I made a simple proof-of-concept rmate server for Zed.

It handles incoming rmate TCP connections and then uses Zed with tmp files.

It could be a lot more robust, feature full, safer, prettier. Error handling is a mess. There are unwraps. It will basically panic on any problem.

But it should work just fine as the intended short-term stop-gap until proper support is added in Zed.

Find it at https:/ / github. com/ zuckschwerdt/ zed-rmate-server ( https://github.com/zuckschwerdt/zed-rmate-server ) with some binaries at https:/ / github. com/ zuckschwerdt/ zed-rmate-server/ releases ( https://github.com/zuckschwerdt/zed-rmate-server/releases )

— Reply to this email directly, view it on GitHub ( https://github.com/zed-industries/zed/issues/8472#issuecomment-2233106753 ) , or unsubscribe ( https://github.com/notifications/unsubscribe-auth/AAC5IQTBOH2EGIWEEKGJN7DZMZJWPAVCNFSM6AAAAABD3WXTK2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMZTGEYDMNZVGM ). You are receiving this because you commented. Message ID: <zed-industries/zed/issues/8472/2233106753 @ github. com>

[byronrode]

Lovely @zuckschwerdt - just tested this, and it works really nicely

[zuckschwerdt]

I've now refactored the protocol handling to be standalone and reusable. Could be a starting point, but it's only tested against the https://github.com/aurora/rmate client so far.

[byronrode]

I've now refactored the protocol handling to be standalone and reusable. Could be a starting point, but it's only tested against the https://github.com/aurora/rmate client so far.

Nice. Will pull the updated version. FYI, in my multiple uses with this yesterday (we lost an entire k8s cluster 😢) I have had no crashes or issues.

The aurora rmate client is the only one I ever use, and was based off the textmate one IIRC.

[zuckschwerdt]

I can think of one possible issue causing grief: if you save and then close immediately the file change might not be detected before the connection is closed (on detecting Zed closed). We should re-check for dirty files before closing, but I don't see that in notify-rs. Maybe something like a second of grace period is needed?

[byronrode]

In my previous experience I lost some changes due to closing the window soon, so I generally keep it open a while anyway.

In the VS Code plugin I use, it shows a status of sorts in the status bar, something like:

Starting server… and then with files it has a saving/saved status for the file/buffer being edited. Generally I keep the window open for a while, and it's usually for configs etc.

On Thu, Jul 18, 2024 at 11:48:08, Christian W. Zuckschwerdt < @.*** > wrote:

I can think of one possible issue causing grief: if you save and then close immediately the file change might not be detected before the connection is closed (on detecting Zed closed). We should re-check for dirty files before closing, but I don't see that in notify-rs. Maybe something like a second of grace period is needed?

— Reply to this email directly, view it on GitHub ( https://github.com/zed-industries/zed/issues/8472#issuecomment-2236087928 ) , or unsubscribe ( https://github.com/notifications/unsubscribe-auth/AAC5IQXYYPBVFHGR3NB2VKLZM6FNRAVCNFSM6AAAAABD3WXTK2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMZWGA4DOOJSHA ). You are receiving this because you commented. Message ID: <zed-industries/zed/issues/8472/2236087928 @ github. com>

[zuckschwerdt]

The mtime is now tracked and a final check on close should catch all unnoticed changes.