Avant, j’utilisais elpy, encore avant j’utilisais python-mode.el, cette année je teste PyCharm, mais les vieilles habitudes étant bien collées, aujourd’hui je teste lsp-mode avec jedi-language-server.
C’est quoi LSP !?
C’est un protocole, Language Server Protocol, qui permet de séparer l’éditeur (vim, vscode, emacs, …) de toute la plomberie ultra spécifique au langage (find-definition, …).
Il y a donc pour commencer un mode emacs pour parler avec des backends en LSP, le fameux lsp-mode
, et Il y a donc tout un tât de “serveurs” parlant en LSP :
Q: Mais alors un même “serveur” peut être utilisé pour plusieurs éditeurs ?
A: Exact ! C’est d’ailleurs le cas de jedi-language-server · PyPI qui fonctionne avec vim, emacs, vscode, … il s’en fout en fait, il implémente juste le protocole, c’est cool.
Et ça permet d’implémenter le “backend” dans le langage de son choix (je vous regarde, vous qui n’aimez pas trop trop beaucoup débugger du elisp, à commencer par moi).
jedi-language-server
Finalement c’est “juste” une abstraction de Jedi mais qui parle LSP, c’est “de la glue”. 1400 lignes de Python, 0 lignes de Lisp. C’est gentil à côté des 15k lignes de lisp d’Elpy.
Connaissant l’équation E=mc², Errors = (more code)², j’aime.
Et quoi ça donne ?
La popup bleue, c’est optionnel, c’est lsp-ui
, ça sort la docstring de la chose pointée (on en a de toute façons une ligne dans le minibuffer), elle se place un peu “où elle peut” (et c’est configurable).
La complétion fonctionne, le xref-find-definitions
aussi, ça surligne touts les usages d’un même nom (iter
dans ma capture d’écran par exemple).
Ça se configure assez simplement, je vous conseille d’avoir jedi-language-server
dans ~/.local/bin pour ne pas avoir à l’installer dans tous vos venvs.
Inconvénients
Sans LSP, pour ajouter “un langage reconnu par emacs” c’est M-x package-list-packages
, trouver le paquet, l’installer, terminé. Maintenant il faut en plus installer le “backend”, et le maintenir à jour.