今天更新了 lsp-mode，然后 lsp 全部功能都挂了（mspyls后端）。开始的时候怀疑是最近更新系统造成的，于是重新 build mspyls，没有解决。然后 debug-on-error 发现 lsp-ui 的 byte-code 有问题，
File mode specification error: (void-variable lsp-ui-doc-winum-ignore) [9 times]
懒得寻找具体的问题，于是删掉 lsp-ui 重新安装，问题解决。之所以这么解决，是因为我之前被 byte code 咬到过好多次了，每次都是删掉重装或者重新 byte-compile 解决的。
于是发到这里给大家提个醒：单独升级 lsp-mode 可能会有问题，升级完后最好重新 byte-compile lsp-ui 这个包。
@seagle0128 这应该算个 bug 吧
Edit: 这个 bug 可能是今天早上更新 lsp-ui 造成的，下午又更新 lsp-mode，导致我误认为是 lsp-mode 的 bug，记忆真是最不可靠的 
你说的应该和这个有关 Symbol’s value as variable is void: lsp-ui-doc-winum-ignore · Issue #421 · emacs-lsp/lsp-ui · GitHub
在 fix: Place cl-eval-when after provide · emacs-lsp/lsp-ui@5ba04fd · GitHub 引入
issue里给的reproduce step很诡异，在我正常reproduce的时候没法重现，还没来得及看
是的，同一个问题。
这个问题可能是 spacemacs 带来的，我的怀疑基于以下观察：
重新安装 lsp-ui，问题解决。
但是下次重启 emacs 后问题又回来了。
看起来这是一个兼容性的 issue。你们都是使用 spacemacs 出现的问题吗？如果安装并启用了 winum-mode 还有有问题没？
spacemacs 应该是默认启用 winum 的
已经给了两点建议去修复这个bug，我自己还没时间测试，有心人可以去试一下
@seagle0128 不放后面，lsp-ui-peek require lsp-ui本身，然后lsp-ui在provide前面放一个(require 'lsp-ui)，这样byte-comp的时候会循环引用，然后出错。
看了下 fix: Place cl-eval-when after provide · emacs-lsp/lsp-ui@5ba04fd · GitHub ， 这个 commit 是 @cireu 提交的，引入了这个 regression issue。 有人已经指出这个跟安装顺序有关。先安装 winum 再安装 lsp-ui 就有问题。我想移动的这段代码是不是 compile 的时候也应该eval？
好像不是这样，我删除 lsp-ui 重新安装的时候没问题，这时 lsp-ui 是后安装的那个
那这样看来是 lsp-ui 的锅喽？
这人指出的是用 emacs -Q 重现的步骤：
我能肯定的是一定跟加载顺序有关。我没有参与这个 PR review，不大理解为什么一定要把这段代码挪到后面去，导致前面的代码加载出现未定义的问题。让 @cireu 看看吧。
确实，现在问题清晰了，不是 spacemacs 的问题，谢谢澄清
@cireu 没有复现是否是因为没有使用 byte-compile 后的 lsp-ui？这个 bug 应该和 compile 有关。
@MatthewZMD 应该也遇到这个问题了，
大家能否商量一下把这个解决了，太影响使用了
我也遇到这个问题了，你可以暂时先手动(require 'lsp-ui-doc)再(require 'lsp-ui)来规避这个问题。
Centaur 目前没有用 winum，所以我一直没注意这个 issue
这样看来，“少即是多”是真的
好奇怪，我的spacemacs昨天更新过之后就出问题了，c++/python的的lsp自动补全功能都不正常，终于看到有其他人也出现了
嗯，看到 comment了。我觉得solution 2 更优雅一点。还得看看还有没有其他类似的问题。
其实可能revert掉更好，感觉这个方法还是太hacky了。说实话这PR时间太久（去年7月的，最近才有人管）具体的细节我已经记不清楚了，不知道留着还会出什么问题
先revert回来吧，如果还想实现功能就发个新pr。