MIT 几十年前的 X forwarding 不就已经解决了这个问题么。程序显示在本地，实际操作都在远程。除了对网络质量要求比较高，Windows 下搞个 VNC 或者 putty 不就完事了，而且不只限于单个程序，只要网够好想上网看视频都行。就算网不好，是跨洋网络，开个 Emacs 和终端模拟器也是绰绰有余的。
这个就不需要了, 很早就用过, 效果非常差.
试用了一下, 这个有点接近, 不过局限性太大, 问题很多:
- magit没法用
- flycheck工作不正常
- lsp之类的工具工作不正常
- 用户主目录不是对端的, 导致很多命令失效,
- 文件变化检测有问题
我感觉我想要的基本也就是这个效果了
想了一下，这样的话，本地的操作又需要再开一个 Emacs client 连接本地的 server 了🤣
我平时都是开三个emacs, 打开三个工程
Remote Development 没有开源？只找到这个：
我还想看看它去哪里下载适合远程环境的可执行文件呢。虽然暂时没找到它去哪里下载，但是在远程服务器上可以找到已经下载了哪些文件：
*@vps:~$ du -hd1 ~/.vscode-remote/
68K /home/*/.vscode-remote/data
93M /home/*/.vscode-remote/bin
51M /home/*/.vscode-remote/extensions
143M /home/*/.vscode-remote/
以及在远程启动的进程：
*@vps:~$ ps aux | grep vscode
* 4411 0.0 0.0 4288 768 ? S 13:20 0:00 sh /home/*/.vscode-remote/bin/473af33.../server.sh --port=0
* 4420 0.2 2.9 1297348 61716 ? Sl 13:20 0:07 /home/*/.vscode-remote/bin/473af33.../node /home/*/.vscode-remote/bin/473af33.../out/remoteExtensionHostAgent.js --port=0
* 4562 0.2 3.3 1391068 68752 ? Sl 13:22 0:07 /home/*/.vscode-remote/bin/473af33.../node /home/*/.vscode-remote/bin/473af33.../out/bootstrap-fork --type=extensionHost
* 4596 0.1 1.1 725204 23848 ? Sl 13:23 0:05 /home/*/.vscode-remote/extensions/ms-vscode.cpptools-0.22.1/bin/Microsoft.VSCode.CPP.Extension.linux
* 4616 0.0 1.2 328416 25292 ? Sl 13:23 0:00 /home/*/.vscode-remote/extensions/ms-vscode.cpptools-0.22.1/bin/Microsoft.VSCode.CPP.IntelliSense.Msvc.linux 45
这些可执行文件都是微软事先准备好的，用户只要执行 Remote-SSH: Connect to Host... 就注入。免去用户自行安装编译，这很好，我只是有点好奇，到底准备了多少平台对应的可执行文件？如果微软不为某个平台提供可执行文件，是不是只能一翻两瞪眼了？
是啊，如果有个分离的应用，只需要在本地serve一个project folder，然后大家就都可以在client (web 或emacs）端编辑，就好了。
只是感觉这个功能，难度大于实用性。现在vscode的在文件的rename, move上还是有很大的问题的，我试过几次。
不得不说因为这个功能可能要叛逃了，我用emacs原因就一个痛点，我希望只配置一个开发环境，比如windows上用wsl，公司我用linux，之前就是用xserver简单实现，现在，一切都解决了
想象过于美好。
Remote Development 的本质就是在远程运行一套无界面的开发环境，该有的扩展和配置一样都不能少。
诚然，VSCode 会自动帮你安装一些它推荐的扩展到远程服务器，看我在#26楼的回帖。
但是，你仍然需要自己手动安装额外的扩展。例如你在本地用了 lsp(clangd/cquery/ccls)，现在想要在远程使用，对不起，请逐一手动安装并配置。
UPDATE
VSCode 整体流畅度不错，只是一旦网络连接中断，就要 Reload 整个窗口（相当于x掉再打开），严重影响体验：
如果用的是 mosh 远程登录跑 Emacs，电脑盒盖休眠放多久都没问题。
1 个赞
试了一下 写python还是很爽的 各种插件包括 git / jupyter / lsp / conda一眼望去都支持的样子 shell也和conda有整合 python环境能自动识别（这是托python插件的福） 建立连接有点慢（静态分析和加载定义好像比较耗时 好在是async的） 但是很省心 (大雾 30min断了两次）
爱了爱了
补一张debug的 虽然我写script多一点 用的比较少。。
对于习惯了 emacs -nw 的用户来说，VSCode 的优点是美观和多线程带来的流畅。远程开发倒是不觉得很新鲜，终端里的本地和远程只有一 ssh 之隔，界线很模糊，Emacs 运行在哪一端区别不是很大。
远程emacs -nw开不了图 
选择在终端下使用 Emacs 的那一刻，就注定与图无缘了，无论远程与否，这也是一种牺牲吧。
装就完事了，其实还有个事，vscode入门门槛低，以后组建开发环境，比如我之前写的项目，别人用c写的python扩展，ububtu下引入openssl1.0，我manjaro1.1死活装不上，后来开了个虚拟机编译完拖回来，现在好了，以后没人分发一个docker-compose，直接 docker-compose -d爱咋玩咋玩去，爽翻天
远程用 ein 可以开图
ein的体验比vscode差远了。。。
（更正 我前面的回复是想说远程的emacs -nw不能开图
用port forwarding映射到本地的emacs当然是可以的 org babel其实也可以
但是比起vscode来补全之类的体验还是要差点
我想说 ein 还好了，够用，至少能实现 90% 的 jupyter notebook，而且不折腾。不过既然你这么说，看来我要再次尝试一下 VSC 了，看看有没有可能让我变节 ，反正之前几次都因为编辑和使用习惯不顺手而最终放弃。
突然想起了eclipse che(logo-eclipseche), 记得出来有两年了, 当时没什么感觉, 现在感觉挺先进的, 这种模式挺好, 在远端安装并启动eclipse che, 然后在本地用浏览器打开编辑, 补全, 编译, 调试应该都可以.
说这么多，最后还是ssh上去终端emacs最实用
大部分人选择编辑器，只看他补全好不好用，因为没有补全，就不知道怎么写代码了