Closed imron closed 3 days ago
This is a feature I'd love to see built into Zed. It even think it would be be neat if you could remote into some server and do the same collaborative editing there as well, although I don't know how often that would be used - maybe in the context of "fighting fires."
This feature is so useful that Jetbrains recently revamped their entire approach to remote development with Jetbrains Gateway to have something similar.
OT, but I wonder if this has improved significantly since I tried it last - it was super clunky and heavy handed when I first tried it. I much prefer how VS Code's works, it is a lot more simple.
OT
I don't think it's off-topic - in fact having this work smoothly and seamlessly is a major part of this feature.
I haven't used Gateway, but their previous remote development solution (which involved rsyncing files between machines) was also super clunky (especially when the host was Windows and symbolic links were involved).
VSCode really knocked it out of the park with the remote developer extension and it should be the standard to aim for and improve upon.
It even think it would be be neat if you could remote into some server and do the same collaborative editing there as well, although I don't know how often that would be used - maybe in the context of "fighting fires."
I imagine good collaboration tools would be really useful in this space (I've previously had to collaboratively fight fires over a mix of slack and zoom and other tools), however there are also potential security concerns as anyone connecting to Zed for collaboration would have the same access to the host as the user that ran the Zed process (which may not be themselves).
You don't want people connecting to Zed 'server' that is running as sudo (to fight fires on a file that requires admin priv to edit), and then have connecting users be able to open a shell in the remote terminal as root and do things.
I was holding back on this feature, but now that it is out here, I'll also jump in. π
At the time of the Xray experiment, one mind-blowing feature was the ability to spin up the editor in headless mode. If I recall correctly, this mechanism was the backbone of the editor's web version. Reading through Discord, using the editor from the browser (i.e. the web version) is on the roadmap, so I hope to see this capability resurface. π
But I also agree with @imron; such a feature should be paired with (granular) users' permission management. Not sure if this goes outside of Zed scope's, though. Xray allowed access only to files loaded in the workspace, but this becomes more complex when the terminal is integrated within Zed. But then again, the permissions story could be somehow managed via user and user groups provided at the OS level? I'm not an expert, so I'll leave it to the team.
I'd also love to see this.
Btw this format in the CLI would be fantastic:
zed user@host:path/to/project
vs code's format is very strange by comparison:
code --remote ssh-remote+workspace
I can understanding adding a flag though, esp if e.g. you don't specify user@
(which btw vs code somehow forgot to support specifying a user (in any format)):
zed host # yeah not enough context
zed user@host # probably ok if you don't mind the inconsistency of conditionally allowing --ssh to be omitted
zed --ssh host # πͺ
zed --ssh host:path/to/project # πͺ
zed --ssh user@host:path/to/project # πͺ (totally understandable to require the --ssh flag)
+1 to this, it's definitely a must for me because of WSL2 - which is currently the only way to have a decent development environment on Windows for non-MS stuff.
The discussion seems focused on launching zed from the local machine to edit a remote file. As a user of rmate, then rsub, then ratom (well, maybe I renamed it ratom), I have the following:
Would like to suggest adding a feature that is equivalent to rmate/rsub for zed, i.e. the ability to trigger a local zed from a remote machine to edit a remote file.
I believe "remote development" is not only about editing files of a remote machine but also connecting to an LSP server running on the remote machine. As far as I know, very few LSP servers allow clients to connect to them via TCP, so maybe an additional forwarder program is required to be installed in the remote machine.
As a person who comes from the NeoVim world, there are already something like distant and distant.nvim. Since distant
is a general library and is written in Rust, I guess it might be easy for Zed to integrate with.
Most important for me would be to remote into a container from a local Dockerfile or docker-compose. Same functionality as with vscode's dev containers. IMHO this is much better than simple SSH.
Adding a +1 vote to this but with a little context.
I have a workstation that I do most of my actual programming on, which I access from various different machines as a "frontend" to that workstation. I've always really enjoyed VSCodes support for this exact scenario and how seamless and easy to setup it is. Would love to see this implemented in this editor. One thing to note however is that the workstation is Linux based and most of the machines I use as "frontends" to that workstation are macOS based, so this might involve making the editor work on Linux as well.
I use this feature everyday with VSCode as I am having my source in a remote computer, then when I tried Zed and it lack of this feature, I cannot experiment any further. Please adding this feature as it is very useful.
I love this feature in vscode, because it is a pain to unify your own development environment on different computers, by remote development, I can start development on any new machine by install a vscode, even on some computers with extremely low configuration.
This is a blocker to me regularly using zed. I almost always use vscode remote developing from my laptop to my desktop at home, so it would be disruptive to change this workflow to use zed.
If this feature was supported, then I would definitely switch to use zed as a primary editor when using my low end MacBook Air.
I'll also chime in with some additional context around this feature.
For my use case (and others who work with HPC) almost none of our development is done locally. VSCode is the de facto standard due to the remote development tools. I know that JetBrains also has some remote development tools although I'm not too familiar with them.
It would be great to see another editor that could support this use case and it seems Zed might be uniquely positioned to pull off an amazing user experience given the infrastructure built around collaborative editing. Excited to see what can come from this!
+1 for remote lsp connection, I really like docker dev environments for keeping host machine clean
Remote connection is also a big blocker for me using zed. Keep up the great work!
+1, I use remote env everyday. It could be amazing to have this feature in Zed.
Supporting devcontainers will open up a lot of possibilities, including easy integration with developer tools, like newly launched DevPod, which supports launching development environments locally or on the cloud platform of your choice.
Launching a whole headless zed on the remote sounds like a good solution - it would trivially allow for remote language servers without them having to support TCP. And remote language servers etc integrations in the correct target environment would make life way, way easier than trying to approximate something similar locally with SSHFS. I occasionally write code where some dependencies are simply not available on mac, so every file that uses those upsets the language server.
Sadly can't use zed in its current state because our entire development is done via VSCode devcontainer.
+1. Please please please make the remote development feature happen.
+1 for remote connection
lapce support SSH and WSL remote development https://docs.lapce.dev/get-started/remote-development
The remote dev in Lapce looking interesting but the editor itself is really in its early days. Even the basic core editing features aren't there (find & replace, bookmarks etc), no way to use as a daily driver.
Though Zed is not far ahead in this department either :( Wish the devs first implemented basic editing before taking on the fancy complex colab features.
Wish the devs first implemented basic editing before taking on the fancy complex colab features.
As frustrating as that is, I believe they took to heart (at least some of) the lessons that were learned in the XiEditor project which was pioneering efficient text editing in Rust. There it became quite clear that you can either design for multiplayer editing from the start (hard, takes a long time) or you can "just" get the basic singleplayer functionality in place and then rewrite everything from scratch upon realizing that doing multiplayer right requires a completely different approach (still hard, still takes a long time, additionally wastes a ton of work).
Btw since plugins are such a popular feature request... If you want the editor to stay responsive with huge files, plugins will essentially need to be handled as "AI players" which in turn requires (surprise!) collab functionality to be in good shape.
TBH I don't quite see how, say, adding Find and Replace function in addition to already existing Find function is staying in a way of rolling out anything else.
However, the lack of Find and Replace etc basic editing features is definitely staying in the way of wider adoption. It is just not useable as it is, you have to constantly switch to Sublime or whatever for certain editing ops. Doesn't work for anything other than super light projects with a handful of small files. I'm itching to fully switch myself but can't do w/o basic editing functionality. Same story with few other colleagues who tried Zed.
This is, of course, providing Zed Industries are even interested in attracting large crowds at this early development stage at all. Perhaps whatever goals they targeted have been met as is.
Hmm, it would seem the functionality is at least partially already there, it just lacks UI. I recommend voicing your concerns regarding this particular functionality over in zed-industries/zed#5439 (and of course upvoting the issue). Similarly for other editing ops you are missing, please give existing issues a vote or create new ones if there is none.
Been there, seen that. Select Next is an escape but only if you are dealing with small files. A handful of text occurrences. Not going to fly with large files and tens or even hundreds of occurrences. It would of helped if there at least was an option to "Select All" in the Find, yet another basic function in other editors.
Anyways, this is not the place and Find & Replace was just an example. There are many more missing basic editing features.
My point is that, perhaps, basic editing should have been covered first before shooting for the stars. So that devs could already migrate to otherwise awesome editor w/o waiting for the complex features to come in place first and the team to return back to the basics afterwards...
My "basic editing" is going to look very different from yours (and that of Zed devs), hence why I'm asking for input/votes on the specific feature requests.
I do a lot of professional python coding, both locally and in docker containers. We don't have a huge team, but using docker as a dev environment helps keep things consistent when the devs are all using different local hardare. I'm already loving Zed for local development, but I would love a remote dev feature just like VS Code! I'm definitely adding my like/vote to this feature.
+1
What about a Gitpod integration ?
+1. Would be an amazing for ML community. A standard ML workflow is to edit code directly on a beefy GPU capable server. If there is already a workaround / an existing feature would love to hear about it.
@sandhawalia as a workaround you can mount the remote folder locally via sshfs. It's not perfect but works well enough for a lot of things.
+1 I do a lot of dev from macOS onto beefy linux machines over ssh with VS code. Especially while I'm traveling, this feature is killer for me.
Still waiting to have this feature on Zed.
I use a Chromebook. These devices generally don't have enough computing power to handle tasks for work, but with remote editing they become viable machines.
I use a Chromebook. These devices generally don't have enough computing power to handle tasks for work, but with remote editing they become viable machines.
That's right. Just +1 to this issue. The remote feature also supports development on other operating systems too. I am looking forward to using this feature.
+1
+1
I have multiple machines that I use across the day in different places, having this feature would be great. A web version would be great too so I can bring my iPad instead of my laptop sometimes, even if the web version will be less performant.
The only reason I am using vscode for some of my small projects is because of the remote development capability. I can just spin up a remote docker container, and then use vscode or vscode-web to work on it.
+1
The use case that I have is developing linux apps on a Mac. Currently I'm using the Dev Containers function to have a linux container with all the dependencies, and with VS Code "Remote Dev" running in the dev container, I can use my normal LSP and C libraries as if I'm on a linux machine, even though I'm on a Mac. And with the emulation in Docker, it's possible to run an amd64 container on an Apple silicon computer making it possible to develop and run x86 programs. It appears to be an open spec now as well per https://containers.dev/
+1 for wanting this feature.
My team and I mostly have Macbooks, but we spend all of our time logged into remote machines (servers, in-office workstations if we're WFH, lab computers, etc). We all make heavy use of VSCode's "Remote-SSH" mode, and we'd have a hard time giving up that workflow.
+1
I liked Zed Editor, minimalist and quite fast, but it falls far behind in terms of features when compared to VSCode. I was excited to use it, but one thing I frequently do is remotely access machines on the server where the company I work for hosts projects. A feature similar to VS Code's ssh-remote would be really useful.
+1 I want this feature too
+1 I want this feature too
+1 if this means docker support, even better! not having docker in zed is what makes me still use vscode :/
+1 I want to try this so bad but don't do any local dev
+1, like vscode. docker container support and remote server development are necessary
Visual Studio Code has a killer feature, "Remote Development", which allows you to remote in to another machine or a docker container, and develop on the remote machine/container as if the entire directory structure and dev environment (including terminal shell) was local.
It would be great to eventually see this feature in Zed, and even if Zed doesn't support this in version 1, it's a compelling enough feature that it would be worth laying to groundwork early on to support it, especially while you're still figuring out the internal api for the editor and how pieces fit together.
For some anecdotal feedback on the usefulness of this feature, in my current role (C++ dev at a large enterprise), for various business reasons our choice of IDEs is more or less limited to VSCode or CLion.
Since I joined and started showing people how the Remote Dev feature of VSCode works, I have seen about a dozen diehard CLion fans switch to VSCode (despite CLion being a better IDE for C++ development) simply because the Remote Development feature works so well and our development process involves a lot of remote development - we have company issued windows laptops, but the software we develop is linux-based and development happens in a mix of docker containers, virtual machines, wsl2 and remote linux instances.
VSCode with the Remote Development extension makes this really easy to deal with and devs will put up with reduced capability on the C++ IDE side of things, for the superior remote development support.
This feature is so useful that Jetbrains recently revamped their entire approach to remote development with Jetbrains Gateway to have something similar.
Anyway, just wanted to put this out there as something to consider, because I guess it will be easier to make architectural changes needed to support something like this earlier rather than later.