eglot几乎零配置我觉得是因为大部分lsp server基本不需要配置,server之外eglot又没有提供可配置的东西。碰到jdtls这种某些情况下有配置需要的,eglot就不太方便了。
jdtls是它提供了许多lsp协议标准之外的功能。eglot作者本人不想支持lsp协议之外的功能。lspmode是有人专人维护,去实现了这些额外的功能。
eglot本身基本上是零配置的,当然它本身能够配置的东西也非常少。eglot的上手体验无疑是比lspmode好的。
lspmode第一次开启lsp还会弹出个框问你要如何选择workspace还是root directory之类的东西,要是没接触过lsp,期待开箱即用的,比如我第一次开lspmode,肯定就直接麻了的。eglot的话就是根据project.el来直接决定,如果是在git文件夹底下,就直接开启了,不需要额外的配置。
这个包是很多flymake 的后端集合,你可以看看
我个人更喜欢可配置的,单看这方面,我更倾向于lsp mode,虽然配置项有点过多吧,但至少给了我选择。
当然这个是个人喜好问题,提出来也只是给一些不熟悉的人提供一个比较两者的角度。日常用的话我当然选lspce了,哈哈
功能差不多。
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
多谢回复,受益良多!!!
日常用golang比较多, 我需要给golang的server配置几个参数
早期flymake功能太弱, 比flycheck差太远, 后来(好像三四年前左右)大改了一次, 理论上基本追平了flycheck, 但是此时flycheck已经非常完善了, 特别是有很多后端
没人讨论这个?
flymake,flycheck,我全都要(握拳)
主要还是看关系……关系户可以直接进主线,不是关系户就得先进 GNU ELPA 观察。不过 eglot 也算是在 GNU ELPA 观察很久了。但是像 ivy 这种也是 GNU ELPA 观察很久的,也没进
明明可以贴链接却截图,不是好习惯。
我前边回贴的意思是,希望你在 1 楼把消息来源补上,不要让每个看贴的人都去搜索一遍。
好的。zsbd
也不算lsp之外的功能,java,deno都有额外的协议,主要是有些语言的库实现不是以源文件的形式存在的,而是存在于语言虚拟机中,查找定义就要先解析内容再生成临时文件才能查看定义。
这些不做,像java和deno这种语言就完全没法查看函数定义了。
其实我觉得eglot合并入主分支是负担,邮件列表讨论问题太麻烦了。
那些开发者估计也习惯了,这么多年都过来了,普通用户提问题确实麻烦了。
不过内置之后倒是方便了用户,不需要单独安装了。
行动在哪里?
好了 zsbd
我日常使用的就是Golang,什么都不用配置。
非常赞同这一点。