当然是以最初级用户为标准呀，比如非程序员的普通用户，他们可能连 terminal 都不清楚是什么。
前Atom团队开发，Atom应该是能终结emacs,vim的编辑器中最失败的一个, 但为啥还有那么多人看好原Atom团队, 是因为tree-sitter的原因吗
感觉跟开发语言是 Rust 的有关系。风头无两。
不只 tree-sitter，Atom 启发了快要目前最可能终结 Emacs 和 Vim 的 VSCode。Electron.js 本来实际上是为了 Atom 开发的。所谓 Atom 失败，也只是被它后继者的 VSCode 取代了。
5 个赞
任举一例: Windows 下使用 Emacs 的 Tramp, 要多麻烦有多麻烦. 还得先去下个 PuTTY, 而且使用过程中还有坑, 这些我都忍了, 慢慢摸索就是. 最难蚌的是不管在 Windows 下还是 Linux 上用 Tramp 都巨卡, 跟 VSCode 的比就是弟弟. 有些功能适合 built-in 用 C 写而不是 Lisp, 比如这个.
再一个, 平滑滚动也是千呼万唤始出来, 而且还对设备有要求 (当然你可以下软件绕过这一点, 但我综合体验下来用的最顺的还需要付费).
不想用 putty 的话，用 Windows 自带的 OpenSSH，tramp 方法选 sshx 就行，哪怕懒得看自带的 Info，解决方案论坛里搜也有
显然你都没试过 rsync 方法，甚至 ssh control master 方法。
6 个赞
你说得对但是应该没多少 Emacs 新手会了解这些东西, 并愿意花费精力去尝试, 然后应用到自己的配置中. 你跟我说这些 workaround, 我可能也许大概能看懂, 但你要是让一个初次接触 Emacs 的人去干这种活儿, 我恐怕他转头就去下载 VSCode 了.
2 个赞
但是我觉得新手应该不知道还有 tramp⋯⋯反正我是用了两年 Emacs 才实际把这功能用起来的。
所以一般我默认都知道 C-x C-f 有这么个隐藏功能了，应该得有不错的答案搜索能力，觉得不好用可能就是单纯没有动力去改进 workflow，凑合能用就行的心态。
4 个赞
+1
我觉得zed挺无聊的，
编辑器要不拓展方便 能让你对自己工作流进行针对改造，要不bloatware 什么都有开箱可用 用户学习编辑器的工作流
单纯为了写的舒服流畅我宁愿用发的jb订阅，vscode也是好在两头兼顾（都到了够用的等级），helix和zed倒是两者都不够用…
3 个赞
同意。zed 最大的新意可能就是多人同步编辑文件。但是这东西我不觉得真的很有用，我还是更 prefer 异步的 code review 的形式，同步编辑更适合 office 这种不好版本控制的文档。对于使用 git 的代码来说，没大用。
其他的功能，lsp 是 vscode 主导开发的，treesitter 倒是 zed 主导开发的但是 neovim emacs 都内置了。AI 做的也不如 cursor。拓展系统也不够完善。
到最后，zed 还剩下啥，你总不能说是用 rust 写的原生 UI 所以比 vscode 用 electron 更流畅吧。我反正是看不出来 zed 在现在的编辑器里目标是占据哪个生态位。
helix 我倒是觉得有自己的生态位。它是一个把 lsp ，treesitter，内置了的开箱即用的终端编辑器，类 vim 模式键位还算好用，不会配置 vim/emacs，又需要用终端写代码的，还真的可以开箱上手用 helix。我现在就是把 helix 当做我在 windows 下的 $EDITOR 。（因为我的配置 hard code 了一些 unix-specific 的内容也不想专门花精力适配 windows）
3 个赞
同步编辑，如果是用latex写paper的话，那还挺不错的功能。word 自己的同步做得很不太理想，有时候会丢内容，用的时候需要比较小心，Google doc 这方面做的不错。如果zed能替代Google doc在同步编辑下的能力，比如就算是写纯文本文件，也能更好的同步，那还是很好的功能。
这倒是一个我愿意尝试zed的一个角度。
zed之前试过，感觉就是超级快。
上古神器有上古神器的包袱, 新生代有新生代的缺陷. 过了这么久你我还能在这里相遇, 说明它必然有着不可替代的理由.
看一个软件成不成熟, 可不可用, 我都是在Debian的仓库里找, 如果当前 stable 版本及其往后的版本有, 那么说明这个软件已经很成熟, 可以用了. 否则的话, 还得再等等, 火候不够.
7 个赞
式微有啥统计数据的支持么？我觉得会用 vscode 的人，之前大多数用的也不是 emacs 啊，我用 vscode 之前用的是一个 c++ 的软件，叫 codebricks (啥太久没用都不记得了)，然后是 clion。我同学在 vscode 之前用的 sublime text。我的另一个同学则是 visual studio。如果 java 则是 eclipse。我的意思是，没 vscode 之前，emacs, vim 也不是主流啊。虽然我确实知道从 emacs 跑到 vscode 的。
1 个赞
org-mode 我都默认不打开 fontlock-mode 的
VSCode 诞生前后海量的用户增长量, 这是凭空冒出来的么? 不过说到底也是我的推测, 你可以不信.
另外你说的那玩意叫 Code::Blocks.
直接看 stackoverflow 的年度问卷调查
蓝色的点是实际在用的，红色是明年还会继续用的比例，不参与排序，VSC 58.7%, Vim 16.42%, neovim 12.56%, Emacs 3.82%
下面是 2018 年的，VSC 34.9%, vim 25.8%, Emacs 4.1%
结论是确实受到 VSC 冲击，但是 Emacs 因为本身用户少到可怜，影响远没 vim 受到的大（当然有 neovim 的额外因素），甚至相比 2015 年的时候涨了一点点。冲击最大的是 Notepad++ 和 Sublime Text，这两个几乎没特色功能，就真的只能靠用户惯性了，虽然还在 emacs 前面，但也已经不如 vim
4 个赞
我同意有大量的 vim/emacs 用户转移到 vscode 这个观点。
其实很多 vim/emacs 用户是不写配置的。很多的都是用默认配置，最多就是用 package-install 装几个包然后启用一些 (xxx-mode)，不用任何配置的 vim 用户就更多了。这些用户很多都是只在 ssh linux 终端里用。 vscode 出来以后能很方便的远程连接，就都用 vscode 了。
觉得 emacs 用户和 vim 一样多，恐怕是个错觉。
在 VSC 以前，Notepad++ 35%, SublimeText, Vim 15% 排前三，而 Emacs 排老四也就 3.8%
不写配置还用 Emacs 的人也远少于 vim，因为有 MicroEmacs (GNU Mg) 这个替换选项
实际上我开始用 Emacs，也是因为 Spacemacs，那也是 Emacs 用户数开始起色的时期。当然因为 GNU Emacs 开始频繁更新不兼容功能的问题，导致只有所谓轻量化配置套件才能存活，就是另外一回事了。
甚至根据上面的调查，可以说，考虑到 neovim，用 vim 的人数总体是在涨的，在 VSC 出来以后一直保持 25% 左右。
1 个赞