好的, 谢谢, 我一会看看你的配置, 感谢分享.
我主要觉得在 LSP 协议和服务端都实现很健全, VSCode/Vi 都用的很爽的时候, Emacs 这边确实各种因为作者的问题, 导致设计架构不好, 配置麻烦, 用户体验太差 (卡和各种报错).
用户需要的就是零配置的LSP Client插件, 一行 require 代码搞定所有事情, 最多提供几个选项可以自定义 mode-hook 和关闭高级功能.
我先忍一段时间吧, 如果这几个月忙完了, lsp-mode 和 eglot 还是让我各种崩溃的话, 我就自己写啦, 对这两个项目的代码质量和用户体验没法吐槽了.
是的，VSCode 用户体验确实很棒，这也是 Emacs 应该借鉴的地方。只是习惯了 Emacs 各种 keybinding，也受不了浏览器系编辑器巨大的内存占用，还是坚守这个老古董了。lsp-mode和eglot都在朝好的方向发展，假以时日应该能稳定和成熟起来。如果到时还是各种问题，我也愿意一起搞个新的出来 
更新了一下，好几个client都有问题，先迁移到eglot， 感觉细节差得还有点多，比如flymake 有些错误提示不会实时消除，不知道大家有没有遇到这样的问题
新的接口lsp 确实有些Client还有问题，我刚才就报了两个 issue。不过最近修复很快。
eglot是后来者，flymake 是同一个作者。不过总感觉质量和功能有些不爽。反正目前我还是用flycheck，尽管flymake内置并重写了。相应的，试用了一段eglot，感觉还是太简陋了，离自己想要的还是差很远，虽然目前还保留一个选项在Centaur Emacs中。eglot 唯一的优点就只剩配置简单了。
VSCode 我连续用了一个月, 也折腾了上百个插件, VSCode从通用性上已经可以秒杀所有IDE了, 主要界面也好看.
但是 VSCode 最终我没有坚持的主要有几点:
但是VSCode的LSP做的真的好, 真的好, 真的好, 说三遍, 体验Emacs这种渣渣 LSP 体验就想摔键盘.
flymake 的代码是写死的, 估计 eglot 和 flymake 都是同一个作者, 感情在那里, 不会删除的.
我写了一段代码可以解决你说的问题:
(dolist (hook (list
'js-mode-hook
'ruby-mode-hook
'python-mode-hook
'go-mode-hook
))
(add-hook hook '(lambda ()
(run-with-timer "5sec" nil (lambda () (flymake-mode -1)))
(eglot-ensure)
)))
毕竟 LSP 就是微软搞出来的，做 IDE 也是微软的强项。想想 Visual Studio 雄霸宇宙第一开发环境多少年了，至今无法超越。
这里要赞一赞lsp-mode的开发者 yyoncho 了， 最近有过一些交流，他也跟我提过一些需求，当然大多数是我提issue 或者idea给他。对问题反馈及时，而且有不少新的 idea，个人也在积极推进（比如跟我和 treemacs 的作者沟通加入支持 lsp 的功能）。他的目标之一就是打造一个接近于 VSCode 体验的 Emacs IDE，也有漂亮的 UI 和鼠标操作吸引到更多的开发者。你可以到这里去提交你想要的功能 https://github.com/emacs-lsp/lsp-mode/issues/515 。
这是他的一些 todo list：
其中最后一项，我主要是集成到doom-modeline。目前基本功能已经完工，以后有新的 API 会逐步增强。效果如下：
个人对于他的新作品 dap-mode 很感兴趣，这是除了 lsp之外，Microsoft VSCode 团队的又一大贡献，也是 Emacs 最缺失的功能之一：好用的debug。目前在lsp-java 中已经可用，如果稳定下来，相信其他语言也能很快跟进。
我主要吐槽代码质量和用户体验, 不管目标多么远大, 每个版本都要保证流程的可用性, 这样用户才会越来越支持.
当然, 我现在也没时间去做的更好了, 没有资格站着说话不腰疼.
我现在就忍了吧, 期待 lsp-mode 的作者做的更好吧.
确实是的，lsp-mode 和company-lsp 的配合使用体验还是差了一些，nvim 上的话，coc.nvim或者ncm2 和lsp 的配合真是比emacs好太多了，用过之后再来体验emacs 的lsp 感觉差距还是比较大的
看了看lsp，离开箱即用还有距离，比如没有自动(require 'lsp-client)，这个很奇怪，有什么原因吗？
看下這樣行不行？
(use-package lsp-mode
:commands lsp
:init
(setq lsp-auto-guess-root t) ; 我習慣自動選project root
;; (setq lsp-prefer-flymake t) ; 預設t。flymake替代flycheck
:config
(require 'lsp-clients) ; ocaml,css,python,bash,...
)
我不認爲需要做到完全開箱即用(比如*-mode-hook是侵入式的，需要顯式指明)。有些用戶可能根本不想用某些language servers，(require 'lsp-clients)可能會註冊一堆用不着的。
这个不是什么大问题，只不过我比较奇怪为什么不自动加载lsp-clients。如果用户想要别的client可以手动覆盖的吧？
我觉得可以 (require 'lsp-clients) 。这只会自动注册，并不会启动，还得加入-mode-hook。当然，如果能自动检测并自动加载就更好了。eglot, flycheck都不需要额外的多余配置。如果愿意你也可以自行配置。
我提交了一个 issue 在这里：[Enhancement] Automatic client detection · Issue #512 · emacs-lsp/lsp-mode · GitHub.
所以现在的问题是什么？我感觉自动检测的逻辑挺直接的啊。 搞一个类似
((major-mode . (candidate1 candidate2))
(major-mode . (cadidate1)))
的alist，启动的时候从candidate1开始试，在exec-path里找可执行文件（或者后端定义的时候说明了可执行文件路径？或者别的什么更精细的函数？我不清楚lsp具体是怎么搞的），找得到就用，找不到就试下一个，都没有就说没有。
vscode关键优势的就在于用的是js, electron, 本身这个社区就比较活跃，插件数就很多，而且很多web-based的软件可以直接移植到vscode里，比方说jupyter，在vscode里就跟打开个浏览器页面没差。
不过有一句说一句，搜索功能做的是真辣鸡。也没有人给它做个好点的搜索section。
这个package确实挺新颖的，功能也很强大。但不得不说，缺失的功能还很多，而且考虑到freeze问题，估计我2，3年内不会碰这个东西。
另外注意到這個有趣的issue Gripes about lsp-mode/elgot comparison · Issue #180 · joaotavora/eglot · GitHub Comparison lsp-mode/elgot is out-of-date/wrong/irrelevant “joaotavora大戰yyoncho (笑)” 吸引眼球的話要用個有趣的描述～
我也是这么建议的，类似flycheck一样。可能内部实现需要先重构才行。目前作少量配置也能工作了，好不错。
嗯，肯定还不成熟不完善，不过基本功能已经可用了，应该不用等两三年。有时间可以一起参与的。
我居然看完了所有内容！似乎两边吵起来了呀😄其实是设计思路不同吧。eglot作者比较推崇不依赖于其他包的简洁设计，缺点是功能相对弱些，至少UI不讨喜。想想看内置的flymake不如flycheck应该也是类似原因吧。多年前我还用flymake，自从flycheck诞生就放弃了。
刚又都试用了下，eglot也不好用啊，比不上vim的lsp客户端，更不用说vscode了。互相借鉴下发展一个成熟稳定的吧。