Emacs : aujourd'hui j'essaye lsp-mode

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.

3 « J'aime »

Peut être parce que je suis sous windows, j’adore pycharm, et ne veut même pas essayer vim…

J’entend que quand on est habitué à PyCharm ça doit être agréable, tout comme pour moi qui suis habitué à emacs c’est agréable, c’est culturel.

j’ai pas mal essayé PyCharm, et je vais continuer un peu cette année, ne serait-ce que pour pouvoir aider les élèves qui sont dessus, mais j’ai quelques problèmes avec qui me rebutent pour mon utilisation perso, ce qui me vient en tête :

  • ~9s pour s’ouvrir sur mon i9 (entre ~0s et 1s pour emacs en fonction de la config).
  • Le file picker graphique : même en utilisant ses raccourcis claviers, je le manipule beaucoup plus lentement qu’une complétion bash.
  • PyCharm alloue ~12GB de RAM au lancement là sur ma machine (1.5GB vraiment utilisée) contre 90MB emacs.
  • La moitié de mes raccourcis claviers (bash) habituels ne fonctionnnent pas dans l’émulateur de terminal de PyCharm (M-b, M-f, M-d, C-c, …).
  • Si par malheur j’ai le réflex de taper git commit --amend dans le terminal de PyCharm, vu que ma variable d’environnement EDITOR c’est emacs, il m’ouvre un emacs dans le terminal de PyCharm que je ne peux pas quitter (j’ai besoin de la touche alt, ou de C-x C-c, aucun ne fonctionne dans le terminal de PyCharm). (J’entend que c’est un problème d’utilisateur Emacs uniquement).
  • La “commande rapide” (shift shift) me joue des tours : par exemple je tape “shift shift term” je voit “Terminal” je suis content, mais le temps d’appyer sur entrée il trouve une meilleure proposition qu’il me met en haut à l’instant où j’appuie sur entrée…
  • L’indexation qui m’interdit de faire ça ou ça pendant qu’elle tourne (je n’ai plus le contexte en tête, je crois que j’essayais de modifier un paramètre d’exécution, je n’avais pas le droit tant que l’indexation tournait … j’ai du attendre …).
  • L’interface qui lance “tox” et qui essaye de parser ce que tox affiche pour me l’afficher joliment, c’est gentil, sauf que j’utilise tox -p all, et que PyCharm échoue à comprendre ce que tox écrit en mode parallèle. J’imagine que c’est pas compliqué à fix, mais à la base, pourquoi parser ça ? Ça cassera toutes les 2 ou 3 versions de tox, ça embête tout le monde à chaque fois, pourquoi ? Pour le présenter sous forme de jolie liste ? Pas convaincu. (Idem pour tout ce qui est présenté “graphiquement” par PyCharm, son intégration git par exemple, elle est mignonne pour un débutant, et j’imagine qu’un habitué ne le regarde même plus et n’utilise que les raccourcis clavier, mais comment je fais un git rebase -i HEAD^^ ?)

Pour certains problèmes j’ai ouvert des issues sur leur bug tracker, certains se fixent simplement (un bug de recherche dans l’outil d’edition de raccourcis clavier, …), mais pour certains autres je comprend que ce n’est pas possible de les corriger parce qu’il n’y aura pas de concensus, typiquement M-b dans l’émulateur de terminal, je veux qu’il soit donné au processus bash, pour que bash l’interprête comme sa documentation l’indique, mais certains utilisateurs ont peut être lié M-b à autre chose dans PyCharm et, même s’ils ont le focus sur le terminal, aimeraient que ça fasse ce pour quoi ils l’ont bindé… qui a raison ?

C’est certainement bien quand on y est habitués, typiquement les raccourcis bash, quand on ne les a jamais appris, ils ne doivent pas manquer. C’est donc probablement une forme de “culture”, j’en ai une autre, et la migration est trop dur pour moi.

Oui il faut absolument un éditeur à coté de Pycharm - j’utilise Notepad++ avec syntaxe highlighting pour lecture / modification rapide de fichiers et PyCharm pour un travail plus approfondi. Les 9 secondes sont vite regagnées pour moi par la navigation rapide du code, autocomletion sur la base de type annotations, etc mais avec une bonne connexion internet et un serveur lsp j’imagine qu’on récupère cette fonctionnalité, du moins pour tout ce qui est builtin.

Oui c’est frustrant … je crois que j’ai eu ça pour faire du conda install

Je n’ai pas trop d’habitudes hors PyCharm à désapprendre mais je tente VS Code aussi pour le coté multilingue et pour faire plaisir à mon chef d’informatique :slight_smile:

C’est tout à fait vrai, notre forme de culture et notre vécu, conditionne nos choix d’environnement.

pour ce qui est de la vitesse de toute façon je tape avec quatre doigts seulement …

C’est marrant plus je viens, et moins j’ai l’impression de connaitre de choses.
vous parlez de trucs qui me sont inconnus, genre bash complexe …

1 « J'aime »

Le serveur LSP tourne localement, pas besoin de connexion internet. Il est capable d’auto-complétion et de navigation aussi (find reference, etc…), pas uniquement sur ce qui est natif : tout ce qu’il trouve dans l’environnement.

Un “find-reference” sur, au pif, le premier fichier que je trouve, un “IntegrityError” (dans du Django) dan mon code m’ammène bien dans utils.py:36 de django.db.

C’est basé sur :

1 « J'aime »

Il y a t’il quelqu’un qui de temps en temps aurait besoins d’un dev gratos, pour bosser en binôme, vous profitez de moi et moi j’apprend de vous?

mdk,
est-ce que sur lsp-mode il y a une recherche profonde dans tous les fichiers pour retrouver un texte quelconque dans tous les fichiers du projet?

Ça pourrait me motiver à faire une conférence sur bash, même si c’est pas très Python.

Mais en deux mots j’utilise beaucoup les raccourcis bash, typiquement ceux de la section “commands for moving”, “Killing and Yanking”, … :

Ça nécessite vite d’avoir la touche Ctrl (les racourcis en C-qqch) et la touche Alt (les raccourcis en M-qqch) qui fonctionnent (Alt ne semble pas fonctionner dans le terminal de PyCharm).

Y’a des choses très sympa à faire, typiquement :

$ cat /etc/hosts C-a C-k  # Le C-a revient au début, le C-k "coupe" la ligne
$ cat /etc/passwd C-a C-k  # Pareil
$ C-y # retrouve /etc/password dans l'historique des trucs "coupés"
$ M-y # retrouve /etc/hosts dans l'historique des trucs "coupés"

L’historique des suppressions dans bash est en fait une pile, qu’on peut parcourir à l’envers, c’est souvent pratique. Cerise sur le gâteau : les raccourcis bash et les raccourcis emacs sont les mêmes.

Sur du close-source ? J’ignore mais ce serait une drôle d’idée.

Sur de l’open-source on a plein de projets, par exemple ici :

qui doivent avoir des issues ouvertes (PyDocTeur, potodo, pogrep, powrap, …), y’a de quoi faire. Après pour bosser “en binôme” tu peux essayer de passer aux soirées traudctions de l’AFPy tu trouveras bien un binôme pour t’aider. Et avec l’habitude le côté “asynchrone” de git fonctionne très bien : quelqu’un fait du code un jour, quelqu’un le relit un autre jour, et de jour en jour le code s’améliore jusqu’a être accepté, c’est comme travailler en binome, mais asynchrone.

comment on répond avec un encart?

ce que je trouve dans la participation à un github, c’est que ton code est accepté un jour, mais avant d’en arrivé la, tu n’as eu personne avec qui discuté des bonnes pratiques etc…
tu ne t’enrichi pas d’un dialogue, que tu pourrais en avoir en équipe, binôme ou autre.
je te dis ça parce que je suis totalement autodidacte, freelance, mais je ne rend pas compte des choses que je fais mail.

Je n’ai pas l’impression, pour ça j’utiliserai git grep :

Sur le projet Django par exemple, (~300k lignes de Python), chez moi, un git grep except.IntegrityError prend 0.03s.

Ouvrir tous les fichiers qui contiennent un except IntegrityError depuis bash revient à :

$ emacs $(git grep -l except.IntegrityError)

Tu peux surligner ce que tu veux citer avant de cliquer sur répondre.

Je ne suis pas d’accord : si c’est mal fait la PR n’est pas mergée. Il y a donc une discussion qui se met en place entre l’auteur et le mainteneur jusqu’à ce que ce soit propre.

Regarde par exemple : FIX: TypeError when one forgot to put its operation in a list. by JulienPalard · Pull Request #132 · stefankoegl/python-json-patch · GitHub

Je fais une PR, il trouve que mon if est louche, j’explique mon raisonnement, il le valide mais demande de rajouter un commentaire pour l’expliquer au prochain lecteur.

Après évidement tu auras des relecteurs plus “crus” que d’autres, moins patients que d’autres : eux aussi font ça sur leur temps libre limité. C’est pour ça que je te conseillais AFPy · GitHub : on sait qui y traîne, on peut même y parler français, en parler sur IRC, en parler pendant les meetups de traduction, …

Je viens d’essayer effectivement c’est très rapide, mais cela te renvoie une liste de tous les fichiers ou c’est utilisé.
l’avantage avec pycharm, c’est qu’il te liste les fichiers, mais en plus tu visualises directement la ligne ou le mot ou l’expression à tété trouvé. (Ctrl+Maj+F)
Un autre avantage, c’est qu’avec un Ctrl+B sur une fonction et tu remonte à sa source

Effectivement, je vais tester, merci pour ces précieux conseils.
maintenant le plus dur cela va être de me mettre aux pull requests ahhaha…

Le -l c’est explicitement pour dire que tu ne veux pas voir la ligne, c’est pratique pour n’avoir que des noms de fichiers, pour les donner à emacs. Mais sans le -l tu as bien les lignes :

Tu peux demander un peu de contexte aussi avec -A (after), -B (before) ou -C (contexte), typiquement avec -C3 tu as 3 lignes de contexte :

Et c’est une regex, donc tu peux exprimer des recherches un peu compelxe, comme "tout ce qui commence par (éventuellement du blanc) suivi de trois chevrons : git grep '^\s*>>>'.

Je vois, en fait c’est très clair du coup.
j’ai l’impression de ne pas être à l’aise quand je vois ça avec linux.