各位道友好，本人开这个帖子只想和大家分享交流另一个很棒的编辑器，不希望产生无谓的纷争。对emacs和emacser拥有绝对的尊重。希望好的技术和工具互相学习和借鉴，让各位有更多选择和快乐。
zed最近已经集成了git，mac 和 linux 有预览版可以申请内测，而windows在自己编译的debug选项中也可以体验了。zed是一个我在使用过程中的任何流程都没有感受到卡顿的编辑器。它的设计借鉴众家之所长，每个地方都是全文本。现在内置的vim完成度已经非常高。下一步集成调试器之后，就会继续深挖可扩展性。记事本一般的速度和emacs级别的可扩展性(未来)。可以想象，它的未来值得期待。希望小伙伴和高手都来尝试一翻。discard上已经出现很多因为这波git的更新看到的一些emacs使用者了。我自己在使用中无比想念emacs上的一些插件功能，比如symbol-overlay. 我的分享还有一个私心，就是希望更多的emacs高手看到，也许就喜欢上并推动zed的发展。 
这是zed 2025的路线图
Zed 自己开发的的文本渲染引擎让我印象深刻， 飞快
可能是吸取了 atom 最终被 vscode 击败的经验和教训，这一次 zed 选择“卷土重来”的路上，选择了更加积极的拥抱开源社区，作为一家商业公司，开发出了 treesitter，让 neovim，helix， emacs 等所有编辑器都受益了，值得点赞。同时他们将自己的核心商业产品 zed 也选择了 GPL 进行开源，也同样值得点赞。
另一方面，我不认为 zed 在当前 focus 的 scope 足够吸引 emacs 用户。zed 目前的发展方向是快速开箱即用的编辑器，也就是你说的，“超级记事本”。而在可拓展性上的缺失并不足以吸引 emacs 用户。如果仅仅只是为了快，那 vscode 都比 emacs 快，vscode 的插件生态也比 zed 强了不知道多少，emacs 用户如果不满意速度，完全可以用 vscode。当然，如果我使用 windows，我可能也会选择使用 zed，而不会使用 emacs。每次一使用 windows，我就会不自觉的产生抗拒配置和折腾的情绪，选择我什么东西想要有开箱即用的心理。
记事本一般的速度和emacs级别的可扩展性(未来)。
你这个饼画的大的，zed 团队自己都不敢说。
https://zed.dev/docs/extensions/developing-extensions
首先 zed 目前开发插件只能用 rust 开发，而且根本就没有一个 scripting language 来做动态 evaluation，就这个扩展性怎么和 emacs / vim 这种配置即代码，配置即插件的编辑器比拓展性？
我在 zed 的 github issue 里也没有搜索到任何有关 scripting language 的计划，有一个 github 的 discussion 有人提出了使用 lisp 作为 scripting 的建议，这个讨论并没有引起广泛的注意和参与，仅有部分人提出使用 lua 是比 lisp 更好的选择，但是这个争论局限于了编程语言的争论，而并没有推进 zed scripting language 的拓展。
就是希望更多的emacs高手看到，也许就喜欢上并推动zed的发展。
emacs 的生态繁荣是因为用 emacs 为 lisp 提供了编辑器最底层的 API 方便 hack，并且用 lisp 写拓展很方便很简单，emacs 大量重要插件的开发者并不是程序员，比如 orgmode 的现任维护者，人家主业是搞材料科学的。emacs 的插件贡献者，有几个人有时间和精力去研究 rust 呢？
说一句比较现实的，你再怎么在这里安利 Zed ，现存的 Emacs 资深用户也不大可能会对其多看一眼，因为目前就没有什么特征是 Zed 独有的，那些十分看重性能、外观的用户，如果不是 Rust 的狂热教徒，早就跑去用生态更加完善的 VSCode 和 Neovim 了，所以你不如去这些社区安利一番。
原生支持 Emacs 键位吗? 键位完善程度怎么样?
有emacs版本的键位，完善与否不重要哦。因为你能自定义
zed估计没也没把emacs的用户当成目标群体吧？用emacs才几个用户啊？vscode、vim、notepad之类的用户才是它的目标群体。
感谢您诚挚的讨论，关于可扩展性，可以看看这篇文章。我理解 zed 团队是高度重视这方面的，只是现在的时机和发展阶段决定了可扩展性目前的样子，但能看的出来他们有丰富的经验，并且考虑到方方面面。至少从中你可以看到核心团队追求的目标是什么 https://zed.dev/blog/between-editors-and-ides
对于 emacs 用户来说，可拓展性肯定是最重要的，因为只要有可拓展性，用户可以自己搓出自己想要的任何东西。其他的东西都只是 nice to have。
因此既然 zed 在当下的开发重心并不是拓展性，而是其他的功能比如调试器，git 集成，针对特定编程语言的优化等。那么我只能说 zed is not there，zed 的 target audience 并不是 emacs 用户。
如果从一开始 zed 是一个底层用 rust，上层用 scheme 提供 scripting （甚至都别 scheme 了，就用 lua 都行，因为 lua 可以用几乎零开销的 lisp 方言 fennel）的软件架构，那我相信就会有大量的 emacs （以及用复杂配置的 vim 玩家） 玩家愿意来使用 zed，并来做 hack。
当然了，emacs 的 audience 太少了。作为一个商业公司如果在创业周期的初始推出了一个这样的 “属于 hacker 的玩具” 项目，那肯定是自取灭亡。
我只能说从我自己的使用体验来看，除了搜索等几个细节还要多多完善之外，zed的体验已经能满足日常需求。得益于zed内置的丰富文本表示和已有的任务系统，整体编辑体验良好，和终端的集成感觉浑然天成。zed对可扩展性上限的开拓虽然还有待时日，但对可扩展性的依赖其实并没有那么强。
没有支持中文的邮件客户端，代替不了 Emacs
我个人还是不能理解你坚持不懈在 emacs 论坛里推广 zed 是为了什么。
目前使用 emacs 的人应该都是能清晰自己的需求，而这些其他编辑器无法给予的。
非 Emacs 社区用户: Hope to support xxxxx
Emacs 社区用户: An unofficial xxxxx for Emacs
Emacs 一念神魔啊
为什么不重要？这很重要。如果原生有对 Emacs 键位的支持的话，官方在加各种新的功能或者命令的时候都会考虑到是否会出现键位冲突、如何更好地整合进键位中。
仅仅是能自定义键位，那我不如去用 VS Code 吧
试用过一次，在未经我同意的情况下就擅自下载npm包，污染我的环境，直接删了，永不录用
比较看好用Lua的Neovim.
感觉对emacs用户基本没什么吸引力, 速度快,开箱即用的编辑器已经很多了, 不差这一个, emacs用户更看重的应该还是扩展性, 其次才是速度快和开箱即用.
扩展性基本就等于内置脚本语言, 而这个好用的话, 还可以用在编辑器扩展以外的地方, 比如说我有时在代码注释里就直接写了elisp
//(find-file "c:/Windows/System32/drivers/etc/hosts")
//(* 3600 24 7)
哈哈，zed目前只专注于编辑功能
感觉你说的蛮有道理的哦，不过这个随着时间的推移会变化呢。半年之后不妨再看看。最近zed的变化我感觉进入爆发期了
过段时间再看看，目前还没有十足的竞争力