去年重新皈依emacs是因爲發現閱讀代碼emacs UI體驗比neovim好很多。spacemacs作爲starter確實不錯。但最近接二連三惱人的預設讓我浪費了很多心力調查原因，找到一個惱人功能，比添加一個實用功能，很可能更難。發現自己取消這些惱人設置浪費了太多代碼了，所以決定遷移到doom-emacs，希望是一段好的旅程。
spacemacs//c-toggle-auto-newline
emove c-c+±enable-c++11
默認(defvar ivy-re-builders-alist '((t . ivy--regex-plus)) ...被改成ivy--regex-ignore-order了。而我是堅信subsequence filtering加空格分割搜索串的
禁用cmake-ide rtags ycmd ggtags也費了我不少工夫。 (setq c-c++-excluded-packages '(company-ycmd ycmd))
週末發現selected-window的mode line顯示不出來了。
之前mode-line裏的(projectile-project-name)沒有緩存導致嚴重性能問題
正在努力建設我的~/.config/doom/
doom-emacs用的 shackle evil-collection這些包似乎更加優越一些？求survival guide…比如：
- 常用的窗口管理
-
helpful-mode用哪些鍵
- lisp編輯配置
2 个赞
doom已经不用shackle了 现在是基于display-buffer-alist 的
helpful-mode 应该map到emacs-mode的+lookup/documentation 就行
窗口管理我觉得doom自带的popup system挺好的 好好读一下 popup module的code documentation就行
一切擋路的鍵都讓賢~
(map!
;; localleader
:m "," nil
;; Override default :n [b [w
:nm "[" #'lispyville-previous-opening
:nm "]" #'lispyville-next-closing
;; Override default :n < >
:nm "<" #'lispyville-next-opening
:nm ">" #'lispyville-previous-closing
)
(define-inline +my/prefix-M-x (prefix)
(inline-quote
(lambda () (interactive)
(setq unread-command-events (string-to-list ,prefix))
(call-interactively #'execute-extended-command))))
讲道理我现在觉得lispy还是insert mode好用。。lispyville看上去很美 用起来总有点问题
doom-emacs 不是另外一个 spacemacs 吗？
也曾用过一段时间 spacemacs，感觉就像是每天都有无数人在背后捅娄子（当然也有补娄子）。。其实还是因为自己有一双管不住要更新的手。
2 个赞
現在的感受是捅婁子太多而作者根本不管補簍子的PR…我一直以來都很安分地只專注好好配置c++的不玩這些工具的，+lang/c-c++亂得都不讓我好好玩了。只能放棄
我已經堆積了很多不被理睬的PR了
我很好奇这种大的project，是如何申请加入contributors呢？如果能有权限去管理pr的话，也方便了很多，现在感觉是人手不够用
我说怎么我要手动设为ivy--regex-plus，但是又好像在文档里看到默认就是这个呢，原来是spacemacs偷偷改了。。
LdBeth
12
都在 git log 里了，沒有另外拎出來维护的必要。在 git log 里还能对应具体的代碼变化，为啥还要开倒车回手动時代。
git log在哪啊，好的话我也用了。
还是你说的就是普通的git log？
我是把会影响用户的改动拿出来单独放到news里，不是所有的commit都包括的。
我是觉得git log茫茫多，不好看出来哪个会影响到自己
LdBeth
14
针对 Spacemacs 而言，只要影响用户的改动，看 dotspacemacs 文件和 layer 具体的 diff 和 log 就可以了。就算拿出来单独放到news里，用戶也不见得全用的到。
git log 用文件名过滤：
git log --follow '*.wmv'
明明 git 这麼多功能，结果都當云盘用。
你说的有道理，应该定一个convention，所有会影响到用户设置的commit都用关键词开头，比如change-default: some commit head
这样直接看log就可以了，也可以自动生成只包含change-default的log
进一步想的话，git或者github应该出一个标签系统，类似现在github的isuue tag
git已经有tag了，不过是时间线tag，不是类型tag
1 个赞
完全可以在一个独立的文件里记录git commit hash和tag的对应
然后contributor可以共享这个文件 大家都能添加标签
最后可以用function parse tag 然后得到对应的git commit hash， 然后从git获取log message
说了这么多 好像org mode的tag系统很适合做这个事啊 有一个function自动吧commit 导出成org 文件就可以了
类似
<tag1><tag2>commit header
commit body
导出到
* [[link to commit][3l3h2]] commit header :tag1:tag2:
commit body
?
等等，能不能直接用org header的格式写commit header？ 这样导出来直接就是org 文档，连parse 都不用，
或者可以在commit header省略开头的星号，parse的时候加
commit的时候其实不写tag也ok tag全部存在org file里就行了
1 个赞
嗯，这样修改比在commit里面方便很多。不过两套（基本）一样的log总感觉有点奇怪。