用了挺久emacs的了，我感觉现在emacs最缺的是教人怎么用的流程性文章，而不仅仅是插件介绍文章。
比如我们学编程，刚开始都是学语法，刚把语法学完了写的东西，绝对是错误百出。最好的方式是有一个范例学习，可以学到整个代码的设计，开发的步骤，有了整个框架流程，具体的细节自己学起来也就容易了。
现在emacs世界也是类似，一个新手，唯一学习的方式就是去看别人的配置，但是学emacs和学编程不一样的地方在于，emacs本身是个编辑器，我去学elisp，配置细节就相当于是学编程的语法，就算我把centaur emacs的文档和源码都看了，不代表我用他进行python编程的时候就知道怎么用。
最好是由作者给出某种场景下的典型工作流，比如用centaur emacs进行python编程，怎么创建环境，补全操作，跳转操作，执行代码，调试代码，远程开发，怎么用是最高效的，这些只有作者知道，不是初学者学了几个快捷键就能用好。
之前也有人提过emacs的学习方式是遇到了问题再找解决方案。但是我的理解这个方式效率太低了，拿前面编程的例子来说，这样干就好像学编程不读别人的源码，学完了语法就开始做项目，这样虽然也能学会，但是花的时间也太长了。我也不是说不踩坑，但是前人已经把大坑都踩了，我们还非要把这些典型的坑再踩一遍着实没必要。
emacs本身已经是一个成熟的产品。新手用emacs如果不能发现他的好处，也用不长久。
总结：emacs世界需要一些类似下面这些标题的教程，作者在教程里以一个实际开发者的视角进行操作，这样新手操作几遍自然就会了，以后自己有需要再看配置改源码也不迟。一定要落在具体的场景里面。
“使用centaur emacs进行python开发的最佳实践”
“使用centuar emacs进行c++开发的最佳实践”
“使用chenbin’s emacs进行c++开发的最佳实践”
“使用chenbin’s emacs进行通用源码阅读的最佳实践”
8 个赞
Shynur
2
可以类比成 学习/玩 乐高，你不一定要做出什么真正有用的东西（你们当然可以），比如我没有特地寻找过OP提到的具体应用场景，主要是玩。只是这是高门槛的乐高，你得学会ELisp。
1 个赞
Roife
3
YouTube 上应该有不少此类视频
我觉得经验丰富的用户为新手提供这样的教程其实不错，类似 doom / spacemacs 也吸引来了很多新用户
org
4
从本质上讲，你要理解，它的使用是由社区驱动的，社区更多的是秀操作和出包供大家方便使用。如果真的去讲最佳实践，那恐怕也仅仅是一篇攻略。
所以我说的具体场景的最佳实践呀。比如“使用centar emacs开发python的最佳实践”。
猫哥这个就很好，我之前就看过 
希望其他配置的作者也能写些类似的资料
得看是什么角色把，如果是还没工作，把emacs当成玩具当然可以。但是如果对于一个已经工作的人来说，玩emacs不能带来任何好处，也坚持不下去
rua
9
很简单，你现在在工作中编程的时候要用到什么功能就在 emacs 中找到对应的
当然不了解编辑器的人可能根本不知道自己要的是什么功能 （比如我以前根本不知道 lsp
1 个赞
你说的这种“最佳实践”，本身就很容易过时。另外根本不存在什么“最佳实践”。
最好的使用方法就是看源码，自己配。
好，我拿实际的情况举个例子，假如你想使用centaur emacs。
如果你不知道有lsp的功能，该怎么去查找一个符号的定义？只能全局搜索或者用tag。
当你知道lsp可以跳转定义了，你不知道可以让跳转的位置变成一个拆分的窗口，每次都只能跳转过去看了再跳回来
当你知道可以拆分窗口之后，不知道可以只保留一个窗口，只能一个一个关。
如果centaur emacs的作者出一个教程，把他开发python项目的完整过程，怎么跳转，怎么查看定义，怎么调整窗口都详细地讲解之后，新手才知道该怎么操作。反之，centaur emacs里面很多配置，很多快捷键，看了源码之后你还是不知道该用哪个
很多人都说“没有最佳实践，每个人有合适自己的”。这句话大错特错，不同人的操作方式肯定有优劣之分，操作简单易用的方式肯定比操作复杂的更佳。
举个例子，你是新手，你自己写了个配置，用了一个月很熟悉了，你会说你的配置比chenbin/猫哥的配置更佳？
rua
13
是啊我就是 rg 用了一年（
后来觉得烦了采取更新自己的 workflow 才慢慢了解到 lsp，慢慢更新到现在自己的配置
这种最佳实践应该还没什么人写，或者说不是最佳实践而是分享自己的项目级的 workflow
2 个赞
问题是case太多了，根本不会存在单一配置在所有case上最优的情况。最后不还是每个人有一套自己用得最顺手的配置？
像chenbin/猫哥/centaur emacs他们的配置本身就是吸取了很多优点形成的。我们就算看了源码也还是不知道怎么用最合适。比如你去看spaceemacs的spc下的命令，还有一大堆其他操作。我们只能挨个去尝试才知道哪个好用。
如果作者直接基于一个场景写出怎么运用各种功能就能节省很多时间。
确实“不会存在单一配置在所有case上最优的情况”
但是发行版的作者可以列出他当前这个配置在某个场景下的最优情况啊，他列出来了就可以比较，有比较才有选择
是的，基于自己配置的workflow就是我前面提到的“最佳实践”，能让别人看到你使用自己的配置干一件事怎么干。不然看源码你只能看到他的配置有哪些，不能看到怎么运用。
在emacs里面，特别是管理窗口，buffer，跳转相关的功能初学者把握不好
这种文章很多的,例如,我很久以前写过一个简单的guide. https://github.com/redguardtoo/mastering-emacs-in-one-year-guide/blob/master/developer-guide-en.org
由于emacs插件的丰富,每个人都有自己的一套工作流,没法统一.
可以选一个guide,先把工作流跑起来,以后再慢慢优化.
我目前做javascript/typescript全栈开发, 我觉得自己目前的工作流的效率是很高的,博客文章教程都介绍过.不过工作流的个人特色未必能被很多习惯传统工作流的程序员接受.
举个例子,我使用ctags和grep进行代码浏览 这样做操作速度很快但牺牲了一些精确性,其他人如果喜欢vscode那种使用lsp的精确代码导航,就不会深入研究我基于ctags和grep发展的一些进阶技巧了.
1 个赞
看上去你想要的不是什么最佳实践，而是tutorial/guide，而且是一个个特定功能的介绍。
另外，你一直拿懒猫/chenbin他们的配置来举例说多好多好，那你说他俩的谁的最佳？
company-mode/corfu/auto-complete谁最好？helm/ivy/consult？lsp-mode/eglot/lsp-bridge/lspce？etags/ctags/uctags？el-got/straight/pie/…？use-package/leaf/setup？
1 个赞
lynnux
20
是的，没有统一的最佳实践，但可以把各人的配置列举展示在特定分类，emacswiki就是这样做的，不过有点老了，以前我初学的时候逛得挺多的