我想逃离Emacs好几次了，第一次是VS Code，然后是Eclipse平台，期间还有一段时间，因为协同编程，用了一段时间IntelliJ，结果发现自己新上手IntelliJ，比旁边老手还会玩IntelliJ。
但是每次逃离，都又回到了Emacs。你说这是为啥了？可能就是其他平台，少了点Emacs的文本编辑的乐趣吧。
说实话，我内心的排序，如果不用Emacs，我可能会用Eclipse，其次再是其他开源编辑器如VS Code，在往后就是专有（proprietary）的IntelliJ平台，再往后其他专有编辑器IDE吧。
话说，我从实习到之后的三份正式工作，一直在使用Emacs作为主要的开发工具。没觉得自己效率比其他用IDE的同事低多少。我还经常抽空教同事如何使用IDE的一些高级功能。天天用IDE的人，对自己用的IDE又有多了解呢？
Eclipse不能和Emacs做对比吧，Eclipse是IDE，Emacs是文本编辑器。
比如：Eclipse、VS都是按工程划分的（通常是具体语言导向）
Emacs基本上没有工程的概念，所谓的projectile也是各种不同的项目文件混在一起编辑。
vscode 的架构无法避免内存泄露是 @manateelazycat 的一个说法，一时找不到原帖了，我自己是不懂啦。
同样很期待 lsp-mode/dap 的发展，成熟之后，我就可以删掉好几个 IDE 了 
我只用org-mode，目前还没找到更好的编辑器，所以就用着了，其他的功能基本不碰。
嗯，magit、org-mode、ranger都是很好的效率工具了！
对我来说，都是开发工具，有没有Project这个概念不重要。我都不是Projectile用户，也不喜欢Projectile。
另外我也不觉得Eclipse怎么特别语言导向了。我经常在Eclipse里面，Python、Java、Scala和SQL来回切换。
而且Emacs有没有Project这个概念，取决于你用什么工具了。我用ENSIME，里面就有原生的project概念。
ENSIME甚至会抱怨你的文件目录不符合规范。
[warn] You have .scala files in the base of your project. Such "script style" projects
[warn] are not supported by ENSIME. Move them into src/main/scala to get support.
一直get不到ranger的high点，倒是 dired 成为必须的工具
ranger的deer一退出就杀掉deer buffer。这个是真的麻烦
我也 get 不到，用起来怪怪的，不顺手。
看文件方便…小小的爽点
原始的 ranger 本就是個 vi 按鍵綁定的終端文件管理工具，vi 黨或雙修黨肯定就 get 得到了。
如今不离开，只因为org-mode。
同org mode
一直都在使用emacs写c++代码。当然还有magit，org。
因为很多自己emacs里实现的功, 想在其他编辑器里实现同样的功能, 要多花数倍的时间.
心流可以理解是专注力的意思吗？
做事情的专注是一个人的能力，没法理解怎么得到『常用的工具最好可以全键盘操作』这个结论。
之前对全键盘操作以前也很执拗，现在没有了。Emacs和Vim这种编辑习惯都是“上古时代”留下来的遗产，有优点和缺点。 另外，作为一个软件开发者，至少需要在浏览器和编辑器之间切换，Emacs这点还没做到也基本做不到（以前有想过是否有这样一个东西 
） 鼠标操作在所难免。
换成在mbp上，所有工具上的操作都可以在“全键盘”上高效完成。
现在觉得 用户体验好和专业、高效才是好的工具。
每个人对工具“能够做什么”和要的结果都不一样的，没有必要纠结这些。
反过来想，当初开始学Emacs, 没及时发现投入成本大于收益，太固执于现在的方案却不思考其他方法，才对Emacs有些抱怨。
編程畢竟大部分時間還是打字，只有少部分時間在用鼠標，能不用就不用是最吼的。
打程序不是CG相關，像3D建模和後期製作（我以前出於興趣稍有涉獵），調參數靠感覺，所以用鼠標方便控制就有優勢。而寫程序敲下去是一個字就是一個字，含糊不得的。
你覺得EAF或EXWM可以嗎？瀏覽網頁用vimium(a ff or chrome extension)可以排除90%的鼠標操作吧。
望賜教，只用過linux和windows
老實說，這種「理客中」式的古早味套話，讓人覺得有點Non-Constructive了
没有了解过这几个插件，后续可以了解下。Chrome能很好满足我看网页的需求
苹果笔记本的触控板可以了解一下，相当于鼠标。使用体验比上鼠标好非常多。
嗯嗯，谢谢建议，我最近一直在学如何做好结构化思考和表达
实话说， Visual Studio Code 在今天（2019 年）算得上是一个非常优秀的编辑器。相比于之前若干竞争者，如 Sublime Text、Atom 等，VScode 在微软加持下的社区生态让它走到了另一个档次。而且我有足够的理由相信，VScode 的开发者从 Emacs 这里参考了不少东西，比如 M-x，VScode 也有一个对应的很舒服的命令窗口。而且 VScode 几乎是我用过体验最好的基于 Electron 的桌面软件。（当然，体验再好，毕竟还是 Electron）
相比 IDE，这样的「专业编辑器」在面向大而杂的代码库时可能更有优势。而且 VScode 是足够开箱即用的。如果你有心查看那些 GitHub 上热门的面向最终用户的软件项目，你会发现这些项目的 README 文件几乎都傻瓜化到了一定程度，这是趋势。尽管这种趋势会给开发者带来额外压力，但相比于 Oracle 和其他公司的某些晦涩酸腐，这无疑是极大的进步。关键是，我自己的观察发现，即使如 VScode 一般配置简单的编辑器，许多人也几乎宁愿让自己不舒服也不去改动配置或者安装插件，也不清楚「工作区」究竟为何物。这类用户缺少的不是完成繁杂流程的耐心，而是「Do the Hacking」的好奇心。在任何时代，希望这类代表着大多数的用户能够自己从头定制 Emacs，都是不可能的，对吧？只不过在那个令人向往的上古年代，程序员本来就少，富于好奇心者比例更大而已。
回到正题。在命令行下启动的 Emacs，即使通过 Spacemacs 引入了三百多个包，占用的资源仍然远远少于基于 Web 的一众文本编辑器。我是开放 Web 的支持者，但我固执地认为 Electron 会夺走我的某种安全感。在很长一段时间里，我都是一个 Vim 用户。（即使到现在，一次性地编辑一些小文件，我还是会使用 Vim）为了让它看起来更像「我自己的编辑器」一点，我尝试去阅读 VimScript 的文档，但最后还是放弃了。那让我感觉不是在 2010 年代编程，而是操纵着一台被诅咒的上世纪遗留机械。尽管我对 Emacs Lisp 仍不入门，但往 M-x 中加入一个自定义命令，仍然是搜索一下，几行代码就能搞定的事情。对于 Hack 来讲，这感觉舒服多了。如果要我总结下的话，Vim 的插件也像配置，Emacs 的配置也像插件。
做不同的事情使用不同的编辑器太正常了。我写同一个项目的时候甚至也常在 Emacs、VScode 和 IDEA 系间换来换去。我没有写过 VScode 的插件，当我有了这种经历后，我想我能更通透地评价它。但我认为它是一个足够好的编辑器，对多数人来讲，这就是编辑体验的提升。但它取代不了某种畅快的体验。如果我有修炼到面对 Emacs/Spacemacs 这个庞然大物时目无全牛的那天，也许我会更加喜爱 Emacs。可惜，时间太宝贵了。