如果只是性能问题我就放心了。。。
主要是担心vscode有更好的特性自己却不了解，显得井底之蛙了。
我说个思路吧，用unison保持本地与远端文件一致，然后在本地用emacs更新内容，unison自动同步到远端。执行shell命令可以自己单独开个终端，或者写成脚本用emacs相关函数调用执行。同步文件时只选那些你关心的，其他的不要同步。(超)大项目vscode会卡，这种方式不会。而且同步到本地相当于做了一次备份，即使服务器挂了(我这里经常出现)，你的劳动成果还在，还能快速恢复。
1 个赞
哪里比ssh爽？
我都是直接在服务端装emacs。term下用emacs。
1 个赞
我已经不用gui很久了。当然，只是emacs作开发。并没觉得有什么不便。而且在远端配合tmux 标签 emacsclient。非常方便。
1 个赞
tmux 按键跟 emacs 的会冲突吗？
我折腾了许久 tramp lsp，format 各种也采用类似方案了（用的 syncthing 同步），唯一的问题是会有写完，运行命令但还没同步过去的尴尬。
没有，而且tmux的前缀键是可以配置的。
1 个赞
如果你只要单向同步，可以用inotifywait + rsync，然后用flock搞个文件锁，让shell命令在同步结束之前不要执行。双向的话，uniosn不能在同步之后停下来，也不能对外发信号，搞不了。也许可以用grep过滤一下日志，检测运行状态，同步期间加锁，不准执行命令。以前我用的服务器在国外，延迟感人，确实会出现还没同步完就开始执行命令的问题。不过最近转移到了国内，出现这种情况的几率小了很多。
1 个赞
syncthing是那个用go写的工具吗？我之前简单浏览了一下，它好像要用浏览器配置，而且配置看起来很复杂，看得我头都晕了。
我简单看了下 uniosn，是要手动或者配合别监测工具（如你说的 inotifywait）？
我一般情况到服务器延迟不超过 50ms， 还是会经常出现本地文件保存然后切换命令行需要等待同步的情况，也可能是 syncthing 更新监测有延迟。 所以想大概了解下 uniosn 流程。
update: 发现把 fsWatcherDelayS 改低就行了_(:з」∠)_
是的，syncthing.net。配置我用起来了感觉还好，远程 syncthing cli show system | grep myID 然后在本地通过 id 配对，设置同步路径就好了。
在终端里面 CTRL-SHIFT-XXX 这种按键是不能用的，在tmux里也不例外。然后其他的常规的终端能用的快捷键在tmux里面都能正常使用，没遇到过bug。我的tmux的前缀是 Alt-<backquote>，是很低频的快捷键，然后如果要发送 Alt-<backquote> 就连按两下这个按键就行了。使用起来很顺畅。
终端里使用 emacs 其实很流畅的。我甚至在手机上都使用 ssh 来使用 emacs。 除了不能看图片，其他没啥不方便。
1 个赞
从我个人工作环境来说，我们都是在开发服务器上开发、调试。服务器硬件比较强，而且有显卡，并且时不时要用到别人编译好的动态库。如果要把开发环境搬到 Mac 本上，很费劲，不现实。 这几年我都是 ssh 到服务器使用 emacs，总体来说也没什么大问题。但是打字会有一点点延迟（服务器在国外，还隔了个跳板机），而且经常会有“闪屏”（初步怀疑是 lsp ui 引起的），比较影响体验。同时也丢失了一些 gui feature，心里不太舒服。 用了 vscode 的远程开发之后，想要通过 tramp 实现类似的体验。一开始是折腾环境变量，接着是 projectile 导致卡顿，所以全部换成 project.el。然后是搞 lsp-mode 的 remote client，时灵时不灵，看相关的 GitHub issue 也是一年多以前的了，尚未解决。最后发现 clang-format 也没有对 tramp 的支持。折腾了一周，还是放弃了。 相比之下，vscode 最大的体感优势就是“无感”。插件不需要专门去支持，因为他们就是运行在远端。环境、配置什么的也不用专门去适配，你也不会因为远程开发而丢失了本地的特性，因为 server 也是运行在远端。 同时说明一下，通过 socket 去连接远程的 emacs daemon 也是条死路，已经有人验证过了，我也是反复鞭尸了几次。
9 个赞
我理解 vscode主要的优势在于，他的插件也负责了安装一些binary的功能和配置，比如lsp-mode的langage server tool，如果用tramp，要自己下载binary到remote，remote client配置起来也有点麻烦。
不过我日常还是用自己配置的lsp-mode，我主要是用cpp，cpp的lsp-mode的format也是依赖remote有clang-format，有了之后是可以支持的。
如果麻烦不是给问题的话，真实的麻烦应该只有“性能”这一点。
50ms的延迟，用emacs terminal over ssh，体验确实是太差了。我觉得这种使用，属于没有为远程编辑做任何的设计，很不合理，必须要有local buffer，不要每次按键都有“同步”的网络通信，只在我需要的时候有确定性的“同步”网络通信，比如保存。
那么是否没有必要进行远程配置 例如本地配置的emacs直接以sshfs形式访问远程文件 这样脱离了远程编辑的范畴 也能实现基本的保存编辑 也不会有任何延迟
sshfs应该对应sync类型的方法。应该也是可以的
我暂时想到的
跳板的支持不如tramp方便，tramp可以pipe连接。不过sshfs只操作一次就可以了，也不算特别麻烦。
我常用的是 ssh｜docker，实际的代码执行都在docker里，包括language server。不过sshfs搭配一个同步过的镜像似乎也是可以的。都绕不过去
两种是不同的方法，tramp跟vscode server更接近，实际执行在服务器，sshfs和sync更接近。
所以问题变成sync类的工具，是不是可以用sshfs工具简单实现？
sync类应该也算一种完备的方法了，但是跟tramp比哪个更方便？
如果非常依赖于docker的环境, 需要实时进行调试的, tramp 会更方便. 如果只需要少数的调试, 以编辑为主的情况下, sync类比较方便
对，上面的讨论来看， tramp的设计跟vscode server几乎是等价的。如果像追上vscode的话，主要是性能需要提高。
终端也有看图片的命令。叫catimg还是啥来着，平时不用，忘了名字了
我觉着vscode 本地编辑远程文件虽然很流畅。但是这并不是唯一方式。
emacs vi nano 这一类经典编辑器，支持的经典term方式也是非常好的办法。而且有时候是更简单，甚至唯一的办法。所以我在vscode还没诞生的时候就这么用。现在还是这么用。而且安装emacs的插件的时候，如果依赖gui，我就放弃。
有的场景vscode tramp这种方式是非常麻烦或者不允许的。比如通过跳板机，或者某些堡垒机。部署之后不允许ssh 传输文件。或者公司规定文件不能在本机保留，只能在服务器上操作。不过这种情况除了直接term之外，还可以开个远程图形界面。
2 个赞