能否多讲几点flymake 和flycheck 的对比？
我昨天阅读了这个blog，里面提及在Emacs27以后，两者其实差别不大。
时间角度看，Flymake 是在 Emacs 22.1 (2007) 并入 Emacs 的，Flycheck 大概 2014 年开发的。
世纪初的软硬件条件，跟现在没法比，软件开发方式估计也有不小的差别。
现在的eglot几乎就是零配置。
eglot几乎零配置我觉得是因为大部分lsp server基本不需要配置，server之外eglot又没有提供可配置的东西。碰到jdtls这种某些情况下有配置需要的，eglot就不太方便了。
4 个赞
jdtls是它提供了许多lsp协议标准之外的功能。eglot作者本人不想支持lsp协议之外的功能。lspmode是有人专人维护，去实现了这些额外的功能。
eglot本身基本上是零配置的，当然它本身能够配置的东西也非常少。eglot的上手体验无疑是比lspmode好的。
lspmode第一次开启lsp还会弹出个框问你要如何选择workspace还是root directory之类的东西，要是没接触过lsp，期待开箱即用的，比如我第一次开lspmode，肯定就直接麻了的。eglot的话就是根据project.el来直接决定，如果是在git文件夹底下，就直接开启了，不需要额外的配置。
1 个赞
这个包是很多flymake 的后端集合，你可以看看
1 个赞
我个人更喜欢可配置的，单看这方面，我更倾向于lsp mode，虽然配置项有点过多吧，但至少给了我选择。
当然这个是个人喜好问题，提出来也只是给一些不熟悉的人提供一个比较两者的角度。日常用的话我当然选lspce了，哈哈
2 个赞
功能差不多。
flycheck默认支持的语言更多，开箱即用做得更好。
flymake默认支持的少，不支持的语言需要自己配置。默认支持的语言配置比较古老，可能指定的命令行程序linter已是非主流.
虽然flycheck更流行，但我用flymake,因为flycheck模块化不好，所有代码都放在一个文件 （ https://github.com/flycheck/flycheck/blob/master/flycheck.el ），有点过重。
如果熟悉命令行程序和Lisp的话，可以把flymake打造得更轻量级一点。例如，只在保存当前buffer时启动检查， flymake 设置为“保存时检查”后遇到的问题：需要重复保存两次才能提示正确的检查结果
flymake定制可以从flymake-proc-allowed-file-name-masks, flymake-proc-err-line-patterns看起。
有一个flymake的优化技巧值得一提， 官方的例子都是把当前buffer复制到一个临时文件。如果采用了之前提到的保存时才启动linter检查的方案，那么临时文件就没有必要了，这样实现简单，性能也更好。这里是给eslint写的实现， https://github.com/redguardtoo/lazyflymake/blob/master/lazyflymake-eslint.el
7 个赞
多谢回复，受益良多！！！
日常用golang比较多, 我需要给golang的server配置几个参数
早期flymake功能太弱, 比flycheck差太远, 后来(好像三四年前左右)大改了一次, 理论上基本追平了flycheck, 但是此时flycheck已经非常完善了, 特别是有很多后端
没人讨论这个？
flymake，flycheck，我全都要（握拳）
1 个赞
主要还是看关系……关系户可以直接进主线，不是关系户就得先进 GNU ELPA 观察。不过 eglot 也算是在 GNU ELPA 观察很久了。但是像 ivy 这种也是 GNU ELPA 观察很久的，也没进
明明可以贴链接却截图，不是好习惯。
我前边回贴的意思是，希望你在 1 楼把消息来源补上，不要让每个看贴的人都去搜索一遍。
1 个赞
好的。zsbd
也不算lsp之外的功能，java，deno都有额外的协议，主要是有些语言的库实现不是以源文件的形式存在的，而是存在于语言虚拟机中，查找定义就要先解析内容再生成临时文件才能查看定义。
这些不做，像java和deno这种语言就完全没法查看函数定义了。
其实我觉得eglot合并入主分支是负担，邮件列表讨论问题太麻烦了。
那些开发者估计也习惯了，这么多年都过来了，普通用户提问题确实麻烦了。
不过内置之后倒是方便了用户，不需要单独安装了。
行动在哪里？