今天实在忍受不了pyls+lsp-mode 慢如龟速的补全，主要是针对pandas和numpy大型库的情况下，几乎无法使用。折腾了下 GitHub - emacs-lsp/lsp-python-ms: lsp-mode Microsoft's python language server ，使用了dotnet-sdk在macOS下成功编译，将vscode里的御用lsp搬过来，果然速度快多了。Microsoft 还是很良心的，居然成了开源届的一股清流。如果有相同困扰的童鞋可以试试这个了。
Update: 使用Centaur可以自动下载mspyls可执行包，不需要任何额外操作和配置了，支持Windows，macOS和Linux。
Update 2020-2-26: 自动下载功能已经合并进上游，lsp-python-ms默认启用该功能。lsp-python-ms-update-server可强制更新 mspyls。
lsp-python-ms确实很不错，而且装起来不是太麻烦
(use-package lsp-python-ms
:ensure nil
...)
我使用的时候发现 :ensure 那一项需要替换为 :demand 。不是很明白这么做的原因。
持续关注一下，之前用 lsp-python 因为不能自定义 flychecker 所以换回 PyCharm 了。大型的 Python 项目感觉还是 PyCharm 更加方便一些，反正我把 PyCharm 的按键方式改为了 Spacemacs 的按键，基本上和 Emacs 可以无痛切换。
不需要啊，:ensure 是确保package已下载，demand是让package开机load，没啥影响
原来是这样，之前情况是配置后还是会提示 no language server，需要添加一项demand
因为user-package设置了defer，这时候就需要demand强制加载。看看use-package-always-ensure变量就清楚了。
我刚刚在 macOS 10.12 试了一下，Microsoft.Python.LanguageServer 进程也起来了，但似乎 c/s 之间没有任何通信，打开调试信息 *mspyls* 缓冲是空的。
检查一下*lsp-log*这个buffer。
刚装完的时候貌似索引超久，然后一下显示lsp task canceled之类。
要多等一会儿。mspyls的策略是全部索引缓存起来，下次查询就快了。vscode里也是这样的。
这个 buffer 我之前也是看过的，除了打印一堆 search path 之外，并未提示异常。
那可太久了，我昨晚电脑没关，今天又在外面一天，傍晚五点多才回来。
不过的确是启动过程没有完成，我看到有人提 ISSUE 了：LSP never reach “started”?
我也报这个错，哎，同样的server在vscode上体验完美的简直爆炸，emacs里的体验是恶心的想死。咋差距那么大涅，难道这就是拿工资和不拿工资的差距 
我有个梦想：希望有一天emacs里python的lsp至少能比anaconda-mode 体验一样好 （感觉要做到vscode一样的体验，有点奢求）
其实在我的机器（一台MBP2015和一台Ubuntu服务器）上，lsp的效果比anaconda-mode好很多呢。起码补全的速度更快，而且lsp的补全还是模糊补全，anaconda-mode能否模糊补全我不太清楚。
我最晚的一次是在6月6号编译的mspyls，这个版本还是能够工作的。你不妨checkout到这之前的commit之后重新编译一下，看看能否解决你的问题。
Emacs 如果还是单线程就永远不可能了。
据我的观察，同样的 server，在 VSCode 下也是要转圈圈等待的，而且有的也很慢，要等很久才会补全，但是 vsc 不会阻塞用户操作。Emacs 就不同了，一旦请求发出去，在得到应答之前，用户动弹不得。
这个结论是如何得到的？lsp-mode用的是异步请求，在得到应答之前你的操作也不会被阻塞的吧
打开 lsp-log-io看看有什么记录。我这里没有问题，同样使用pandas和numpy速度很快。
我录了一小段视频，可以看看
lsp-mode现在是一些细节还有待雕琢，但是大部分功能是没有问题的。性能需要server和client共同改进。至于说阻塞UI的问题，我没有碰到过，lsp-mode是异步请求的，目前瓶颈是json parser，但在27中有明显改善。
这个不能算error，应该是一个info或者warning。出现后还是能正常使用。进程管理器中看看server进程是否还在索引工作（CPU占用高），等索引完了使用很顺畅。