Integración de Claude Code IDE para Emacs

 (github.com/manzaltu)
1 puntos por GN⁺ 2025-08-07 | 1 comentarios | Compartir por WhatsApp
  • Claude Code IDE for Emacs integra de forma nativa Claude Code CLI en Emacs para ofrecer un entorno de asistente de programación con IA muy potente
  • A través de un puente bidireccional basado en Model Context Protocol (MCP), Claude puede aprovechar diversas funciones de Emacs como LSP, gestión de proyectos y funciones de Elisp
  • Proporciona funciones optimizadas para Emacs como detección automática de proyectos, sesiones múltiples, integración de diagnóstico (errores/advertencias), diff avanzado, seguimiento de tab-bar y selección/buffers
  • Gracias a los comandos y la extensibilidad de Emacs, es posible exponer comandos directamente mediante un servidor MCP e integrar flujos de trabajo personalizados
  • Construye un entorno de desarrollo con soporte de IA en la nube mediante una conexión profunda entre Claude y todo el ecosistema de Emacs

Descripción general

Claude Code IDE for Emacs es un proyecto de código abierto que potencia las capacidades de Claude AI dentro de Emacs mediante su integración con Claude Code CLI. A diferencia de un simple wrapper de terminal, este paquete ofrece un puente basado en MCP (Model Context Protocol) con comunicación bidireccional, diseñado para que Claude pueda utilizar realmente las funciones internas de Emacs. Conecta con el ecosistema sólido de Emacs, incluyendo LSP, gestión de proyectos y funciones de Elisp, para implementar un entorno de soporte al desarrollo con IA productivo e inteligente para usuarios de Emacs.

Características principales

  • Detección automática de proyectos y gestión de sesiones

    • Usa project.el integrado en Emacs para reconocer proyectos automáticamente y separar sesiones
    • Proporciona instancias y buffers de Claude Code independientes para cada proyecto

  • Integración de terminal y soporte de color

    • Soporte de terminal con color mediante vterm o eat
    • Permite conversar con Claude dentro de Emacs

  • Integración de IDE a través del protocolo MCP

    • Expone diversos comandos de Emacs (exploración de código, consulta de símbolos, análisis AST, entre otros) como servidor MCP
    • Claude puede ejecutar comandos de Emacs y funciones definidas por el usuario

  • Servidor de herramientas MCP altamente extensible

    • Posibilidad de agregar/definir herramientas MCP personalizadas (p. ej., búsqueda en todo el proyecto, refactorización global, etc.)

  • Diagnóstico de código y diff

    • Entrega información de diagnóstico de errores/advertencias del código mediante Flycheck y Flymake
    • Soporta vista diff avanzada y acceso a información de diagnóstico usando ediff

  • Gestión de estado/traslado de comandos

    • Con tab-bar, seguimiento de selección y buffers, Claude puede comprender el contexto actual del usuario

Integración de herramientas de Emacs

Claude Code IDE expone directamente a Claude, mediante el sistema MCP tool, múltiples comandos e información de Emacs

  • Integración LSP (xref)

    • Soporte de navegación inteligente basada en LSP, incluyendo go-to-definition y búsqueda global de símbolos/referencias del proyecto

  • Soporte de Tree-sitter

    • Ofrece comprensión de la estructura del código mediante análisis de árbol sintáctico y AST (árbol sintáctico abstracto)

  • Integración de Imenu y Project

    • Proporciona automáticamente símbolos, archivos del proyecto e información de estructura

  • Funciones Elisp personalizadas

    • Expuestas directamente como MCP tool para aprovechar flujos de trabajo únicos o funciones especializadas por dominio

Con esta integración, Claude puede utilizar la información de contexto del ecosistema de Emacs para ofrecer asistencia de IA precisa a nivel de código

Uso

Comandos básicos

  • M-x claude-code-ide-menu: Invoca un menú transitorio que muestra visualmente todos los comandos
  • Activación de Claude Code dentro del proyecto, envío de prompts, reanudación de conversaciones previas y diversa gestión de estados/sesiones
  • Posibilidad de administrar varios proyectos simultáneamente y operar sesiones únicas de Claude por cada proyecto

Ventanas y gestión de sesiones

  • Si una nueva sesión ya se está ejecutando, solo se alterna/mostrar la ventana
  • Aun cerrando la ventana con el comando estándar de Emacs (C-x 0), Claude en sí no termina

Configuración

  • Soporta personalización detallada de Claude Code CLI, backend de terminal, backend de diagnóstico, posición/tamaño de ventanas, opciones de depuración, entre otros
  • Ofrece opciones avanzadas como agregar flags, definir prompts del sistema y función de nombre de buffer
  • Es posible activar el servidor MCP y definir herramientas/puerto en uso

Configuración del backend de terminal

  • El valor predeterminado es vterm, con opción de cambiar a eat si es necesario
  • eat es un terminal puro basado en Elisp y es útil cuando hay problemas de compilación de vterm
  • Incluye atajos de teclado dedicados (M-RET: salto de línea en el prompt, C-<escape>: salida/cancelación, etc.)

Opciones de diagnóstico/depuración

  • Detección/enlace automático o especificación forzada de Flycheck y Flymake
  • Incluye opción temporal para evitar el bug de reflujo/reajuste del terminal de Claude (#1422)
  • Soporta logs de depuración detallados a nivel de Emacs y CLI para ver mensajes de WebSocket, JSON-RPC, entre otros

Avanzado: múltiples worktree y operación de sesiones

  • Uso de git worktree, con posibilidad de ejecutar varias sesiones independientes por ramas dentro del mismo proyecto
  • Soporte a flujos de trabajo de desarrollo paralelo mediante buffers y contexto únicos por grupo de trabajo

Detalle de Emacs MCP Tools

Ejemplos de MCP Tools incorporadas

  • xref-find-references: búsqueda completa de referencias de un símbolo específico dentro del proyecto
  • xref-find-apropos: búsqueda global de símbolos/código basada en patrón
  • treesit-info: entrega datos de análisis AST basados en tree-sitter
  • imenu-list-symbols: muestra todas las funciones y variables de un archivo
  • project-info: provee metadatos y archivos del proyecto actual

Añadir herramientas personalizadas

  • Los usuarios pueden agregar sus propias funciones de Emacs siguiendo el formato de herramientas MCP
  • Por ejemplo, se puede definir una herramienta de búsqueda de código con ripgrep o comandos propios de un dominio y llamarlos directamente desde Claude

Licencia y proyectos relacionados

  • Disponible bajo GNU GPL v3.0 o superior
  • Se mencionan proyectos relacionados como integraciones de VS Code y Neovim (claudecode.nvim)

Importancia y ventajas

Claude Code IDE for Emacs ofrece un entorno de IDE con IA más poderoso que las herramientas de integración de LLM/IA existentes, ya que permite aprovechar de forma activa el contexto de trabajo y la información del ecosistema de Emacs. Aun en una fase relativamente temprana, cuenta con múltiples funciones integradas, alto nivel de personalización y soporte multi-proyecto, por lo que es una opción muy sólida para usuarios de Emacs y desarrolladores de código abierto

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-08-07
Comentario de Hacker News
  • Igual que LSP y tree-sitter, herramientas de codificación con IA como Claude Code o Aider son una gran noticia para editores como Emacs o Vim, porque ya no hace falta esforzarse por implementar funciones avanzadas de IDE por cuenta propia y se pueden integrar fácilmente para concentrarse en sus propias ventajas editoriales. En la práctica, esa personalización y esa integración flexible elevan mucho más la competitividad de estos editores.
    • Me pregunto si hay un estándar para integrar fácilmente herramientas de codificación tipo agente en el editor, como con LSP.
    • Siempre pensé que sí: Emacs y Vim ya tenían funciones avanzadas de IDE desde antes, y con LSP y tree-sitter ahora la estandarización entre editor y lenguaje es más simple.
    • No estoy de acuerdo con que Emacs y Vim sean editores de nicho; ya son editores de referencia.
  • Siempre pensé que Emacs es el mejor editor para un agente de IA, porque puede ver el estado completo del editor con facilidad y cambiar su comportamiento mediante elisp; los editores que permitan la personalización de Vim o Emacs tendrán una gran ventaja en el futuro.
    • De hecho, Vim y Emacs siempre han tenido una gran ventaja. Cada quien valora cosas distintas, pero a mí personalmente la extensibilidad cerrada de VSCode o IntelliJ me parece un gran problema. Cerrada significa API de plugins limitada, entorno de ejecución sandbox, mecanismos de aprobación corporativa, lógica interna opaca, etcétera. Antes me esforzaba por pasar a otro IDE para encontrar nuevas funciones, pero hoy siento que aprender Emacs me acerca más a mis objetivos. La forma de resolver problemas con Emacs es mucho más satisfactoria que con un IDE.
    • La fuerza de Emacs está en el núcleo del intérprete de Lisp: un agente de IA puede inspeccionar y modificar directamente el estado completo del editor en ejecución usando el mismo mecanismo de evaluación que usa el usuario. En la mayoría de los editores, la API de plugins está fijada de forma rígida.
  • Estoy usando con satisfacción el plugin claude-code.el, que aunque es solo un wrapper de terminal, también ofrece un potente menú Transient. Aun si funciona solo dentro de Emacs, ya sube mucho la eficiencia del flujo de trabajo; comparado con el viejo entorno de iTerm, armé un flujo mucho más personalizado y fácil. Voy a seguir de cerca los paquetes nuevos que salgan; también tengo mucha expectativa por eca-emacs. Con herramientas cuya confiabilidad impacta en la productividad, suelo ser cauteloso al introducirlas al principio; a menudo pasan por una fase de "big-bang" donde los proyectos grandes requieren mucho retoque.
    • Lo probé un rato y al final terminé usando solo claude code en terminal otra vez. En Emacs sentía un poco de tirón, y no veía por qué no usar una ventana de terminal aparte. También me faltó que no se conecte con el paquete mcp.el. En la práctica, al usar claude code no he alcanzado todavía una calidad de código utilizable para mi trabajo; también conviene revisar mcp.el.
  • Me alegra que Emacs integre herramientas modernas como LSP, tree-sitter y Claude Code, pero a la vez siento que la complejidad de la configuración subió de verdad. Aunque llevo 20 años usando Emacs, hoy configurar el entorno no es fácil; antes de la integración de Claude Code con IDE fue lo más sencillo (funcionaba y la sincronización automática de buffers casi no exigía atención). En mi nuevo macOS apenas pude correr typescript-ls, pero gopls todavía no termina de descargarse. Con una o dos horas lo arreglaría, pero es engorroso averiguar dónde se traba. Lo comparto porque me intriga cómo lo están haciendo hoy los usuarios de Emacs. Últimamente estoy codificando con gusto con Zed; no es fácil soltar 20 años de adaptación a Emacs. La edición de archivos de configuración pequeños, el soporte para proyectos grandes y la extrema personalización de Emacs siguen siendo extraordinariamente valiosos. Me pregunto si Neovim mejora más por este lado. Me pregunto si necesito aprender mejor debugging de elisp para entender mejor cómo mis comandos actúan en el entorno, y me inquieta si la experiencia en neovim será distinta después de estar acostumbrado a los keybindings de Emacs (¡hasta Dvorak!)
    • Recomiendo totalmente aprender debugging de elisp: aunque lleves décadas con Emacs, hay mucha gente que no conoce el profiler integrado, edebug, apropos, la expansión de macros, el sistema de advising y los buffers indirectos, entre otros. Si comparas Emacs con un auto, es una máquina que puedes armar piezas sobre la marcha y hasta cambiarla por una subacuática; por eso necesitas una mentalidad básica de resolución de problemas y aceptar lo inesperado. Puedes ubicar el punto de falla enseguida y escribir directamente el elisp correcto en el buffer de gptel para hooks o funciones advise y probarlo de inmediato; esa sensación de libertad hay que vivirla. Hoy no me preocupa mantener una configuración "limpia"; me concentro en modular bien y, cuando hace falta, agrego elisp. Si algo se rompe por actualizaciones de otros paquetes o problemas externos, suele bastar con encontrar la falla y crear una solución alternativa en minutos, y pasa de vez en cuando.
    • Para gestionar problemas del entorno, corro Emacs en Docker; recomiendo revisar emacs-native-dockerfiles.
    • Integrar un nuevo ecosistema de lenguajes en Emacs es bastante engorroso porque la elección de paquetes y herramientas externas (como servidores LSP) es complicada; incluso hay muchos proyectos de prueba que implican dudar cada vez. Para la descarga e instalación de herramientas externas, uso Nix (devenv.sh), direnv, etc., de modo que Emacs solo obtiene rutas y no descarga por sí mismo, y guardo la configuración relacionada también en devenv para que el equipo use el mismo entorno.
    • Aunque tengo 8 años de Emacs, hace dos meses cambié por completo a nvim y estuve un mes sin abrir Emacs. Instalé lazy.vim y alterno plugins de IA; recientemente, el ecosistema y la comunidad de nvim están más activos, y ThePrimeagen parece un buen ejemplo.
    • La experiencia con Neovim también ha avanzado mucho: puedes configurar desde barebone hasta funciones completas de IDE; ya hay muchas distribuciones preconfiguradas, así que revisen algo tipo LazyVim. También se puede mirar awesome-neovim #ai para plugins de IA.
  • Hace falta una integración más fuerte con org mode, o más bien funciones de IA para toma de notas en general: con GitHub/copilot, luego de 30 días borra el contenido de la conversación y te perjudica bastante si quieres construir una base de conocimiento con IA; se vuelve urgente un enfoque como notebookllm de Google para gestionar localmente investigación y notas.
    • Recomiendo probar gptel-mode: la conversación se guarda en org buffer, y se pueden guardar y restaurar sesiones fácilmente; además, se integra bien con mcp.el.
    • También vale la pena revisar ob-aider: ob-aider enlace
  • Me encanta mucho que puedas añadir herramientas libremente al servidor MCP; es exactamente lo que esperas de Emacs. Llevo años usándolo y últimamente escribo elisp con más frecuencia, y el soporte de Claude para escribir elisp también es bastante bueno, así que lo uso más seguido (a veces hay que corregir uno solo el orden de paréntesis, pero en general está bien). También voy a probar efrit de Steve Yegge, porque la capacidad del agente de ejecutar expresiones elisp arbitrarias eleva otro nivel las posibilidades de Emacs. efrit
    • Soy un seguidor y fan de Yegge desde hace tiempo; aún creo que estamos en la luna de miel de vibe code, pero su capacidad con Emacs supera a la de cualquiera. Me di cuenta hace 1 o 2 años de que los LLM grandes son raramente buenos con elisp, y eso fue el origen del proyecto hipermoderno; veo a efrit como muy prometedor (aunque todavía no lo tengo totalmente configurado).
  • Al mismo tiempo han aparecido más de 5 paquetes de integración Emacs/Claude Code, y en dos o tres, sobre todo en Reddit, la competencia se ve intensa; es interesante, aunque parece que los plugins realmente buenos existen en silencio y casi nadie los menciona. El paquete yuya373/claude-code-emacs ya implementa casi todas las funciones de los competidores.
    • No sé cuánta popularidad tiene, pero parece el más fácil de instalar; revisa melpa claude-code
    • Ese paquete parece no incluir la integración /ide de Claude-code-ide.
  • Recomiendo también probar eca; está enfocado en construir la mejor herramienta de pair programming con IA en Emacs.
  • He sentido que en la comunidad de Emacs últimamente hay una atmósfera que critica esa discusión de integración con IA, pero honestamente creo que causa más perjuicios que beneficios. Incluso si la IA evoluciona distinto a la generación actual, creo que el origen de Emacs está en el MIT AI Lab, y es raro que un grupo de herramientas nacido ahí se rechace en ese contexto.
    • La belleza de Emacs es el control centrado en el usuario: puede cambiarse todo desde la capa de Elisp según lo que necesites, por eso estos paquetes siguen apareciendo. VS Code, en cambio, induce división estructural; Microsoft usa APIs propietarias para sus herramientas exclusivas y da una API de extensión muchísimo más limitada para afuera, por eso hay tantos forks de vscode. En Emacs, con un solo desarrollador de Elisp con pasión y habilidad puedes cambiarlo todo y siempre pueden aparecer nuevos módulos de integración de IA/LLM. Siento que la crítica en la comunidad de Emacs está algo sobredimensionada; de hecho, siguen saliendo constantemente plugins de IA/LLM con buena recepción, por ejemplo gptel.
    • El origen de esta atmósfera está en Richard Stallman: él cree que la integración de alternativas de "software no libre" debe evitarse cuando un proyecto de software libre no está listo. Esa posición provocó demoras en decisiones como GCC extensions, depurador LLVM, tree-sitter, git/bzr y CI build farms, y durante ese tiempo se retrasó la adopción de reemplazos para proyectos núcleo como Emacs; al final siempre terminamos aceptándolos tarde, y a veces parece que era para proteger el lugar de la FSF.
    • La comunidad de Emacs es súper diversa: siempre hay críticas, pero no hay que hacerse ruido; con módulos de terceros se puede agregar cualquier función, y no hay forma de que el mantenedor principal lo impida.
    • Me enteré de que el MIT AI Lab está conectado con el boom de IA moderno, y me parece interesante.
  • Estoy muy ilusionado con estas herramientas y me encanta integrar Emacs y la IA en mi flujo de codificación; pero, sobre todo, quiero ejecutarlo localmente en hardware por debajo de $2000. Me pregunto si esto es posible hoy o en el futuro cercano y si alguien acá ya usa agentes de codificación con modelos locales.
    • Se están haciendo avances enormes en inferencia eficiente de memoria y en modelos abiertos orientados a código; ahora los modelos Qwen3-Coder son muy comentados (Qwen3-Coder). Para ejecución local hay herramientas como Ollama y LM Studio. Según el tamaño y cuantización del modelo, con presupuesto de $2000 se pueden correr muchísimos modelos; los Mac de la serie M también tienen buena relación costo/rendimiento. El subforo LocalLlamas tiene mucha info de LLM local. No es el nivel de un laboratorio de IA grande, pero si se prefiere un setup completamente local, sí vale mucho como proyecto interesante para probar.
    • gptel soporta varios modelos, incluyendo locales.
    • También son opciones MacMini o frame.work desktop, o Nvidia DGX Spark (precio mínimo de 3k)