git-gutter 踩坑记录,推荐大家使用 diff-hl

起因

写个了递归函数,打印出一万七千多行的 results。

#+begin_src python :results output
# 大写 65-91 小写 97-123
def test():
    for i in range(97, 123):
        for j in range(97, 123):
            for k in range(97,123):
                print("C-%s %s %s" %(chr(i), chr(j), chr(k)), end="\n")

test()
# print("Hello World!")
#+end_src

然后把 results 折叠成一行之后用 C-k 删除,发现每次都能把 Emacs 搞崩。

过程

尝试写了个最小配置,发现 Org Mode 完全 hold 的住这个小场面啊。

然后就挨个儿把挂在 org 上的 minor mode 关掉,凭直觉先关掉了提示操作的 goggles 和给中英文之间加空格的 pangu-spacing,发现没变化,然后就是 git-gutter,发现问题果然出在 git-gutter 身上。

为了确定,重启了三四次,虽然搞不明白,但能绝对肯定是 git-gutter 的问题了。

后续

发现问题之后马上去 GitHub 提 issue,写完 issue 才后知后觉的发现这是被收录在 emacsorphanage 里的。

正好此时网络连接问题把我在浏览器里写好的 issue 清空了,我也懒得再写第二遍了。

结论

马上换 diff-hl 重新走了一遍流程,完全没问题。推荐大家尽早弃用 git-gutter 保平安。 :crazy_face:

碎碎念

忘了之前是怎么在 diff-hl 和 git-gutter 中选择后者的了,可能是因为对 Sublime Text 莫名的好感?虽然也没怎么用过……

3 个赞

git-gutter 基本处于无人维护的状态,所以转到了 emacsorhanage。号称的live updating一直有问题,在我的环境中就没成功过。diff-hl 一直维护的不错,功能也强很多,Centaur Emacs中就集成并优化了,很稳定。最大的问题就是名字不太直观,之前讨论过多次,最后由于兼容性一直没有改。

平时我就写写 org-roam 笔记,开着 git-gutter 看见边栏上的一堆加减等号还挺有意思,稀里糊涂用着也就没在意它是被上游搁置了的插件。

如果不是遇到了这次的“极端”情况,还真没注意一个搞 UI 元素的插件居然能把 Emacs 卡死。

一般各种教程、文章、配置里也不会去写为什么选A不选B这种信息,真的只有自己碰到了才会给自己总结一下。

吸取经验教训,下次首选人气高开发活跃的插件来用 :stuck_out_tongue_closed_eyes: 不然连写 issue 的心情都没有。

对,尽量选用质量高、稳定、开发者活跃的插件,否则出了问题只能自己hack,还没法提交PR。 我的diff-hl效果如下,和流行的编辑器效果很像。terminal下就使用±号来显示。

image

1 个赞

你的 UI 调教得真好看 :heart_eyes:

我是眼高手低的那种,本来把配置文件拆成了六十多份文件想搞模块化,现在我都塞进 init,能默认就不动官方推荐配置 :rofl:

可以参考:

1 个赞

:laughing: 我的笔记里标记了大佬的配置,时不时能发现一些新东西。有的函数忘记在备注里加链接,甚至都忘了从哪里抄的了。

还在默认用 git-gutter。

哈哈哈 visual glitch 也比卡死 Emacs 强啊,真不知道用 Doom Emacs 的人啥时候能踩到和我一样的坑。

doom 默认用的是 git-gutter-fringe,不是git-gutter。当然,git-gutter-fringe 也进了emacsorphanage :joy:

我抄了你的配制发现如果把那个高亮变窄会有点卡,是啥问题 (doom emacs 29, mac)

哈哈哈,写文档我喜欢关掉所有 git 相关元素,感觉文档不用怎么控制每个版本增删之类的,红红绿绿的分散注意力 :rofl: