开放性议题:各位Emacs党为什么没跳出神之编辑器这个坑

我想逃离Emacs好几次了,第一次是VS Code,然后是Eclipse平台,期间还有一段时间,因为协同编程,用了一段时间IntelliJ,结果发现自己新上手IntelliJ,比旁边老手还会玩IntelliJ。

但是每次逃离,都又回到了Emacs。你说这是为啥了?可能就是其他平台,少了点Emacs的文本编辑的乐趣吧。

说实话,我内心的排序,如果不用Emacs,我可能会用Eclipse,其次再是其他开源编辑器如VS Code,在往后就是专有(proprietary)的IntelliJ平台,再往后其他专有编辑器IDE吧。

话说,我从实习到之后的三份正式工作,一直在使用Emacs作为主要的开发工具。没觉得自己效率比其他用IDE的同事低多少。我还经常抽空教同事如何使用IDE的一些高级功能。天天用IDE的人,对自己用的IDE又有多了解呢?

4 个赞

Eclipse不能和Emacs做对比吧,Eclipse是IDE,Emacs是文本编辑器。

比如:Eclipse、VS都是按工程划分的(通常是具体语言导向)

Emacs基本上没有工程的概念,所谓的projectile也是各种不同的项目文件混在一起编辑。

vscode 的架构无法避免内存泄露是 @manateelazycat 的一个说法,一时找不到原帖了,我自己是不懂啦。

同样很期待 lsp-mode/dap 的发展,成熟之后,我就可以删掉好几个 IDE 了 :smile:

3 个赞

我只用org-mode,目前还没找到更好的编辑器,所以就用着了,其他的功能基本不碰。

2 个赞

嗯,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 得到了。

2 个赞

如今不离开,只因为org-mode。

2 个赞

同org mode

一直都在使用emacs写c++代码。当然还有magit,org。

因为很多自己emacs里实现的功, 想在其他编辑器里实现同样的功能, 要多花数倍的时间.

1 个赞

心流可以理解是专注力的意思吗?

做事情的专注是一个人的能力,没法理解怎么得到『常用的工具最好可以全键盘操作』这个结论。

之前对全键盘操作以前也很执拗,现在没有了。Emacs和Vim这种编辑习惯都是“上古时代”留下来的遗产,有优点和缺点。 另外,作为一个软件开发者,至少需要在浏览器和编辑器之间切换,Emacs这点还没做到也基本做不到(以前有想过是否有这样一个东西 :slight_smile: ) 鼠标操作在所难免。

换成在mbp上,所有工具上的操作都可以在“全键盘”上高效完成。

现在觉得 用户体验好和专业、高效才是好的工具。

每个人对工具“能够做什么”和要的结果都不一样的,没有必要纠结这些。

反过来想,当初开始学Emacs, 没及时发现投入成本大于收益,太固执于现在的方案却不思考其他方法,才对Emacs有些抱怨。

1 个赞

編程畢竟大部分時間還是打字,只有少部分時間在用鼠標,能不用就不用是最吼的。

打程序不是CG相關,像3D建模和後期製作(我以前出於興趣稍有涉獵),調參數靠感覺,所以用鼠標方便控制就有優勢。而寫程序敲下去是一個字就是一個字,含糊不得的。

你覺得EAF或EXWM可以嗎?瀏覽網頁用vimium(a ff or chrome extension)可以排除90%的鼠標操作吧。

望賜教,只用過linux和windows

老實說,這種「理客中」式的古早味套話,讓人覺得有點Non-Constructive了

1 个赞

没有了解过这几个插件,后续可以了解下。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。可惜,时间太宝贵了。

11 个赞