应该是 emacs -Q -l minimal-config.el
我第一次用 emacs -Q 还查询了好久怎么导入最小配置的elisp script。
顺便再建议一条哈。如果不是使用(package-install)装的包，而是通过(add-to-list 'load-path)装的包，要确保该包没有被字节码和native编译过。（我之前就遇到过这个坑，把源码更新了但是没有更新字节码，导致出现了预期不一致的行为）
1 个赞
这也难怪emacs的名声是对新手不友好了，居然开始讨论开嘲讽模式了。</元嘲讽>
我赞同LdBeth的观点，把这样的提问留在那里，没人回答对大家也没有什么影响。管理员也不需要觉得需要解决所有论坛上的问题；有心情就看看没心情就不看，这样不是都好了吗？
我甚至觉得移动分区都没有必要 —— 好像也没有那么多该删掉的帖子影响阅读啊？
4 个赞
这个论坛每天也没几个发帖的, 低质量问题又没多到爆吧的程度, 问题不大. 我感觉老手看到这种问题也不会花什么时间的, 一般直接看一眼就没兴趣了吧
2 个赞
很可惜，emacs新手不快速成长为老手，大多人最后就会放弃。
没有什么嘲讽的意思。
这个贴也不是说一定要执行，只是探讨怎么快速成长，提高大家交流质量。
如果新手不快速学会emacs -Q等一系列自我排查的方法，新手基本上就一直在粘贴复制起不来的循环中徘徊，最终还是放弃。
我也同意，没必要太过于上纲上线。。。毕竟就是一个论坛，好不容易有对Emacs 有兴趣的在这边问问，大家聊聊。
新手放不放弃不是我们需要担心的内容。 每个人都有从萌新走过来的阶段，Emacs 也未必就必须是所有萌新最后的终点。如果问个问题，管理员觉得问的太差，就直接加入 whatever 一种惩罚，这会不会有点过于严苛了？
不合适的问题，有人愿意提醒就提醒，觉得浪费时间的，也完全可以不去关注，扫一眼，也花不了多少时间。
我是觉得还是要有提问题的自由，即使不规范。
2 个赞
我觉得不好，这也是我为什么讨厌 stackoverflow
赞同，还是要对新手友好点。
对于不规范的发贴，老手忽略就好，最好可以设置不再提醒。其实新手也会愿意回答。
建议置顶一篇发贴指南，不要太长，几条要点就好。
我认为，论坛还是有序一点比较好。
或许现在越来越多人习惯用即时聊天工具沟通，就把说话碎片化的习惯带到了论坛。
即时聊天的时候你可以忽略，刷几屏就过去了，但是论坛不同，被忽略的主题随时会回到你的视线，例如出现在搜索结果中。
论坛很多人都属于古道热肠，见不得问题悬而未决（也可以算是一种焦虑吧？），即使帖子语焉不详，也会有人回复讨论。往往需要几个来回，才能明白在问什么。这也就是为什么说不规范发帖会浪费别人的时间。
提倡规范发帖，不仅是为了更好的解决问题，还希望发帖的时候多为别人考虑，考虑别人是不是能看懂，而不是想当然认为别人就应该懂我。
1 个赞
个人认为惩罚没有必要，不理就好，这样会带来更多的负面效应。
最麻烦的其实是还有人一张图就 at 你，问你怎么回事。这点上我必须说两句，绝对不是崇洋媚外。从我GitHub上接收到的issue来看，绝大多数老外提问都很详细，包括环境、重现步骤、自己做的尝试、预期以及现象等等，甚至有些还附带一些代码说明。不能说事无巨细吧，基本上看下就大概知道是不是问题、问题在哪儿。反观，很多从国内IP来提问的，直接两句话或者一张图报bug，说这个不对了，不好使了……后来我煞费苦心提供了bug和feature模板，结果直接删除。很多时候真的想不理直接关掉，但是为了保持对新手的“友好”和“热情”，都是尽量解决。从这点上我非常理解懒猫的苦恼，确实可能会耗费大量的时间和精力。
说回论坛上的帖子，从这几年的观察看也是类似的，很多提问没有任何上下文就说这里有问题那里有bug。坛子里大多数都是IT从业者吧，你真的遇到一个客户直接丢张图说你有问题的时候抓狂不？连测试人员提bug都有一套固定模板的，就是为了减少沟通成本。所以管理员也经过讨论，在文本框加上了提示，结果还是被很多人直接忽略。无奈呀 
在此再呼吁下，提问的时候换位思考下：如果有人问你问题，你希望对方提供什么信息才更有把握去解决？哪些是必要的基本信息？
1 个赞
这个完全赞同，尽量规范提问才更有价值。
「提问的技巧」 不少论坛都有, 但好像没有 「emacs -Q」技巧, 百度 「emacs -Q」基本找不到什么, google 好像也那样, 是不是还要个 「google emacs -Q 技巧」 有时不方便 番羽, 那就 「百度 emacs -Q 技巧」. 记得好像论坛 有过个 调查贴, 有不少 非IT人士(本人亦是), 用 org-mode 来码字的, 也有些 还是从 org-mode 认识到 emacs 的, 新手就不少, 如果要规范 「提问的技巧」, 相关的引导贴 与 发贴规则 也要定义配套好
例如: emacs 细节太多, 这个我也刚知道的, 那这个用法 「emacs -Q」 就帮不上了, 看来还要个「排错 技巧」
我认为论坛还是要和 issue tracker 分开来。
issue tracker，是软件作者出于责任感来应对用户需求，因为作者一个人不能预料所有用户使用場景，所以要有完整复现方法才能给人有效的方案。不想给別人 debug 的开源作者可以关 issue tracker，只收有能力自已改代码的用户提的 PR，也无可厚非。问题就在 issue 是要一个个解決的。
论坛这里虽然有求助的，但也有特点：
- 可以是开放问题
- 可以偏题，issue 里別人问 Spacemacs 问题你说 Doom 更好会被打死，但只要提问的人换了 Doom 问题解決不是好事？
- 稍有过类似问题的用户不用讲什么复现步驟，因为亲自遇到过同样的问题，或看到关键字就能猜个办法出来，一般猜错了也没事，換个人来就行。Stackoverflow 也有类似现象，最客观正确的回答从来不是题问者最后选择的
我觉得模板这样的太教条主义，适合 issue tracker，不适合论坛。
哪怕有人提了个显然不构成有效提问的，说他最后什么都没学到也太武斷了点。
issue tracker 是有很多伸手的，但在 issue tracker 里你的身份是作者，覺得不构成提问的 issue 烦是正常的。这里大家同是用户，我觉得同是用户的话没有什么立場斥责別人的。
当然我知道您在这里也会順帶解決自已写的包的求助，只要问题能有效解決在 issue tracker 和论坛都可，但是这两种心态还是要分开。
9 个赞
其实并非一定要怎么处罚，发帖也没有绝对的规范标准，有的问题就是无法重现。
主要还是希望每个发帖的人，都摒除掉自我中心的习惯。想要别人帮忙解决问题，先问自己有没有把问题说明白。
论坛虽然不是 issue tracker，但是也承担了解答问题的作用。不管是谁来解答问题，作为提问者都应该先释出诚意。
2 个赞
看来争议很大，就先这样吧，我也没有很好的办法。
论坛还是要维护的，要不质量起不来，当然大家都随意，那就靠群体力量影响了。
1 个赞
还是鼓励大家多发帖吧，没必要那么谨慎，但是发帖之前搜一下，不要重复就好了。了解世界的参差百态，激发自己的灵感。也不是每个问题都要有答案。
1 个赞
doom自己就提供了很好的sandbox功能来排错啊，和这里的emacs -Q是差不多的。
我个人也非常赞同提问应该尽自己所能规范。但我们最好不应该就不规范的提问给出惩罚。
如果要提供很详细地重现步骤和环境信息，本身是开发的思路，提问者可能并没有这个经验。
最近看到一些问题下面，有要求提问者按格式提问的，或者就是直接贴一个写如何提问的网页链接，观感非常不好。
我同意这个观点。提问者可能都没有程序开发经验，开发人员看来很简单的事，在他们看来可能并非如此。emacs -Q 也并非随手就能测的，通常要测的包会依赖非常多的其他包，要手动挨个加载，还是很费时间的。特别是如果不知道可能是哪里出问题的情况下。
另外，如果重现步骤和系统环境都加上，问题肯定会变得很长。我有时看别人的提问，就是想简单看一下自己是否遇到过这个情况，有就随手回复一下，根本不想看很长的重现步骤和系统环境信息。
4 个赞