不是有tramp吗？我第一次看到vscode remote server感觉就是个tramp的fork
没用过tramp，不过试用了一下vscode 的remote ssh。 直接本机安装插件，远程连接，就可以直接debug远程主机上的代码。非常方便。
如果tramp卡卡的，那不做locally cache的那些只会更卡。
借问一下，eshell 里 tramp 每次执行命令都会重新建链接，导致每个命令都会等一下，这个有什么建议能优化一下吗？
这个是你的连接有问题吧？？
不过我个人不用eshell配合tramp，remote上的.bashrc或.bash_profile加载不了很蛋疼。。M-x shell够用了，还有shell-here插件
编辑过的文件是会缓存到本地的，甚至你把网线拔掉，重启 VSCode，那些编辑过的文件依然可以自动打开。
所以，VSCode 远程编辑的保密性不如在 Terminal 运行 Emacs，前者你能拷贝整个文件，后者只能拷贝屏幕上有效的内容。。除非一屏一屏滚动拷贝。
本机只是发送一个 Install 指令，VSCode 帮你把扩展／插件安装到远程电脑的 ~/.vscode/ 目录下，详见我这里的分析：
也就是说，扩展／插件必须能在远程环境下运行，好在大部分都没有问题。可是诸如 LSP 这类的扩展，它还依赖第三方的 server，微软不可能为所以平台都提供可执行文件，这时就必须自行在远程环境下编译了。
正常不会在正式服务器环境上开发吧。remote体验还是OK的，开箱即用，远程一下测试环境，能吸引到不少人。
如果是windows用vscode然后remote到wsl或者docker，可玩性还是有的，能直接有个linux开发环境了，如果是在remote到服务器，那还不如在本地开发呢，remote要插件生效的话，还是要把插件安装到服务器，大家都在服务器上玩，感觉也没多方便，倒是往服务器上装了乱七八糟的插件，如果是个人服务器，倒也不是不能玩
Terminal下emacs也是可以选中全部内容，然后拷贝啊。
而且远程编辑最方便的地方是它支持连接任何地方，比方说docker。目前公司的项目的环境全部用docker搭建了，也就是说不需要手动安装任何包了，这应该是一种趋势，保证开发环境的一致性，也不用操心在什么平台上开发。vscode可以attach docker container，也可以ssh forward remote port, 然后再attach，就可以remote editing了，很方便。
但是local环境就没有这些包，没法测试debug，当然你可以手动安装，但比方说你用的windows，开发环境都是linux，就很难保证环境一致，也会有很多问题。
不能直接拷贝，剪贴板不能跨 ssh。
当然，既然 ssh 都能连了，发送文本也不是不可以： Human verification - Stack Overflow
但是，如果公司对源代码管控很严格，必然会监管／阻断任何下载源代码的行为。这种情况下，恐怕 tramp 和 vscode-remote 都不让用了，因为这两种方式都是要把代码 cache 到本地。如果不禁止的话，保护源代码形同虚设。
1 个赞
的确，仔细想想确实是不能copy全部
terminal 拷贝没问题, 无论你跳了多少层ssh. 不过长度会有些限制, libvte 自动机大概能搞10万字节吧
用上了这个包，ssh terminal emacs下拷贝无压力 GitHub - spudlyo/clipetty: Manipulate the system (clip)board with (e)macs from a (tty)
3 个赞
简单说一下，使用 VSCode 连接到 Docker 开发环境，在真实环境下并不太可行，除了上面说的各种隐私问题，还有以下问题没办法解决：
- 网络波动会造成连接断开，直观的表现就是每隔一段时间会在屏幕上出现连接断开的提示，持续一段时间，实际上很影响开发效率
- 使用的人比较多，会占用路由器和交换机比较多资源，造成上面的这种情况
- 公司总是有网络不好的地方，只要网络出现问题就歇菜
综合以上情况，我更倾向于在本地编辑，然后通过 rsync 增量同步的方案，也就是我们现在经过验证后在使用的方案。当然，使用这个方案就无所谓编辑器了，所以这个需求感觉就是个「伪需求」……
docker是本地docker，怎么会有网络链接的问题，你如果在mac上开发linux 的c/c++服务器程序就知道连接docker进行开发是多么理想的情况了
不够话说回来，vscode 的remote功能即时再好，在跳板机面前还是没用，这就很尴尬
1 个赞
同步文件可以用这个软件unison
vscode remote development实际上实现的东西远多于此，不仅包含 language sever，而且debugger protocol 也包含了，所以可以实现ssh到remote，或者在local docker机器上无缝debug，设置断点之类的。
当然如果是远程的docker下debug会复杂点，我自己也没尝试过，但是是可以通过exprot port然后attach的。python用的是这个debugpy GitHub - microsoft/debugpy: An implementation of the Debug Adapter Protocol for Python.
其实我目前远程开发的方式还是直接ssh + tmux然后完全在 terminal下用emacs去debug，复杂一点的就直接上gdb, pdb，简单一点能搞定的就用dap-mode了。
别用 ssh 用 mosh，爽的飞起。
自己玩的话，在自己电脑上装 Docker 是没问题的。如果是公司内使用，会有专用的服务器来承载，然后采用 macvlan 的网络（或类似技术），伪装成一台拥有独立局域网 IP 的服务器。
为了我们的需求，我在 DockerHub 上做了一个基于 Alpine 的镜像，把 Node.js、Git、rsync、Tmux、SSH 服务器以及 Emacs 都添加了进去，这样就可以在启动容器后随便玩了。
我是前端开发，这么做主要的目的就是转移 Node 服务，在夏天减少自己 Mac 的发热，防止电脑降频带来的开发效率影响。至于环境统一以及其它的理由，反而是次要的。
新员工入职后的一般操作是：
- 在本地以 Tmux 启动 rsync，监视本地项目文件夹改动，只要文件夹有更新就同步到自己专用的开发容器中；
- 关掉本地的控制台，需确保 Tmux 已经成功启动；
- SSH 到远程容器，使用 Tmux 启动 Node 服务器；
- 关掉远程 SSH 连接，需确保开发容器中 Tmux 已经启动；
- 以上操作只要系统不重启，不安装新的 NPM 包就不需要再重复了（一些必要的操作还需要远程操作）
这样只要在自己 Mac 中只需要修改，哪怕是晚上在家盲写了一堆代码，第二天带到公司，触发一次保存操作，就可以将代码同步到开发容器中，以独立 IP 的形式访问容器中的 Node 服务了。至于是否在开发容器中使用 TUI 形式的 Emacs，已经不重要了。
unison 牛逼！好好研究下