Intégration de Claude Code IDE pour Emacs

• Claude Code IDE for Emacs intègre nativement Claude Code CLI dans Emacs pour proposer un environnement d’assistance au codage par IA puissant.
• Grâce à un pont bidirectionnel basé sur le Model Context Protocol (MCP), Claude peut utiliser diverses fonctionnalités d’Emacs, notamment le LSP, la gestion de projets et les fonctions Elisp.
• Il propose des fonctions optimisées pour Emacs, comme la détection automatique de projet, les sessions multiples, l’intégration du diagnostic (erreurs/avertissements), les diff avancés, le tab-bar ainsi que le suivi de la sélection et des buffers.
• S’appuyant sur les commandes et l’extensibilité d’Emacs, il permet d’exposer directement des commandes via un serveur MCP et d’intégrer des workflows personnalisés.
• Une connexion approfondie entre Claude et l’ensemble de l’écosystème Emacs permet de bâtir un environnement de développement assisté par IA, en mode cloud.

---

Vue d’ensemble

Claude Code IDE for Emacs est un projet open source qui optimise les fonctionnalités de Claude AI dans l’environnement Emacs via l’intégration avec Claude Code CLI. Contrairement aux simples wrappers de terminal, ce package fournit un bridge basé sur MCP (Model Context Protocol) avec communication bidirectionnelle, conçu pour que Claude puisse réellement exploiter les fonctionnalités internes d’Emacs. En se connectant à l’écosystème riche d’Emacs (LSP, gestion de projets, fonctions Elisp), il met en place un environnement de support au développement IA productif et intelligent propre aux utilisateurs d’Emacs.

Principales fonctionnalités

• Détection automatique de projet et gestion des sessions

  • Utilise le project.el intégré à Emacs pour reconnaître automatiquement les projets et séparer les sessions.
  • Fournit une instance Claude Code indépendante et des buffers par projet.

• Intégration du terminal et support couleur

  • Support d’un terminal couleur via vterm ou eat.
  • Discussion avec Claude directement dans Emacs.

• Intégration IDE via le protocole MCP

  • Expose diverses commandes Emacs (navigation de code, recherche de symboles, analyse AST, etc.) via un serveur MCP.
  • Permet à Claude d’exécuter des commandes Emacs et des fonctions personnalisées.

• Serveur MCP Tools hautement extensible

  • Ajout et définition de tools MCP personnalisées possibles (par exemple : recherche globale dans le projet, refactoring global, etc.).

• Diagnostic de code et diff

  • Fournit les informations d’erreur/avertissement via l’intégration Flycheck/Flymake.
  • Prend en charge des vues de diff avancées et l’accès aux diagnostics via ediff.

• Gestion du changement d’état/commandes

  • Grâce à tab-bar et au suivi de la sélection/buffer, Claude peut comprendre le contexte courant de l’utilisateur.

Intégration des outils Emacs

Claude Code IDE expose directement à Claude, via le système de MCP tool, diverses commandes et informations d’Emacs.

• Intégration LSP (xref)

  • Prise en charge de la navigation intelligente basée sur le LSP : go-to-definition, recherche de symboles et de références à l’échelle du projet.

• Support Tree-sitter

  • Fournit une compréhension de la structure de code via l’analyse de l’arbre syntaxique avec AST (Abstract Syntax Tree).

• Intégration Imenu, Project

  • Fournit automatiquement la liste des symboles, les fichiers du projet et les informations de structure.

• Fonctions Elisp personnalisées

  • Exposition directe en tant que MCP tool pour exploiter des flux de travail spécifiques ou des fonctionnalités métier.

Cette intégration permet à Claude d’offrir un support IA précis au niveau du code en s’appuyant sur les informations contextuelles de l’écosystème Emacs.

Utilisation

Commandes de base

• M-x claude-code-ide-menu : ouvre le menu transient qui expose visuellement toutes les commandes.
• Active Claude Code dans un projet, envoie des prompts, reprend les conversations précédentes et gère divers états/sessions.
• Permet de gérer plusieurs projets simultanément avec des sessions Claude dédiées à chaque projet.

Gestion des fenêtres et sessions

• Si une nouvelle session est déjà en cours d’exécution, l’action se limite à basculer/afficher la fenêtre.
• Même après avoir fermé la fenêtre avec la commande standard d’Emacs (C-x 0), le processus Claude lui-même ne s’arrête pas.

Paramètres

• Supporte une personnalisation détaillée : Claude Code CLI, backend terminal, backend de diagnostic, position/taille de fenêtre, options de debug, etc.
• Offre des options avancées, comme l’ajout de flags, la définition du system prompt, la fonction de nommage des buffers.
• Active un serveur MCP et permet de spécifier les outils/ports utilisés.

Configuration du terminal backend

• La valeur par défaut est vterm, avec possibilité de basculer vers le backend eat si nécessaire.
• eat est un terminal purement basé sur Elisp, utile en cas de problème de build de vterm.
• Propose des raccourcis clavier dédiés (M-RET : retour à la ligne dans le prompt, C-<escape> : quitter/annuler, etc.).

Options de diagnostic et débogage

• Détection et intégration automatiques, ou définition forcée, de Flycheck/Flymake.
• Option temporaire intégrée pour contourner le bug de reflow du terminal Claude (#1422).
• Prise en charge de journaux de débogage détaillés côté Emacs et côté CLI (visualisation des messages WebSocket, JSON-RPC, etc.).

Avancé : plusieurs Worktree, gestion des sessions

• Utilisation de git worktree pour exécuter plusieurs sessions indépendantes par branche au sein d’un même projet.
• Conservation d’un buffer et d’un contexte propres à chaque groupe de travail pour supporter des workflows de développement parallèles.

Détails des MCP Tools Emacs

Exemples de MCP Tools intégrés

• xref-find-references : recherche complète des références d’un symbole donné dans le projet.
• xref-find-apropos : recherche de symboles/code par motif dans l’ensemble du code.
• treesit-info : fournit des données d’analyse AST basées sur tree-sitter.
• imenu-list-symbols : affiche la liste de toutes les fonctions et variables d’un fichier.
• project-info : fournit les métadonnées et informations de fichiers du projet courant.

Ajout d’outils personnalisés

• Les utilisateurs peuvent ajouter leurs propres fonctions Emacs au format MCP tool.
• Par exemple, il est possible de définir un outil de recherche de code basé sur ripgrep ou des commandes spécifiques à un domaine, puis de les appeler directement depuis Claude.

Licence et projets associés

• Distribué sous GNU GPL v3.0 ou version ultérieure.
• Présente aussi des projets associés comme les plugins d’intégration pour VS Code et Neovim (claudecode.nvim), entre autres.

Importance et avantages

Claude Code IDE for Emacs offre un environnement IDE IA puissant qui, contrairement aux autres outils d’intégration LLM/IA, exploite activement le contexte de travail propre à Emacs et les informations de son écosystème. Bien qu’il en soit encore aux premières étapes, il constitue un choix particulièrement solide pour les utilisateurs d’Emacs et les développeurs open source, grâce à ses nombreuses fonctions intégrées, à son haut niveau de personnalisation et à sa prise en charge multi-projets.

[GN⁺]

Avis de Hacker News

• Les outils de codage IA comme Claude Code ou Aider, à l’instar de LSP et tree-sitter, sont une excellente nouvelle pour des éditeurs comme Emacs ou Vim: on n’a plus à réimplémenter toutes les fonctions IDE avancées comme autrefois, et on peut les intégrer facilement à ces outils pour se concentrer sur ses propres atouts d’édition; en pratique, cette personnalisation et cette intégration souple renforcent clairement la compétitivité de ces éditeurs.
  • Je me demande s’il existe un standard qui permette d’intégrer facilement dans un éditeur des outils de codage de type agent, comme on peut le faire avec LSP.
  • J’ai l’impression que c’était déjà le cas: Emacs et Vim avaient déjà des fonctions IDE avancées depuis longtemps, et avec LSP et tree-sitter, la standardisation entre éditeurs et langages est devenue plus simple.
  • Je ne suis pas d’accord avec l’idée que Emacs et Vim seraient des éditeurs de niche; ce sont déjà des éditeurs de référence.
• J’ai toujours pensé qu’Emacs était l’éditeur idéal pour les agents IA: ils peuvent facilement inspecter tout l’état de l’éditeur et modifier son fonctionnement via Elisp. Les éditeurs qui autorisent une personnalisation au niveau de Vim ou Emacs auront probablement un gros avantage à l’avenir.
  • Je remarque que Vim et Emacs ont toujours eu des atouts majeurs. Les avis divergent selon les personnes, mais pour moi la faible ouverture de VSCode ou IntelliJ est un vrai défaut. Par extension fermée, j’entends API de plugin limitée, environnement d’exécution sandboxé, structure d’approbation entreprise, opacité de la logique interne, etc. Avant, je cherchais à migrer vers d’autres IDE pour obtenir de nouvelles fonctions; maintenant, apprendre Emacs me rapproche déjà beaucoup mieux de mes objectifs. La façon de résoudre des problèmes avec Emacs est bien plus satisfaisante que dans un IDE.
  • La force d’Emacs est son noyau interpréteur Lisp: l’agent IA peut examiner directement l’état complet de l’éditeur à l’exécution, avec le même mécanisme d’évaluation que l’utilisateur, et le modifier. La plupart des éditeurs ont une API de plugins figée.
• J’utilise en ce moment le plugin [claude-code.el](https://github.com/stevemolitor/claude-code.el] avec satisfaction. C’est un simple wrapper terminal, mais il offre aussi un menu Transient puissant. Même en restant dans Emacs, l’efficacité du workflow s’améliore déjà beaucoup: j’ai pu créer facilement un flux de travail bien plus personnalisé qu’avec l’ancien environnement iTerm. Je vais continuer à suivre de près les nouveaux paquets qui sortent; eca-emacs m’attire aussi. Les outils sur lesquels on mise en productivité, j’ai tendance à les aborder avec prudence au début: les projets conséquents passent souvent par une phase de « big bang » qui demande beaucoup d’ajustements.
  • Je l’ai essayé un moment puis suis revenu à utiliser claude code directement dans le terminal. Emacs avait un petit côté saccadé, et je n’avais pas vraiment de raison de ne pas ouvrir une fenêtre terminal séparée. La non-intégration avec le package mcp.el est aussi dommage. En pratique, avec Claude Code, je n’ai pas encore atteint dans mon travail une qualité de code vraiment convaincante. mcp.el vaut aussi la peine d’être consulté.
• J’apprécie le fait qu’Emacs intègre des outils récents comme LSP, tree-sitter et Claude Code, mais en même temps la difficulté de configuration me paraît avoir vraiment augmenté. Malgré mes 20 ans d’usage d’Emacs, mettre l’environnement en place aujourd’hui n’est pas simple. Avant l’intégration IDE, Claude Code semblait être le plus simple à utiliser (ça fonctionnait et la synchronisation automatique des buffers demandait quasi rien). Sous un nouveau macOS, j’ai à peine réussi à lancer typescript-ls, et gopls n’est même pas encore téléchargé. En une ou deux heures, ça peut se corriger, mais c’est fastidieux de trouver où ça bloque. Je partage ça par curiosité sur la manière dont les utilisateurs Emacs font aujourd’hui: je code avec plaisir avec Zed en ce moment; lâcher une adaptation de 20 ans à Emacs n’est pas évident. La personnalisation, des petits fichiers de config au support de projets à grande échelle, reste précieuse. Je me demande si Neovim est meilleur de ce côté. Je me demande aussi si je dois mieux apprendre le debug Elisp pour mieux comprendre comment les commandes que j’utilise agissent sur l’environnement. Ayant pris l’habitude des raccourcis Emacs (même jusqu’au Dvorak!), je me demande si l’expérience Neovim est différente à ce niveau.
  • Le debug Elisp est hautement recommandé. Même après des dizaines d’années sur Emacs, beaucoup ignorent le profiler intégré, edebug, apropos, l’expansion de macro, le système advising, les indirect buffers, etc. Si on compare Emacs à une voiture, c’est une machine dans laquelle on peut changer les pièces et la transformer même en sous-marin en cours de route; il faut donc accepter naturellement la résolution de base des problèmes et les situations inattendues. Ce qui me plaît, c’est qu’on repère le point de rupture et qu’on peut écrire directement dans le buffer gptel l’Elisp adapté à un hook ou une fonction advise puis le tester tout de suite. Cette sensation de libération, il faut la vivre. Je ne m’embarrasse plus d’une config « propre »: je module proprement et j’ajoute de l’Elisp au besoin. La plupart du temps, quand quelque chose casse à cause de mises à jour de paquets externes, la recherche du problème et la mise en place d’une alternative se font en quelques minutes, et la fréquence reste faible.
  • Pour gérer les problèmes d’environnement, j’exécute Emacs en Docker; voyez emacs-native-dockerfiles.
  • Intégrer un nouvel écosystème de langage dans Emacs, c’est déjà suffisamment pénible rien que dans le choix des paquets et des outils externes (serveurs LSP, etc.), avec beaucoup de projets de type dabbling qui exigent de se poser la question à chaque fois. Pour le téléchargement/installation des outils externes, j’utilise Nix (devenv.sh), direnv, etc., pour éviter que Emacs télécharge directement et juste fournir les chemins; je stocke aussi les fichiers de config dans devenv pour que les collègues puissent utiliser le même environnement.
  • Utilisateur Emacs depuis 8 ans, je suis passé entièrement à nvim il y a deux mois et n’ai pas ouvert Emacs du tout pendant un mois. J’ai installé lazy.vim et j’utilise alternativement des plugins IA. L’écosystème et la communauté côté nvim sont plutôt plus actifs récemment, ThePrimeagen vaut le détour.
  • L’expérience Neovim a aussi beaucoup évolué: on peut configurer de barebone à des fonctions IDE complètes; il existe déjà de nombreuses distributions préconfigurées, par exemple LazyVim. Pour les plugins IA, voir awesome-neovim #ai.
• L’intégration plus poussée avec org mode, ou des fonctions IA globales de prise de notes, est encore plus cruciale: GitHub Copilot efface les conversations après 30 jours, et ça casse pas mal la construction d’une base de connaissances via IA dans la pratique, comme je l’ai constaté. Une approche de type Google notebookllm pour gérer localement recherches et notes devient alors indispensable.
  • Je recommande d’essayer gptel-mode: la conversation se sauvegarde dans un buffer org et on peut facilement sauvegarder/restaurer des sessions; ça s’intègre aussi bien avec mcp.el.
  • ob-aider vaut aussi le détour, lien ob-aider
• La possibilité d’ajouter librement des outils à un serveur MCP me rend très satisfait, exactement comme on peut l’attendre d’Emacs. J’écris de l’Elisp de façon plus régulière ces dernières années alors que je l’utilise depuis des années; le support de Claude pour écrire de l’Elisp est aussi assez bon, ce qui me pousse à l’utiliser encore plus (il faut parfois corriger soi-même l’alignement des parenthèses, mais globalement c’est bon). Je vais absolument essayer efrit de Steve Yegge; la capacité d’un agent à exécuter des expressions Elisp arbitraires repousse d’un cran les limites d’Emacs. efrit
  • Je suis un vieux fan et follower de Yegge, je pense qu’on est encore en mode lune de miel de vibe code, mais son expertise Emacs est imbattable. J’ai compris il y a 1 ou 2 ans que les gros LLM avaient une aptitude étrange à l’Elisp, ce qui a donné naissance au projet hypermodern. Je pense qu’efrit est très prometteur (même si je ne l’ai pas encore parfaitement configuré).
• En parallèle, voir plus de 5 packages Emacs/Claude Code intégrés et deux ou trois se livrer à une compétition animée sur Reddit est intéressant, mais les véritables bons plugins semblent exister en silence, sans que personne n’en parle. yuya373/claude-code-emacs implémente déjà presque toutes les fonctionnalités des concurrents.
  • Je ne sais pas quel est son niveau de popularité, mais il me semble le plus facile à installer: consultez melpa claude-code.
  • Ce package semble ne pas avoir d’intégration /ide de claude-code-ide.
• Je recommande vivement aussi eca, qui se concentre sur le fait de créer le meilleur outil de pair programming IA pour Emacs.
• J’ai bien senti récemment une ambiance dans la communauté Emacs qui critique ce débat d’intégration IA; honnêtement je pense que ça apporte plus d’inconvénients que de bénéfices. Même si l’IA évolue différemment de notre génération, les racines d’Emacs sont dans le MIT AI Lab, et une posture de rejet de ces outils issus d’un AI working group paraît étrange.
  • La beauté d’Emacs, c’est le contrôle centré utilisateur: on peut tout changer au niveau de la couche Elisp, et c’est ce qui explique que ces plugins apparaissent sans cesse. VS Code, au contraire, induit structurellement une fragmentation: Microsoft utilise une API dédiée pour ses outils propriétaires, mais n’expose vers l’extérieur une API d’extension bien plus limitée, d’où la multiplication des forks vscode. Avec un seul développeur Elisp vraiment passionné et compétent, on peut tout changer dans Emacs et faire apparaître autant de modules d’intégration IA/LLM que l’on veut. Les critiques dans la communauté Emacs sont souvent exagérées selon moi; de fait, les plugins IA/LLM sortent régulièrement et obtiennent de bons retours, par exemple gptel.
  • L’origine de cette ambiance viendrait de Richard Stallman: il juge que tant qu’un projet de « logiciel non libre » est proposé comme alternative, il faut garder ses distances tant qu’un projet de logiciel libre n’est pas prêt. Cette approche a entraîné des retards dans l’adoption de décisions comme les extensions GCC, LLVM debugger, tree-sitter, git/bzr, CI buildfarm, etc., et pendant ce temps-là, l’adoption d’alternatives aux projets centraux comme Emacs a été ralentie. Finalement, il faudra toujours accepter plus tard; parfois, cela semble aussi une façon de défendre la position de la FSF.
  • La communauté Emacs est très variée; on trouve des critiques partout, mais on peut les ignorer. Avec des modules tiers, on peut ajouter toutes les fonctionnalités qu’on veut, et le mainteneur principal n’a aucun moyen de bloquer ça.
  • Le MIT AI Lab connecté à l’IA actuelle est une découverte intéressante pour moi.
• Ces outils m’enthousiasment beaucoup; j’aime intégrer Emacs et l’IA dans mon flux de code, mais surtout je veux les faire fonctionner localement, en local hardware à moins de 2000 $. Je me demande si c’est déjà possible aujourd’hui ou bientôt, et si certains utilisent déjà un agent de codage avec un modèle local.
  • Il y a eu d’énormes progrès en inférence efficace en mémoire et en modèles open source spécialisés en code: en ce moment, la famille Qwen3-Coder attire beaucoup l’attention (Qwen3-Coder); pour l’exécution locale, il existe Ollama, LM Studio, etc. Selon la taille du modèle et la quantification, un budget de 2000 permet de faire tourner énormément de modèles, et les Mac de la série M sont aussi très bon rapport qualité/prix. Le subreddit LocalLlamas regorge d’infos sur l’usage de LLM local; la différence avec le niveau des grands AI labs est réelle, mais si vous privilégiez une configuration entièrement locale, c’est un projet suffisamment intéressant et valable.
  • gptel prend en charge différents modèles, dont l’exécution locale.
  • Un MacMini, un frame.work desktop, ou un Nvidia DGX Spark sont aussi des options (à partir de 3k)