FlyCheck 38 发布

好像是换人维护之后第一次发新版。

以及 Eglot 与 Flycheck 之争最后是 Flycheck 妥协去支持 Eglot 了。

1 个赞

作者有寫文章介紹: Flycheck 38: Might & Magic

我覺得最大的提升是 Native LSP support,性能應該會好不少。

以及 Flycheck versus Flymake

不過我以為現在大家都用 LLM 生成代碼了,還有人在意 Flycheck 嗎 :joy:

1 个赞

Flycheck汇报的信息可以反馈给LLM,作为harness的一部分,让LLM迭代改进代码. 这个过程可以通过emacs mcp让LLM调用来做到自动完成.

还是eglot设计太简陋导致的。flycheck的框架去调lsp api也就封装下接口的事情,但要额外做一个lsp server管理的工作。这样的管理本就应该eglot去做,但是eglot自己都没做好。

3 个赞

直接讓 LLM 自己去調用工具校驗,获取信息就好了,我覺很沒必要經過 Emacs。

Flycheck 的信息是給人看的,而不是給 LLM 設計的,不過我想還是有人會用 Emacs 寫點代碼。

2 个赞

flycheck / flymake是各种语言lint的统一接口,配置好了对人和对LLM都可以用,给人看有价值的信息对AI也是有用的。直接让LLM用的话,我不确定它是否能对任意语言都能找到合适的工具,比如elisp code的各种规范,包括check-doc,在melpa上发布package还是需要遵守的。AI可以很容易处理这些。而且, flycheck可以配置,让LLM把代码改成符合自己规定的形式。

我并不是说Flycheck是核心 它只是很容易可以拿到并复用的一层 毕竟它经历了多年开发验证 harness的其他部分比如test等的反馈更重要

这就是我今天在另一个贴子里说的:

现在这个时代如果有什么必须得通过Emacs来给agent context,我觉得已经不合适了。。。Emacs这么多年的功夫,这么花里胡哨的功能,面向使用对象始终是人,但是在agent时代人就是那个bottleneck

4 个赞

agent面向的使用对象同样是人

哈哈哈,那你观念还在2025年的agent

1 个赞

我最开始就是用的 flycheck 后面随波逐流转 flymake 了

上面的人都这么乐观的吗?现在 ai 编码直接把 emacs 都干没了?为啥我反倒觉得 ai 不仅没有替代 emacs, 反而让 emacs 使用更舒服了,更不想离开了。毕竟要啥就能改啥

比起 emacs,其他垃圾编辑器更容易干没

毕竟 emacs 还是太强大了

agent 现在主要是一个 cli 吧,本质是编辑器无关的


目前人工智能的发展完全是资本家主导,没有什么社区支持,模型或者代理几乎都是黑箱,要在 emacs 中复刻 agent cli 的效果还是比较困难(纯猜测,没有做过比较)。不过尝试始终是好事,多样性始终是好事

以前一直用的 flycheck,后来因为flycheck不支持eglot,转到了 flymake. 其实flymake 后来也慢慢赶上来了。现在已经用习惯了 flymake,没什么动力再回flycheck了。

感觉flycheck的主要优点是在不开 lsp时支持更多的后端,而且实现后端更加容易。

最近试用了2天 flycheck,感觉 flycheck 38 新加的 global-flycheck-annotate-mode 很干扰输入,刚刚输入几个字母就马上提示一堆信息。这个可能和我使用自动保存有关,诊断的太频繁了。

1 个赞

楼上不少人看起来对agent的能力比较乐观 觉得不太需要审查和干预AI的设计和写出来的代码 因为光靠个CLI实在很难干这事 而且CLI不能为提交的代码负责任 是否接受提交AI生成的代码 需要责任人的判断力

我自己最近的体会是 如果完全让AI来写代码 自己不怎么读和修改 这对程序员的判断力有很高的要求 AI可能建议一些不靠谱或者over design的code change 就是opus 5.0也常有 人不太深入思考就接受了 几秒内代码就写出来提交了 这样事情发生多了 代码库就成了一个垃圾场 后来的人或者AI都不敢删掉其中的以前加进去的东西 这种设计上的问题 靠加各种测试不能解决 光靠CLI也很难审查

程序员对代码库了解的越少 代码库越复杂 就越难有好的判断力 久了以后就听天由命吧

我的观点主要是基于“emacs 不仅仅是编辑器”

至于你提到的这个,部分赞同。说机器人的存续和发展依赖于人类,在归根结底的意义上永远是对的。正如从归根结底的意义上,经济是社会演变的决定性因素一样。

不过具体到项目或者编码是否能做到完全无人,我觉得可能还是有很强的可变性。这很大程度上取决于项目的目的,使用场景,以及对代码质量本身的要求。做开发,本质上和别的手艺人无异,其实是有很强的伸缩性的

举例说,我在为资本家编写代码,我在为工资编写代码,我编写的东西是我自己都不在乎的,本质上我生产出来的东西不是我利益相关的,很多时候还是负相关的(生产得越多,我越受到剥削),那么我就没必要自作多情纠结它的质量。能用就行,下次机器人能继续帮我改就行。

或者,本来应用场景对质量要求就低,那么也是同样的道理。

只要降低要求,不怕出错,能承担成本,就能做到无人参与。考虑到大多数实际的开发场景都是做一些普通的,非生命攸关的功能,大部分的编码绝对可以在足够的机器智能的情况下做到完全无人化

这种时候,上面的人在“emacs 只是一个编辑器”的这种前提下,作出的结论,就是正确的了

Emacs是随身携带的可以改造瑞士军刀 在各种环境里 各种开发问题上都能发挥作用 AI大幅度降低了它的改造和适应环境的成本 对于习惯了elisp的人是更有价值的

因此 我不认为有了AI emacs就失去了价值 同样的 我也不认为有了AI 软件就失去了价值 两者是一个道理 AI还没强大到神灵一般的地步 那也许只是人的崇拜心理

作为手艺人 一般会对自己的工作成果质量有自我要求 对于拿工资的工作应该要求还要更高一些 因为那要担更大的责任

2 个赞

可以看出您是一位负责任的手艺人