Passer de lsp-mode à Eglot dans GNU Emacs

 (utcc.utoronto.ca)
1 points par GN⁺ 2026-05-13 | 2 commentaires | Partager sur WhatsApp
  • Retour d’expérience concret sur le remplacement complet d’un environnement LSP basé sur lsp-mode qui fonctionnait bien par Eglot, la solution LSP intégrée à GNU Emacs
  • Par rapport à lsp-mode, Eglot offre une interface minimaliste et discrète, et s’intègre avec des paquets externes comme Corfu, Consult et Flycheck via les API standard d’Emacs Lisp
  • L’essentiel du travail de transition a porté non pas sur la configuration d’Eglot lui-même, mais sur l’exploration, le réglage et les tâtonnements autour des paquets auxiliaires
  • Selon le serveur LSP, comme pylsp ou gopls, la méthode de configuration du workspace diffère, et pour une configuration au niveau du projet, il faut utiliser .dir-locals.el
  • Puisqu’Eglot est intégré à GNU Emacs, il peut valoir la peine, à long terme, d’envisager la transition si vous utilisez Emacs

Motivation du changement et impression générale

  • Sans raison particulièrement forte, l’auteur a commencé à tester Eglot après être passé à Corfu, puis a poursuivi la migration
  • lsp-mode + lsp-ui proposent une interface chargée (busy), avec beaucoup d’informations affichées en même temps ; le passage visait une expérience LSP plus calme
  • Eglot est plus minimaliste que lsp-mode, mais il faut compléter les fonctionnalités avec des paquets supplémentaires pour obtenir une expérience complète
  • Au final, le résultat est satisfaisant, et dans les modes Go et Python, des fonctions comme l’autocomplétion sur préfixe commun marchent mieux
  • Il aurait aussi été possible d’ajuster davantage la configuration de lsp-ui, mais le passage à Eglot a résolu tous les problèmes d’un coup

Intégration des paquets auxiliaires

  • Corfu fonctionne pour l’autocomplétion sans configuration supplémentaire, avec la configuration existante
  • Pour obtenir un aperçu de style lsp-ui dans les références croisées, il faut connecter le paquet consult et définir xref-show-xrefs-function sur consult-xref
  • Après hésitation entre Flycheck et Flymake, le choix s’est porté sur Flycheck
    • Flymake s’intègre mieux à Eglot, mais Flycheck reste globalement préféré
    • Comme Eglot active automatiquement flymake-mode, il faut ajouter flymake à eglot-stay-out-of pour le désactiver
    • Le mode global de flycheck-eglot ne fonctionnant pas de manière stable, une configuration directe via hook a été utilisée

Configuration des raccourcis clavier

  • Eglot ne fournit pas de raccourcis clavier par défaut, il faut donc les définir soi-même
  • Exemples de raccourcis actuellement utilisés :
    • C-c r → eglot-rename, C-c o → eglot-code-action-organize-imports
    • C-c h → eldoc, C-c a → eglot-code-actions, C-c q → eglot-code-action-quickfix
    • C-M-<mouse-2> → eglot-code-actions-at-mouse (un raccourci souris pour contourner les limites d’intégration de flycheck-eglot)
  • eglot-format n’est volontairement pas associé à un raccourci — en Go, gofmt de go-mode est déjà utilisé
  • En définissant eglot-extend-to-xref sur t, on peut, après avoir sauté vers un élément externe, chercher avec M-? d’autres usages dans le projet

Démarrage automatique du serveur LSP

  • La documentation officielle d’Eglot recommande un démarrage manuel, mais une configuration a été mise en place pour démarrer automatiquement uniquement pour les fichiers locaux
  • La fonction eglot-ensure-local-only est définie pour vérifier si le fichier est distant avec file-remote-p, puis appeler eglot-ensure
  • Limite de eglot-ensure : lorsqu’il existe plusieurs serveurs LSP pour un même langage (par exemple pylsp et ruff pour Python), seul le serveur par défaut est choisi automatiquement ; pour en changer, il faut arrêter le serveur courant puis lancer eglot manuellement
  • Pour exécuter plusieurs serveurs LSP simultanément, on peut utiliser un multiplexeur comme rassumfrassum

Accessibilité des Code Actions

  • Les code actions fournies par les serveurs LSP sont nombreuses, mais il est difficile d’y accéder commodément dans Eglot (comme dans lsp-mode)
  • Les serveurs LSP ne fournissent les code actions qu’à la demande, et elles dépendent d’une position précise
  • Eglot ne propose pas de filtrage dans les longues listes de code actions renvoyées par le serveur, ce qui rend ces listes encombrées aussi bien en Go qu’en Python

Configuration du workspace dans pylsp

  • Avec pylsp (serveur Python LSP), pour désactiver en permanence les linters basés sur le style dans les diagnostics, il faut utiliser eglot-workspace-configuration
  • lsp-mode propose des contrôles pratiques pour désactiver des outils de diagnostic individuels (comme mccabe), mais avec Eglot, il faut écrire soi-même la workspace configuration au format JSON
  • Exemple : désactiver mccabe, pylint, mypy, pycodestyle, etc. avec :enabled :json-false
  • Les clés liées à mypy sont utilisées sous deux noms différents, pylsp_mypy et mypy, ce qui vient de détails d’implémentation internes à pylsp
  • Il faut impérativement utiliser setq-default ; avec setq, cela ne fonctionne pas

Configuration par projet et .dir-locals.el

  • Eglot ne propose pas de méthode pratique pour définir temporairement des paramètres de serveur LSP propres à un projet
  • Lorsqu’une configuration spécifique est nécessaire, le plus simple est d’écrire correctement les réglages dans le fichier .dir-locals.el
  • Dans gopls (Go) et pylsp (Python), la structure de configuration est complètement différente, et il faut donc apprendre chaque serveur LSP séparément
  • Pour modifier la configuration à l’exécution, il faut écrire une fonction dédiée qui définit une nouvelle classe via dir-locals-set-class-variables, puis appelle dir-locals-set-directory-class et eglot-signal-didChangeConfiguration
  • Eglot exécute un seul serveur LSP pour l’ensemble d’un projet (arborescence de répertoires), donc une configuration LSP au niveau fichier ou buffer est impossible ; elle doit impérativement être appliquée au niveau du projet
  • Si eglot-workspace-configuration est défini par un moyen générique, il devient une variable locale au buffer, ce qui le rend en pratique inutile

Retour d’expérience : Flymake vs Flycheck

  • Flymake s’intègre mieux à Eglot et affiche directement dans les notes de diagnostic des propositions de correction fondées sur le serveur LSP (quickfix code action) dans le menu contextuel du bouton 2
  • Flycheck se limite au marquage des erreurs, avec la contrainte de devoir déclencher séparément les code actions LSP
  • Après être d’abord passé à Flymake, l’auteur a conservé les deux configurations, car Flycheck reste meilleur sur certains points
  • L’auteur de flycheck-eglot a proposé une solution de contournement à ce problème, ce qui a permis de revenir à Flycheck
  • Flycheck dispose d’une collection de checkers plus vaste que Flymake, et il est plus facile de passer de l’un à l’autre
  • L’option de diagnostic affiché en fin de ligne de Flymake laisse à désirer
    • flycheck-inline n’affiche que les avertissements à la position actuelle et ne montre pas tous les avertissements pendant le défilement
    • Sideline + sideline-flycheck ont la même limite, mais offrent une meilleure expérience UI

À lire aussi

2 commentaires

 
GN⁺ 2026-05-13
Commentaires de Lobste.rs

  • Selon le langage, conseiller de lancer Eglot automatiquement peut être dangereux au plus haut point. Les serveurs LSP de nombreux langages ne peuvent pas être utilisés en toute sécurité avec du code non fiable, et le simple fait d’ouvrir les fichiers d’un projet Rust ou Elixir contrôlé par un attaquant peut compromettre la machine
    À moins qu’il s’agisse d’un langage dont le serveur LSP est connu pour être sûr, il faut éviter l’activation automatique du LSP. Référence : https://rust-analyzer.github.io/book/security.html

    • Si l’on examine du code potentiellement hostile, il faut au final faire tout le travail à l’intérieur d’une véritable frontière de sécurité. Même git status peut constituer une surface d’attaque : https://github.com/justinsteven/advisories/…
      La différence est que, dans ce cas, l’exploit doit être présent dans le dépôt lui-même, alors qu’avec le LSP, le problème peut aussi venir des dépendances. Cela dit, si on s’habitue à activer le LSP par réflexe, il semble difficile d’éviter de devenir moins sensible aux avertissements
    • Une autre raison d’éviter le démarrage automatique est que certains serveurs de langage ont des exigences élevées en ressources. Sur un projet Rust de taille moyenne, le simple fait d’ouvrir brièvement un fichier peut lancer un processus rust-analyzer de 4 Go pendant plusieurs minutes et créer un répertoire target/debug/ de plus de 1 Go
    • De toute façon, à partir du moment où on exécute cargo build, c’est déjà plié. Bien sûr, il y a une grande différence entre le chargement automatique du LSP et une commande lancée explicitement par l’utilisateur, mais en pratique l’écart est parfois plus faible qu’on ne l’imagine
    • Si l’on veut de l’automatisation, il vaut mieux adopter l’approche de lsp-mode : demander avant l’activation et ajouter le projet à une liste d’autorisation. S’il existe déjà un hook qui « exécute automatiquement », il suffit d’une dizaine de lignes avec read-from-minibuffer pour demander d’abord « Faites-vous confiance à ce dossier ? », et en prenant un répertoire de référence avec quelque chose comme projectile, on obtient l’essentiel des bénéfices en matière de sécurité
      Dans ma configuration, j’utilise la liste d’autorisation de lsp-mode, mais je l’efface à chaque session, de sorte qu’il faut redonner son accord projet par projet à chaque redémarrage d’Emacs. Au départ, je crois que j’ai fait ça pour des raisons de performance, car lsp-mode lançait parfois plusieurs processus avant même d’ouvrir un projet donné. Le risque de sécurité est réel, mais mettre en place un workflow correct n’est pas si difficile

  • Ce qui m’agace le plus dans Eglot, c’est qu’il n’expose pas la plupart de ses commandes comme fonctions et les définit plutôt sur des interfaces Emacs comme xref. Quand on a deux backends xref, par exemple CIDER et clojure-lsp en Clojure, on a tendance à préférer CIDER, qui connaît l’état d’exécution réel du code chargé
    L’analyse statique de clojure-lsp peut notamment être désynchronisée, surtout dans un workflow REPL distant. Avec lsp-mode, on peut appeler directement des fonctionnalités comme aller à la définition tout en continuant à utiliser xref, mais avec Eglot, exclure seulement un backend xref particulier est assez pénible. D’autres commandes présentes dans lsp-mode manquent aussi dans Eglot, alors qu’en réalité ce sont des fonctionnalités qui pourraient être fournies via des points d’intégration Emacs similaires à xref

  • J’ai essayé lsp-mode une fois, mais je l’ai supprimé immédiatement à cause du trop grand nombre de pop-ups et de notifications confuses. Eglot offre une expérience LSP bien plus discrète
    On peut le laisser activé et utiliser les fonctionnalités quand on est prêt. Il est intéressant de voir ~cks adopter l’approche inverse tout en mentionnant divers conseils et alternatives

    • J’utilise lsp-mode avec beaucoup de fonctionnalités désactivées, ce qui donne une interface assez discrète. J’ai envisagé de passer à Eglot, mais il ne semblait pas offrir les intégrations que je voulais, donc je n’ai pas poussé plus loin à l’époque
      Ce que je cherche vraiment, c’est un serveur LSP capable de gérer des dépôts très volumineux. C’est souvent là que j’atteins la limite, et je me demande parfois s’il ne faudrait pas créer quelque chose qui fasse l’essentiel de l’indexation du code source en une fois pour le réutiliser dans diverses opérations de type LSP, mais j’ai peur de vouloir encore faire bouillir l’océan

  • Eglot et lsp-mode sont les clients LSP les plus connus pour Emacs, mais il existe aussi des alternatives comme lspce et lsp-bridge
    J’utilise Eglot avec satisfaction depuis plusieurs années, mais il présente une limite de conception qui pourrait devenir plus problématique à l’avenir. Il part du principe qu’il n’y a qu’un client par buffer ; c’était raisonnable au moment de sa création, mais aujourd’hui il devient de plus en plus courant de vouloir faire tourner plusieurs serveurs LSP dans un même buffer. La [recommandation] actuelle est d’utiliser un programme séparé comme multiplexeur LSP

    • Il y a aussi this pour ça

  • Je suis passé de lsp-mode à Eglot pour Python il y a 4 jours, et j’en suis satisfait
    J’ai publié ici une version minimale de ma configuration actuelle : https://discuss.afpy.org/t/configuration-emacs-minimale-en-2026/3001

    • Il y a presque un an, je suis passé d’elpy à eglot + basedpyright, et j’en suis aussi plutôt content
      J’ai tout de même quelques frustrations côté complétion. Par exemple, quand j’appuie sur foo<tab><tab>, basedpyright auto-importe parfois quelque chose d’étrange alors qu’un symbole pertinent existe déjà dans la portée actuelle, et je n’ai pas encore trouvé comment ne compléter que jusqu’à la plus longue sous-chaîne commune. À part ça, c’est plutôt bien

  • J’envie les gens qui arrivent à faire d’Emacs un IDE moderne. J’utilise les raccourcis Emacs, mais même en y consacrant 6 à 8 heures, je n’arrive pas à transformer Emacs en IDE
    J’avais déjà renoncé autrefois en essayant de l’adapter à FB Flow, que j’utilisais à la place de TypeScript dans des environnements de développement Linux et FreeBSD, et le week-end dernier j’ai encore abandonné en tentant de monter sous Windows un environnement Python complet avec tree-sitter. Il y a trop de choses à configurer, et il faut aussi récupérer séparément trop de DLL, comme les parseurs tree-sitter, si bien que l’effort requis pour obtenir quelque chose d’équivalent à un vrai IDE est excessif. Je n’ai plus envie d’y consacrer du temps, mais j’aime toujours le fait qu’en tapant emacs -nw dans n’importe quel terminal, je retrouve un environnement d’édition familier

    • Pour Python, une configuration minimale avec fido-vertical-mode, which-key-mode, global-completion-preview-mode, yasnippet, eglot-ensure et basedpyright suffit largement pour démarrer
      Si basedpyright est présent dans le PATH, on obtient une vraie complétion et une coloration syntaxique correcte même sans grammaire tree-sitter. C’est une version réduite au minimum de ma configuration complète, et celle-ci est disponible dans my full config
    • doom emacs vaut le coup d’œil. La configuration est très simple et, même par défaut, la plupart des choses fonctionnent bien. Si evil-mode ne vous convient pas, vous pouvez aussi revenir aux raccourcis Emacs