vscode 已经成为免费 editor/ide 的第一名了，而且很难看到再有革命性的革新。

vscode 搞成了好几件事，最大的贡献是把 electron 搞火了。之前 atom 感觉非常慢，所以虽然技术出来了，但大多数人都懒得去试。

其次是搞了一个 Language Server Protocol，这货模糊了 editor/ide 之间的区别，而且也避免了每个语言都得给不同的 editor/ide 做支持。

跟 sublime 比，除了免费以外，自带的插件管理/插件市场也是一个虽然不起眼，但却起到实质的决定性作用的一条。sublime 连插件管理本身都得装插件，除了得背快捷键以外，完全不直观这个插件干嘛用的，有多少人用。

然后就是一些非常好用的插件了，比如 remote ssh/container 插件，不知道神器公司有没有对应的，但 vim 本身是不支持的，emacs 是单线程从根上就治不好了。再比如 git 管理，我之前还用 source tree 之类，现在已经完全 gitlens + git graph 了，再满足不了也基本只能敲命令行了。据说 emacs 上的 magit 是神器，很多人不愿意换的最主要原因就是它，但我没用过也不好评价。

另外还有一些非常贴心的设计，比如自带的 terminal，质量是相当高的。remote ssh 连上去比用本地的 term 连过去好用多了。自带的 git 管理，对于不习惯用命令行的人来说也简单多了。我就教我们的 dba 用 vscode 建 branch、commit、push，反正基本上学会这三条基本上就够用了。

还有一点就是 js/ts 的崛起，vscode 作为用 ts/js 开发的 editor，插件也是用 ts/js 写的。这样形成了一种正向反馈，vscode 对于 ts/js 的开发也极度友好，插件非常丰富，反过来又促进了 vscode 的插件生态。

缺点也是有的，尤其对于超长行（比如 minified js/json 文件）、大文件的处理超级糟糕，稍微长点儿大点儿就打不开了。另外就是后台一堆 node 进程，窗口开多了把 cpu 跑满的事情也时不时会发生。但总体上来说，现在 vscode 已经站的相当稳了。

【 在 xieyf (绿蚁新醅酒，红泥小火炉) 的大作中提到: 】
: 难道vscode要一统江湖?
: vim和emacs还在苟延残喘, 看样子可以喘很久.
: sublime text那就是gg了
: ...................
--
修改:eGust FROM 122.59.183.*
FROM 122.59.183.*

vim 插件是挺奇怪的，我以前试验用 neo vim 会好很多，缺点是需要装 neovim nightly

记得今年 m$ 搞了一个需求调查，最后结果是对 vim 支持的投票最高，所以官方支持的优先级应该会提高很多吧。

我本身不是 vi 的重度用户，vi/vim 也只是偶尔远程的时候用用。本身的功能有时候会受影响，所以后来就把 neo vim 插件给卸了……

【 在 pangwa (学门手艺，混口饭吃.) 的大作中提到: 】
: 我用过一个vscode里模拟magit的插件, 不确定是不是edamagic, 体验有些奇怪, 因为有些按键插件没法接管, 所以有不少按键不工作, 而且和vscode的vim按键绑定也有些冲突,  
--
FROM 122.59.183.*

说到 web 版也的确是很重要的一个应用，早期 jsfiddle 那种给几个窗口加点语法高亮就能当产品放出来了。如今在线开发前端都是很正常的，比如 stackblitz，codesandbox 就直接基于 vscode 改的，快捷键都一样。

再比如 github1s，虽然现在我也还有显示树形结构的浏览器插件，但跟用 vscode 打开比起来，易用性实在是不可同日而语。

作为 editor 学了之后很多地方都能用到，vscode 之前恐怕只有 vi 做到了

【 在 ilovecpp (cpp) 的大作中提到: 】
: 还有因为技术路线的原因，实现remote和web版十分容易。
: jetbrains不得不搞了个java远程桌面来实现remote。试了一下，十分迟钝，聊胜于无。
--
FROM 122.59.183.*

只要会写 ProxyCommand 一切都不是问题
比如这是我的 ~/.ssh/config 文件里最复杂的一条：

Host *.i-*
  User foo
  ProxyCommand aws ssm start-session --profile bar-(echo '%h' | sd '^(bar-)?(\w+)\..+' '$2') --target (echo '%h' | awk -F. '{print $2}') --document-name AWS-StartSSHSession --parameters 'portNumber=22'

只要我的 ~/.ssh/id_ed25519.pub 在 ec2 的 /home/foo/.ssh/authorized_keys 里面，我就可以 ssh someprofile.i-abcd1234 直接登上去

我用 fish 语法跟 sh/bash 稍微不一样

【 在 stub (stub) 的大作中提到: 】
: 关键公司所有机器都需要跳板机
--
FROM 122.59.183.*

反正看过别人的描述，我对 emacs 远程编辑的理解就是只能凑合用的程度：
https://news.ycombinator.com/item?id=27012799
volta83 8 days ago [–]

I think nativcomp doesn't really improve what makes emacs "slow".
Emacs is a single threaded synchronous and blocking UI system. Sometimes when my autocomplete, C++ checking, git checking, auto formating, ... run, the editor freezes, for multiple seconds.

All this stuff runs in the UI thread. Braindamaged.

The other thing that makes emacs slow is remote editing. Emacs TRAMP uses one ssh connection per command. VS Code spawns a remote server and asynchronously updates the remote's state. VS Code remote editing experience is as good as the local one, but emacs experience is supper laggy, recurrent freezes of multiple seconds, etc. Particularly when navigating the filesystem in the remote in any modern emacs way (helm, ido, etc.). Or when auto-save happens and everything blocks for multiple seconds, etc.

---

I don't really care if native compilation makes single threaded code faster, if that single threaded code runs in the UI thread and blocks the editor for 10 seconds. Sure now it maybe blocks for 9 seconds, because you can't do much about those 9 seconds you have to wait for some IO operation to complete. But that still sucks.

【 在 zyxwvutsrqp (<m|p|n>=1) 的大作中提到: 】
: emacs/tramp 也是直接通过 ssh 打开远程文件，然后直接打开远程 shell 来干所有的事。单线程不是问题。
--
FROM 101.98.83.*