In a previous post I showed how to get Palantir’s Python Language Server working together with Emacs and
In this post, we look at the brand new elephant in the room, Microsoft’s arguably far more powerful own Python Language Server, and how to integrate it with Emacs.
Since that previous post on Palantir’s language server, I’ve been using Emacs far more intensively for Python coding in tmux on remote machines with GPUs for deep learning.
The interactive programming possibilities of Emacs (remember that Lisp programmers have been doing this since the 60s) make for a great development solution: I can interact with my remotely running neural network code, start a long-running training, and then detach from the running tmux. When I re-attach the next morning (or the next), I can continue interactively experimenting with the still-running Python instance, for example further fine-tuning the training.
Palantir’s Python Language Server can become sluggish at times, so I switched back to elpy which is usually quite snappy, and affords an impressive suite of code intelligence features for such a small package.
However, the elpy RPC Python process has a tendency to die quite often, and even
M-x elpy-rpc-restart simply stops working at some point.
This, together with the fact that Microsoft’s own Python Language Server, the one used for both Visual Studio Code and also in Microsoft’s flagship Visual Studio IDE, has enjoyed and will continue to enjoy a far larger share of developer mindshare and attention, encouraged me to try and get this language server also working with Emacs.
This exercise cost many more hours than I was planning to spend, but everything seems to be working now.
/In this post, I will explain step-by-step how you too can enjoy the highly multi-threaded and actively developed Microsoft Python Language Server in your Emacs./
If you follow the steps set out further down in this blog post, your Emacs too could end up looking like the one showed in the following screenshots.
Read through all of the steps first, and then follow them carefully.
Let me know in the comments if anything should be further clarified.
If you don’t have this yet, download the .NET Core SDK for your platform from Microsoft’s .NET download site and install it.
Next, build the language server:
mkdir ~/build cd ~/build git clone https://github.com/Microsoft/python-language-server.git cd python-language-server/src/LanguageServer/Impl dotnet build -c Release
In Emacs, install the required and some optional packages using for example
lsp-mode– the main language server protocol package
lsp-ui– UI-related LSP extras, such as the sideline info, docs, flycheck, etc.
company-lsp– company-backend for LSP-based code completion.
find-file-in-project– we use a single function from here to determine the root directory of a project.
Microsoft’s Python Language Server likes to replace spaces in the documentation it returns with
Furthermore, there seems to be an additional misunderstanding between Emacs lsp-mode and the MS PyLS with regard to the interpretation of markdown and plaintext docstrings.
Both of these issues impact the blue documentation overlay, and should be worked around by editing the
lsp-ui-doc-extract function in
Right before the line with
((gethash "kind" contents) (gethash "value" contents)) ;; MarkupContent
add the following sexp:
;; cpbotha: with numpy functions, e.g. np.array for example, ;; kind=markdown and docs are in markdown, but in default ;; lsp-ui-20181031 this is rendered as plaintext see ;; https://microsoft.github.io/language-server-protocol/specification#markupcontent ;; not only that, MS PyLS turns all spaces into instances, ;; which we remove here this single additional cond clause fixes all ;; of this for hover ;; as if that was not enough: import pandas as pd - pandas is returned ;; with kind plaintext but contents markdown, whereas pd is returned ;; with kind markdown. fortunately, handling plaintext with the ;; markdown viewer still looks good, so here we are. ((member (gethash "kind" contents) '("markdown" "plaintext")) (replace-regexp-in-string " " " " (lsp-ui-doc--extract-marked-string contents)))
Add the following to your Emacs
init.el, and don’t forget to read the comments.
If you’re not yet using
use-package now would be a good time to upgrade.
(use-package lsp-mode :ensure t :config ;; change nil to 't to enable logging of packets between emacs and the LS ;; this was invaluable for debugging communication with the MS Python Language Server ;; and comparing this with what vs.code is doing (setq lsp-print-io nil) ;; lsp-ui gives us the blue documentation boxes and the sidebar info (use-package lsp-ui :ensure t :config (setq lsp-ui-sideline-ignore-duplicate t) (add-hook 'lsp-mode-hook 'lsp-ui-mode)) ;; make sure we have lsp-imenu everywhere we have LSP (require 'lsp-imenu) (add-hook 'lsp-after-open-hook 'lsp-enable-imenu) ;; install LSP company backend for LSP-driven completion (use-package company-lsp :ensure t :config (push 'company-lsp company-backends)) ;; dir containing Microsoft.Python.LanguageServer.dll (setq ms-pyls-dir (expand-file-name "~/build/python-language-server/output/bin/Release/")) ;; this gets called when we do lsp-describe-thing-at-point in lsp-methods.el ;; we remove all of the " " entities that MS PYLS adds ;; this is mostly harmless for other language servers (defun render-markup-content (kind content) (message kind) (replace-regexp-in-string " " " " content)) (setq lsp-render-markdown-markup-content #'render-markup-content) ;; it's crucial that we send the correct Python version to MS PYLS, else it returns no docs in many cases ;; furthermore, we send the current Python's (can be virtualenv) sys.path as searchPaths (defun get-python-ver-and-syspath (workspace-root) "return list with pyver-string and json-encoded list of python search paths." (let ((python (executable-find python-shell-interpreter)) (init "from __future__ import print_function; import sys; import json;") (ver "print(\"%s.%s\" % (sys.version_info, sys.version_info));") (sp (concat "sys.path.insert(0, '" workspace-root "'); print(json.dumps(sys.path))"))) (with-temp-buffer (call-process python nil t nil "-c" (concat init ver sp)) (subseq (split-string (buffer-string) "\n") 0 2)))) ;; I based most of this on the vs.code implementation: ;; https://github.com/Microsoft/vscode-python/blob/master/src/client/activation/languageServer/languageServer.ts#L219 ;; (it still took quite a while to get right, but here we are!) (defun ms-pyls-extra-init-params (workspace) (destructuring-bind (pyver pysyspath) (get-python-ver-and-syspath (lsp--workspace-root workspace)) `(:interpreter ( :properties ( :InterpreterPath ,(executable-find python-shell-interpreter) ;; this database dir will be created if required :DatabasePath ,(expand-file-name (concat ms-pyls-dir "db/")) :Version ,pyver)) ;; preferredFormat "markdown" or "plaintext" ;; experiment to find what works best -- over here mostly plaintext :displayOptions ( :preferredFormat "plaintext" :trimDocumentationLines :json-false :maxDocumentationLineLength 0 :trimDocumentationText :json-false :maxDocumentationTextLength 0) :searchPaths ,(json-read-from-string pysyspath)))) (lsp-define-stdio-client lsp-python "python" #'ffip-get-project-root-directory `("dotnet" ,(concat ms-pyls-dir "Microsoft.Python.LanguageServer.dll")) :extra-init-params #'ms-pyls-extra-init-params) ;; lsp-python-enable is created by macro above (add-hook 'python-mode-hook (lambda () (lsp-python-enable)))
Although I would have preferred to do this with the two
lsp-mode work-arounds, I am pretty satisfied with this setup.
With the number of users and development effort Microsoft’s Python Language Server has been enjoying and will probably continue to enjoy, it’s great knowing we can make use of this functionality in Emacs.
I am curious how well eglot, a smaller Emacs LSP package than lsp-mode, would do based on the integration above. (hint hint…)
Uploaded new version of emacs-lisp init code with two improvements:
- Thanks to reddit user cyanj for the
print_functionimport suggestion, and commenter Erik Hetzner below for the old-style string interpolation suggestion, this setup should now also work with Python 2, in addition to 3.
ms-pylsdatabase directory is now created as a subdirectory of the bindir.
So far, I have logged two issues, one with MS PyLS and one with lsp-mode, so that we can hopefully one day remove some of the work-arounds detailed above: