1 pontos por GN⁺ 2025-08-07 | 1 comentários | Compartilhar no WhatsApp
  • Claude Code IDE for Emacs integra nativamente o Claude Code CLI ao Emacs, fornecendo um ambiente robusto de assistente de codificação com IA.
  • Através de uma ponte bidirecional baseada no Model Context Protocol (MCP), o Claude consegue utilizar diversos recursos do Emacs, como LSP, gerenciamento de projetos e funções Elisp.
  • Oferece recursos otimizados para o ambiente Emacs, como detecção automática de projetos, múltiplas sessões, integração de diagnóstico (erro/aviso), diff avançado, rastreamento de tab-bar e de seleção/buffer.
  • Com os comandos e a extensibilidade do Emacs, é possível expor comandos diretamente e integrar fluxos de trabalho personalizados por meio de um servidor MCP.
  • Por meio de uma conexão profunda entre o Claude e todo o ecossistema do Emacs, constrói-se um ambiente de desenvolvimento com suporte de IA em nuvem.

Visão geral

Claude Code IDE for Emacs é um projeto de código aberto que maximiza as capacidades da IA Claude dentro do Emacs por meio da integração com o Claude Code CLI. Diferente de wrappers de terminal simples, este pacote oferece uma ponte baseada em MCP (Model Context Protocol) com comunicação bidirecional, permitindo que o Claude realmente aproveite recursos internos do Emacs. Ao conectar com o ecossistema poderoso do Emacs, como LSP, gerenciamento de projetos e funções Elisp, ele implementa um ambiente de suporte ao desenvolvimento por IA produtivo e inteligente para usuários de Emacs.

Principais recursos

  • Detecção automática de projeto e gerenciamento de sessão

    • Usa o project.el embutido no Emacs para reconhecer projetos automaticamente e separar sessões
    • Fornece instância e buffer individuais do Claude Code por projeto
  • Integração de terminal e suporte a cores

    • Suporte a terminal colorido via vterm ou eat
    • Conversa com o Claude dentro do Emacs
  • Integração de IDE via protocolo MCP

    • Exposição de vários comandos do Emacs (navegação de código, consulta de símbolos, análise AST etc.) em um servidor MCP
    • Permite ao Claude executar comandos do Emacs e funções personalizadas
  • Servidor de Tools MCP de alta extensibilidade

    • Possível adicionar/definir ferramentas MCP personalizadas (por exemplo: busca em projeto inteiro, refatoração global etc.)
  • Diagnóstico de código e diff

    • Fornece informações de diagnóstico de erros/avisos de código por meio de integração com Flycheck e Flymake
    • Suporte para view de diff avançado usando ediff e acesso a dados de diagnóstico
  • Gerenciamento de mudança de estado/comandos

    • Com tab-bar, rastreamento de seleção e buffer, o Claude pode entender o contexto atual do usuário

Integração de ferramentas do Emacs

Claude Code IDE expõe diretamente diversos comandos e informações do Emacs ao Claude via sistema de ferramentas MCP.

  • Integração com LSP (xref)

    • Suporte a navegação inteligente baseada em LSP, incluindo go-to-definition e busca de símbolos/consultas em nível global do projeto
  • Suporte a Tree-sitter

    • Fornece compreensão da estrutura do código por meio de análise de árvore de sintaxe e AST (Árvore de Sintaxe Abstrata)
  • Integração com Imenu e Project

    • Disponibiliza automaticamente listas de símbolos, arquivos do projeto e informações de estrutura
  • Funções Elisp personalizadas

    • Exposta diretamente como MCP tool para aproveitar fluxos de trabalho e funcionalidades de domínio específico

Essa integração permite que o Claude utilize informações de contexto do ecossistema Emacs para oferecer suporte de IA preciso em nível de código.

Uso

Comandos principais

  • M-x claude-code-ide-menu: abre o menu transitório com todos os comandos disponíveis
  • Ativa o Claude Code no projeto, envia prompts, retoma conversas anteriores e oferece diversos recursos de estado/gerenciamento de sessão
  • É possível gerenciar vários projetos simultaneamente, com sessão Claude dedicada por projeto

Gerenciamento de janela e sessão

  • Se uma nova sessão já estiver em execução, apenas alterna/mostra a janela
  • Mesmo ao fechar a janela com o comando padrão do Emacs (C-x 0), o próprio Claude não é encerrado

Configurações

  • Suporte a personalização detalhada de Claude Code CLI, backend de terminal, backend de diagnóstico, posição/tamanho da janela e opções de depuração
  • Opções avançadas como adição de flags, definição de system prompt, função de nomeação de buffer, entre outras
  • Possível ativar servidor MCP e definir ferramentas/porta usadas

Configuração do backend de terminal

  • O padrão é vterm, com opção de alternar para o backend eat quando necessário
  • O eat é um terminal baseado em Elisp puro, útil quando houver problemas de build do vterm
  • Atalhos dedicados disponíveis (M-RET: quebra de linha no prompt, C-<escape>: sair/cancelar, entre outros)

Opções de diagnóstico/depuração

  • Flycheck e Flymake podem ser detectados e integrados automaticamente ou definidos manualmente
  • Opção temporária para evitar o bug de reflow do terminal do Claude (#1422)
  • Suporte a logs detalhados de depuração no nível do Emacs e do CLI (visualização de mensagens WebSocket, JSON-RPC etc.)

Avançado: vários worktrees, operação de sessão

  • Utiliza git worktree para executar várias sessões independentes de branches dentro do mesmo projeto
  • Mantém buffer e contexto exclusivos por grupo de tarefas, suportando fluxos de trabalho paralelos

Detalhes das MCP Tools do Emacs

Exemplos de MCP Tools integradas

  • xref-find-references: busca total de referências de um símbolo específico dentro do projeto
  • xref-find-apropos: busca global de código/símbolos baseada em padrão
  • treesit-info: fornece dados de análise AST com base em tree-sitter
  • imenu-list-symbols: exibe todas as funções e variáveis do arquivo
  • project-info: fornece metadados e arquivos do projeto atual

Adição de ferramentas personalizadas

  • Usuários podem adicionar suas próprias funções do Emacs conforme o formato de ferramentas MCP
  • Como exemplo, é possível definir uma ferramenta de busca de código com ripgrep ou comandos específicos de domínio e chamá-los diretamente pelo Claude

Licença e projetos relacionados

  • Disponível sob GNU GPL v3.0 ou superior
  • Cita projetos relacionados, como integrações para VS Code, Neovim (claudecode.nvim) e outros plugins

Importância e vantagens

O Claude Code IDE for Emacs oferece um ambiente de IDE de IA poderoso que, ao contrário das ferramentas de integração de LLM/IA existentes, consegue aproveitar ativamente o contexto de trabalho e as informações do ecossistema exclusivos do Emacs. Mesmo em uma fase relativamente inicial, já traz vários recursos integrados, alto potencial de personalização e suporte a múltiplos projetos, sendo uma escolha muito forte para usuários de Emacs e desenvolvedores de código aberto.

1 comentários

 
GN⁺ 2025-08-07
Opinião no Hacker News
  • Assim como LSP e tree-sitter, ferramentas de codificação com IA como Claude Code ou Aider são uma ótima notícia para editores como Emacs e Vim, que geralmente ficam fora do mainstream, porque não é mais preciso gastar energia implementando recursos de IDE avançados como antes; dá para integrar facilmente com essas ferramentas e focar em diferenciais de edição próprios. Na prática, esse tipo de customização e integração flexível deixa a competitividade desses editores muito maior.
    • Fiquei curioso se existe um padrão para integrar ferramentas de programação orientadas por agente no editor, como o LSP.
    • Sempre achei que isso sempre foi assim: Emacs e Vim já tinham recursos de IDE avançados no passado; com LSP e tree-sitter, a padronização entre editor e linguagem ficou mais fácil.
    • Não concordo que Emacs e Vim sejam editores de nicho; já são editores já consagrados.
  • Sempre pensei que o Emacs seja o melhor editor para agentes de IA: o agente consegue inspecionar facilmente o estado inteiro do editor e mudar o comportamento por meio de elisp. Acho que editores que permitem customização no nível de Vim ou Emacs vão manter uma grande vantagem no futuro.
    • Vim e Emacs sempre tiveram uma vantagem enorme, mesmo que cada pessoa avalie isso de um jeito. Pessoalmente, considero uma grande limitação do VS Code ou IntelliJ a extensibilidade fechada, o que inclui API de plugins limitada, ambiente de execução em sandbox, processos de aprovação corporativos e opacidade da lógica interna. Antes eu tentava migrar para outras IDEs para usar funcionalidades novas, mas hoje sinto que apenas aprender Emacs me aproxima melhor dos meus objetivos; resolver problemas no Emacs é muito mais satisfatório do que em uma IDE.
    • O ponto forte do Emacs está no núcleo do interpretador Lisp: o agente de IA pode inspecionar e alterar diretamente todo o estado do editor no runtime, usando o mesmo mecanismo de avaliação que eu utilizo; na maioria dos editores, a API de plugins é rígida e fixa.
  • Tenho usado com satisfação o plugin claude-code.el. Embora seja só um wrapper de terminal puro, também oferece um menu Transient poderoso. Só executando dentro do Emacs, já melhora bastante a eficiência do fluxo; comparado ao antigo ambiente do iTerm, foi muito mais fácil criar um fluxo customizado. Vou ficar de olho nos pacotes novos conforme saírem. Também espero muito do eca-emacs. Ferramentas em que confio produtividade eu costumo adotar com cautela no início, pois geralmente passam por um período de grande acabamento, principalmente em projetos grandes.
    • Testei por um tempo e acabei voltando a usar só o Claude Code no terminal. No Emacs ficava um pouco travado, e eu não tinha motivo para abrir uma janela de terminal separada; também senti falta de ele não integrar com o pacote mcp.el. Na prática, quando usei Claude Code no meu trabalho, ainda não consegui chegar a uma qualidade de código que considerasse boa o bastante, e o mcp.el também vale a consulta.
  • É animador ver o Emacs incorporando ferramentas recentes como LSP, tree-sitter e Claude Code, mas ao mesmo tempo sinto que a dificuldade de setup aumentou mesmo. Mesmo sendo usuário de Emacs há 20 anos, hoje configurar ambiente não é simples. Antes da integração de IDE do Claude Code parecia a parte mais fácil (rodava e quase não tinha preocupação com sincronização automática de buffers). Em um novo macOS, mal consegui subir o typescript-ls e o gopls ainda nem foi baixado. Talvez em uma ou duas horas eu conseguisse consertar, mas é chato descobrir onde trava. Compartilho isso por curiosidade sobre como os usuários de Emacs lidam hoje com isso. Atualmente estou codando com o Zed e me divertindo, mas não é fácil abrir mão de 20 anos de adaptação ao Emacs. Desde a edição de arquivos pequenos até suporte a projetos em grande escala, e customização extrema, ele ainda é precioso. Fiquei curioso para saber se o Neovim está indo melhor nessa frente, e se preciso aprender melhor debugging de elisp para entender com mais clareza como meus comandos atuam no ambiente. Também me preocupo com a diferença que pode dar ter experiência no neovim, já que já estou acostumado aos keybindings do Emacs (até mesmo no Dvorak!).
    • Recomendo debug de elisp sem dúvida. Mesmo quem usa Emacs há décadas não conhece built-in profiler, edebug, apropos, macroexpansion, advising system, buffer indireto... Em termos de analogia, o Emacs é uma máquina na qual você pode montar componentes enquanto dirige e até trocar por um submarino; então faz sentido ter uma postura de resolução de problemas básica e de aceitação de cenários inesperados. Dá para achar o ponto do problema e testar rapidamente no buffer do gptel o elisp certo para hook ou função advise, e essa sensação de liberdade precisa ser vivida. Hoje em dia nem me importo em manter uma configuração "limpa"; deixo tudo bem modularizado e vou adicionando elisp conforme necessário. Mesmo quando quebra por atualização de outros pacotes ou problemas externos, geralmente em alguns minutos já encontramos a causa e criamos uma alternativa — e isso é pouco frequente.
    • Para gerenciar questões de ambiente, rodo o Emacs em Docker. Dê uma olhada no emacs-native-dockerfiles.
    • Integrar uma nova linguagem ao Emacs continua relativamente trabalhoso na escolha de pacotes e ferramentas externas (como servidores LSP etc.), especialmente porque existem muitos projetos de nível “dabbling”, então isso tem que ser pensado toda hora. Na prática, para baixar/instalar ferramentas externas uso Nix (devenv.sh), direnv e afins, para garantir que o Emacs só receba o PATH e não faça download direto; também guardo as configs relacionadas no devenv para que os colegas usem o mesmo ambiente.
    • Embora seja usuário de Emacs há 8 anos, há dois meses migrei totalmente para nvim e fiquei um mês sem abrir o Emacs. Instalei o lazy.vim e estou alternando plugins de IA. O ecossistema e a comunidade do nvim estão recentemente, na minha impressão, até mais ativos; ThePrimeagen é uma referência.
    • A experiência com Neovim também evoluiu bastante; dá para configurar desde barebone até funcionalidades completas de IDE de várias formas. Já existem muitas distribuições pré-configuradas; vale conferir algo como o LazyVim. Para plugins de IA, veja também awesome-neovim #ai.
  • Sinto falta de uma integração mais forte com org mode, ou de recursos de IA mais abrangentes para tomada de notas. No GitHub/Copilot, depois de 30 dias, eles apagam o histórico de conversa, e isso impacta muito ao tentar construir uma base de conhecimento com IA. Precisa ser forte algo que permita gerenciar pesquisa e registros localmente, como o notebookllm do Google.
    • Recomendo testar o gptel-mode: as conversas ficam salvas no buffer org, e é fácil salvar e restaurar sessões; também integra bem com o mcp.el.
    • O ob-aider também vale a pena, link do ob-aider.
  • Fiquei muito satisfeito com a capacidade de adicionar ferramentas livremente a um servidor mcp — do jeito Emacs. Uso elisp há anos, e ultimamente tenho escrito mais direto; como o Claude também dá bom suporte para escrever elisp, estou usando cada vez mais (às vezes ainda corrijo a indentação de parênteses manualmente, mas no geral está bom). Vou com certeza testar o efrit do Steve Yegge. A função de o agente usar e executar expressões elisp arbitrárias eleva mais um nível o limite do Emacs. efrit
    • Sou fã e seguidor antigo do Yegge, e vejo a fase de vibe code como uma lua de mel ainda, mas sua expertise em Emacs é de uma excelência acima de qualquer um. Há 1 a 2 anos percebi que modelos grandes de linguagem são estranhamente bons em elisp, e isso foi o ponto de partida desse projeto hiper-moderno; acho o efrit muito promissor, apesar de ainda não estar totalmente configurado.
  • Ao mesmo tempo, surgiram mais de cinco pacotes de integração Emacs/Claude Code, e dois ou três parecem disputar ferozmente em Reddit e similares; o interessante é que plugins realmente bons ficam em silêncio e parecem não ser mencionados. O pacote yuya373/claude-code-emacs já implementa quase tudo que os concorrentes fazem.
    • Não sei quão popular ele é, mas parece o mais fácil de instalar; dá uma olhada no melpa claude-code.
    • Parece que esse pacote não tem a integração /ide do Claude-code-ide.
  • O eca também é altamente recomendado; estão focados em construir a melhor ferramenta de pair programming com IA no Emacs.
  • Tenho percebido um clima de crítica na comunidade Emacs justamente contra essa discussão de integração de IA, mas, sinceramente, acho que isso traz mais prejuízo que benefício. Mesmo que a IA evolua diferente da forma dessa geração, eu vejo a raiz do Emacs no MIT AI Lab; com isso, é estranho esse incômodo com ferramentas que surgem de tais AI working groups.
    • A beleza do Emacs está no controle centrado no usuário. Como dá para alterar o que quiser na camada Elisp, esses pacotes aparecem sem parar. Já o VS Code é estruturalmente desenhado para dividir, e a Microsoft usa uma API proprietária para suas próprias ferramentas e entrega para fora uma API de extensão bem mais restrita, por isso surgem tantos forks do vscode. No Emacs, basta um único desenvolvedor de Elisp com muita paixão e habilidade para mudar tudo, e novos módulos de integração com IA/LLM podem surgir à vontade. Também acho que a crítica da comunidade Emacs aqui é, em parte, exagerada; na prática, plugins de IA/LLM continuam saindo com boa aceitação, e um bom exemplo é gptel.
    • Acho que isso acontece por causa do Richard Stallman: ele acredita que, quando projetos de software livre não estão prontos, deve-se ficar de olho para não integrar alternativas de “software não livre”. Essa postura causou atrasos em decisões envolvendo GCC extensions, depurador LLVM, tree-sitter, git/bzr, CI build farms etc., e nesse período só atrasou a adoção de substitutos para projetos centrais como o Emacs; no fim, é sempre adotado mais tarde. Às vezes parece também uma postura de proteger a posição da FSF.
    • A comunidade Emacs é super diversa; tem crítica em todo lugar, mas não precisa ligar pra isso. Com módulos de terceiros, dá para adicionar qualquer recurso que você queira, e o mantenedor principal não tem como barrar.
    • Descobrir que o MIT AI Lab está conectado ao boom atual de IA foi interessante.
  • Essas ferramentas são super empolgantes, e gosto de incorporar Emacs e IA ao meu fluxo de código, mas o que mais quero é rodar isso localmente em hardware próprio abaixo de $2000. Fiquei curioso se isso é viável hoje ou no futuro próximo, e se alguém já está usando um agente de programação com modelos locais.
    • Houve avanços enormes em inferência eficiente em memória e modelos especializados em código open source. Atualmente os modelos da família Qwen3-Coder estão ganhando muita atenção (Qwen3-Coder); para execução local existem ferramentas como Ollama e LM Studio. Dependendo do tamanho do modelo e da quantização, com orçamento de $2000 dá para rodar muitos modelos; os Macs da linha M também têm boa relação custo-benefício. Há muita informação sobre uso de LLM local em LocalLlamas, e apesar de não atingir o nível de laboratórios de pesquisa de grandes AI labs, é um projeto bastante interessante e factível se você prefere configuração totalmente local.
    • O gptel suporta vários modelos, inclusive locais.
    • MacMini, frame.work desktop, ou Nvidia DGX Spark também são opções (a partir de 3k)