spacemacs->doom-emacs了,施工中

去年重新皈依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的话,也方便了很多,现在感觉是人手不够用

能写好 Lisp 的不多啊

我说怎么我要手动设为ivy--regex-plus,但是又好像在文档里看到默认就是这个呢,原来是spacemacs偷偷改了。。

spacemac应该有一个news板块更新新加入/改变的设置,比如像这样

https://github.com/casouri/lunarymacs/blob/master/news.org

突然发现顺序写反了,最后的更新在最下面

都在 git log 里了,沒有另外拎出來维护的必要。在 git log 里还能对应具体的代碼变化,为啥还要开倒车回手动時代。

git log在哪啊,好的话我也用了。

还是你说的就是普通的git log?

我是把会影响用户的改动拿出来单独放到news里,不是所有的commit都包括的。

我是觉得git log茫茫多,不好看出来哪个会影响到自己

针对 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总感觉有点奇怪。

直接从 git log 生成呗