Ainda tem gente usando Emacs?

• Depois de começar no Linux em 1997, alternando entre Vim e Emacs, essa trajetória migrou para VSCode e IntelliJ em 2015, até voltar ao Doom Emacs em 2022 no ambiente de Linux VM remota da Snowflake
• O VSCode facilitou aprendizado e desenvolvimento com UI moderna, porte enxuto, configuração baseada em JSON e integração com LSP para Go e Rust; no desenvolvimento Java, o IntelliJ era a escolha mais realista
• Nas antigas Linux VMs da Snowflake, o foco era escrever shell scripts e arquivos de build do Bazel, e o trabalho via SSH combinava melhor do que um ambiente gráfico remoto, o que fez o Emacs voltar a ser necessário
• O Doom Emacs, com padrões razoáveis, integração de linguagens, atalhos no estilo Vim, menus pop-up baseados em space e uma estrutura simples de arquivos de configuração, faz o Emacs parecer uma IDE
• O principal motivo para continuar usando Emacs é conseguir manter o mesmo ambiente de desenvolvimento em qualquer lugar, só com shell, tmux e Emacs, seja em MacBook, notebook Linux, workstation Linux na nuvem ou servidor FreeBSD

---

De IDEs de DOS/Windows para editores no Linux

• Por volta de 1997, comecei no Linux com o Caldera OpenLinux 1.1
• Antes disso, eu usava bastante Borland Turbo C++ e Visual Basic, então já estava acostumado com as IDEs bem acabadas da época
• Conheci Vim e Emacs por meio de dois livros introdutórios sobre Linux, e ambos eram apresentados como opções avançadas
• As IDEs que eu usava antes pareciam mais completas, mas aprendi o uso básico e os tutoriais de Vim e Emacs
• Até por volta de 2015, fui alternando entre Vim e Emacs
  • O Emacs funcionava melhor para sessões longas de programação
  • O Vim era mais forte para ir e voltar rapidamente entre vários arquivos e fazer edições, como em trabalhos com pkgsrc

Por que migrei para VSCode e IntelliJ

• Embora Vim e Emacs funcionassem bem, a integração com linguagens era fraca, então comecei a me interessar por editores mais modernos
• Ao migrar para o macOS, também experimentei Atom e Brackets, mas eles pareceram frágeis e pesados demais por causa do excesso de recursos e configurações
• O VSCode, que surgiu em 2015, desde o início pareceu a ferramenta certa
  • Tinha aparência moderna e era relativamente enxuto
  • Na época, o editor de configurações era baseado em arquivos JSON, sem painel de ajustes, e isso me parecia mais fácil de controlar
• Quando comecei a aprender Go e Rust, a integração com LSP de cada linguagem no VSCode ajudou bastante
  • Autocompletar de código
  • Destaque de erros em tempo real
  • Aprendizado mais rápido
• Ao lidar no Google com projetos Java usando Bazel, o IntelliJ era a escolha natural
  • Até tentei desenvolver Java com Emacs, mas o IntelliJ era tão bom que, na prática, ele era a escolha realista
• Na Microsoft, mesmo trabalhando com uma base de código em C++ e máquinas Windows remotas, continuei usando VSCode com plugin do Vim
  • Muita gente trabalhava diretamente na máquina remota via RDP
  • Eu preferia rodar o VSCode no desktop local e acessar a máquina remota por SSH

O que me levou de volta ao Doom Emacs na Snowflake

• Depois de ir para a Snowflake em 2022, o desenvolvimento acontecia dentro de antigas Linux VMs, e o trabalho do dia a dia era escrever shell scripts e arquivos de build do Bazel
• Nesse ambiente, VSCode e IntelliJ não resolviam o problema, e eu também não gostava das limitações do ambiente gráfico remoto, então voltei ao modelo de acessar uma VM local por SSH
• Passei a precisar novamente de um editor para longas sessões de trabalho, e a escolha foi o Emacs
• Meu antigo init.el tinha centenas de linhas de configuração acumuladas ao longo dos anos, mas eu não entendia bem o conteúdo e queria jogar tudo fora para recomeçar
• Foi nesse momento que conheci o Doom Emacs
  • O Doom Emacs é uma “distribuição” do Emacs já configurada desde o início
  • Oferece padrões razoáveis
  • Traz integrações de linguagem pré-definidas
  • Proporciona uma experiência familiar para ex-usuários de Vim
  • Não afirma ser uma IDE, mas na prática a sensação de uso é de uma IDE

Como o Doom Emacs mudou a experiência de uso

• Depois de configurar o Doom Emacs, o Emacs voltou a parecer a “ferramenta certa”, como tinha acontecido com o VSCode em 2015
• Muitos recursos do Emacs passaram a ficar visíveis por meio de menus pop-up interativos atrás de atalhos baseados em space, o que facilitou descobri-los
• Ele convive com atalhos no estilo Vim e, ao mesmo tempo, oferece um fluxo de atalhos que pesa menos no pulso
• A configuração é dividida em três arquivos simples
  • config.el: define configurações globais, como theme e font
  • init.el: escolhe quais módulos específicos do Doom serão ativados
  • packages.el: instala pacotes que não vêm incluídos no Doom
• Os padrões são razoáveis, e os detalhes que vale ajustar têm comentários suficientes
• Graças à evolução do LSP e a recursos modernos como tree-sitter, o Emacs agora parece uma IDE
  • Em praticamente todas as linguagens com que preciso lidar, consigo uma integração decente

O valor de usar o mesmo ambiente em qualquer lugar

• O recurso mais poderoso é conseguir o mesmo ambiente de desenvolvimento independentemente da máquina em que estou trabalhando
• Isso inclui MacBook, notebook Linux, workstation Linux na nuvem e até um servidor FreeBSD pessoal
• Tudo o que preciso é de shell, tmux e Emacs
• Ao trabalhar em máquinas diferentes, ter o mesmo ambiente e a mesma memória muscular traz valor direto para a produtividade
• Por causa dessa necessidade, o Emacs se tornou uma ferramenta ainda mais importante do que já foi no passado

O Doom Emacs faz coisas demais?

• Há reclamações de que o Doom Emacs “faz coisas demais”, mas ele é útil justamente porque faz muita coisa
• Às vezes penso se um dia vou reduzir a configuração para aprender mais sobre o próprio Emacs
• O fato de vários módulos modernos de terceiros estarem entrando nos pacotes padrão do Emacs também reforça essa dúvida
• Recentemente, também tive vontade de experimentar distribuições como Bedrock ou Emacs Solo
• Mas a energia de ativação necessária para a transição é alta e, mesmo seguindo esse caminho, eu acabaria me perguntando de novo por que não ir até o Emacs “raw”

Distanciamento em relação a Elisp, Org mode e Magit

• Ainda não entendo completamente como o fato de o Emacs ser baseado em Elisp muda tão profundamente o fluxo de trabalho das pessoas
• Dá para implementar mais lógica e fluxos de trabalho dentro do Emacs, mas eu já resolvo quase tudo facilmente com shell scripts
• Scripts parecem mais fiéis ao Unix, dentro da visão de que “Unix is my IDE”
• Não gosto que Org mode e Magit estejam presos ao Emacs em vez de serem aplicações independentes
• Enquanto continuar existindo a necessidade de trabalhar constantemente em máquinas remotas diferentes, o Emacs seguirá sendo uma ferramenta importante

[GN⁺]

Comentários do Lobste.rs

• Escrevi este post porque o assunto é engraçado demais
  Não por causa de uma pergunta específica, mas porque estou vendo gente em cargos altos nas empresas “descobrir” as ferramentas de linha de comando ao usar agentes de programação baseados em CLI, e querer mostrar o quanto essa nova descoberta é útil
  Até agora o caso mais representativo é o tmux, e agora estou só esperando perceberem que Vim e Emacs também existem
  Essas ferramentas sempre estiveram por aí, e se você perguntar a algum “desenvolvedor 10x sênior” da empresa, ele provavelmente vai dizer que usa
  Mesmo assim, o tratamento comum sempre foi algo como “haha, isso é relíquia antiga. Vamos de web!!11” Talvez esses desenvolvedores tivessem um motivo para continuar usando essas ferramentas ;P

  • Uma coisa boa da “bolha de produtos gerados de baixa qualidade” é que o texto puro está voltando a ser um meio válido e importante
    Isso inclui a CLI ficar mais comum e muito conhecimento que antes era passado oralmente acabar sendo documentado. Claro, com a condição de ser conhecimento produzido por pessoas
    Espero que essa parte boa permaneça mesmo depois de passarmos pela fase ruim atual
  • A maioria dos usuários de Emacs provavelmente usa em GUI
    Não tenho números, mas imagino que seja uma maioria esmagadora

• Eu também entro no grupo de quem começou a aprender agora
  Testei o Doom Emacs alguns anos atrás, mas achei lento a ponto de a latência incomodar, então acabei desistindo. Não sei se isso já ficou no passado graças à compilação nativa; como ainda estou num Emacs padrão, sem configuração, é difícil sentir isso na prática. Estou usando o 30.2 do Nixpkgs, e parece que a compilação nativa vem ativada por padrão
  Não tenho muito interesse em coisas como escrever e-mail dentro do Emacs; eu preciso de um editor que eu possa moldar do jeito que quero. Também seria bom se servisse quando eu quiser aprender Lisp mais pra frente, e provavelmente vai ser Janet. O Helix ainda não tem plugins, então no lado de Lisp quase não há opções. Também gosto da filosofia de que “tudo é texto”, mas ainda preciso ver se isso vai combinar comigo na prática
  Para aprender em 2026, também há um certo peso. Por causa de conhecimento tácito acumulado ao longo de décadas, quando você lê textos aparecem nomes de pacotes, nomes de comandos etc. para todo lado, e isso é avassalador quando você só quer fazer $THING. Então peguei Mastering Emacs como caminho de aprendizado guiado
  As teclas padrão também são bem estranhas. Eu sei que dá para remapear tudo, mas isso dá mais trabalho. Além disso, eu mesmo montei um teclado ergonômico dividido e também ajustei o firmware para um fluxo de trabalho no estilo Vim/Helix, que não usa teclas modificadoras como parte central
  Como fico alternando entre MacBook Pro, PC e teclado customizado, preciso encontrar um conjunto de atalhos consistente que não derreta meu cérebro. hjkl fica na mesma posição em qualquer teclado, mas teclas como Ctrl não

  • Se os atalhos são difíceis e você está mais acostumado com o lado do Vim, vale olhar o evil
    Você pode ouvir a bronca de que evil é para refugiados do Vim que não querem aprender “o verdadeiro evangelho do Emacs”, mas o verdadeiro evangelho do Emacs® é usá-lo da maneira que funciona melhor para você
    Uso Emacs desde 1998 e nunca fui particularmente fã de Vim. Por volta de 2011 comecei a ter um pouco de lesão por esforço repetitivo no punho, então experimentei pacotes que ajudassem a reduzir isso; usei bastante o god mode por alguns anos, mas ainda assim parecia estranho
    Aí resolvi testar o evil “para provar que não daria certo”, mesmo sem nunca ter usado Vim na vida, e em uma semana eu já tinha tanta desenvoltura quanto com o god mode; depois de um mês, eu já era mais rápido do que quando usava os atalhos oficiais do Emacs
    Isso não quer dizer que os atalhos padrão estejam errados. Meus punhos não são bons, então sua experiência pode ser diferente. boon ou meow também podem combinar melhor com você
    Mas, se evil funcionar bem para você, não precisa sentir culpa nenhuma. O Emacs muda o usuário, sim, mas muito mais do que isso, o Emacs muda para servir ao usuário
  • O Doom realmente muda bastante dependendo de como você configura. Isso também vem melhorando com o tempo
    O ideal é montar sua própria configuração, mas dá trabalho, e projetos como o Doom com certeza tornam a entrada de novos usuários bem mais fácil
  • O fato de os atalhos padrão serem estranhos foi justamente algo de que gostei no Doom Emacs
    No passado eu conhecia razoavelmente bem os atalhos padrão do Emacs, mas nunca achei que fossem naturais, e principalmente eram pouco descobríveis
    O Doom Emacs usa uma tecla de prefixo SPC para quase tudo, e se você parar por um instante aparece um menu temporário explicando as conclusões possíveis, o que é bem legal. Dá para descobrir recursos que você não conhecia, e isso não entra em conflito com o modo modal do Vim
    Por isso, uma configuração em que a edição de texto fica no modo Vim e as ações do Emacs ficam nas combinações com SPC parece um bom equilíbrio
    Os atalhos padrão do Emacs também têm vantagens. As teclas básicas de manipulação de texto são compartilhadas com o readline e até com o macOS. As teclas de gerenciamento de texto no estilo Emacs do macOS chegaram até ao VSCode e não conflitam com os atalhos padrão de clipboard, então o VSCode no macOS era bem bom
    Depois que mudei para Windows e Linux, ficou muito difícil aguentar o VSCode sem plugin de Vim
  • Se você veio do Helix, talvez também valha olhar o meow
    Ouvi dizer que ele oferece por padrão recursos parecidos com Kakoune e Helix, e tenta ser menos intrusivo. Não usei nenhum dos dois diretamente, então estou falando com base no que ouvi
    Acho que o pacote evil recomendado tem o problema de tomar controle demais dos atalhos e não se dar muito bem com pacotes externos, o que acaba exigindo muitos pacotes “adaptadores”
    O meow, depois de configurado uma vez, exigiu bem menos manutenção

• Uso há 33 anos, e ele faz tudo de que preciso em um editor ou IDE

• Fiquei indo e voltando entre Doom e (n)vim, mas recentemente acabei ficando quase sempre no Neovim
  O principal problema que tive usando Emacs foi, ironicamente, que a manutenção era dolorosa. Quando eu atualizava o Doom, a sincronização dos pacotes saía do eixo e muitas vezes só sobrava a opção nuclear de reinstalar tudo do zero
  Claro que eu poderia ter consertado isso de um jeito menos “iniciante”, mas a certa altura a gente só quer que a ferramenta funcione. Quando há trabalho a fazer, é difícil lidar com configurações quebradas e com uma dependência excessiva do editor
  Ainda assim, sinto falta do org-mode e da forma geral de navegação do Emacs
  Toda vez que tento soluções “modernas” como VSCode e CLion, acabo tendo ainda mais desses problemas. Falta acessibilidade de verdade, então em vez de navegação puramente por teclado preciso clicar de forma meio estranha, e o comportamento “Vim” também é incompleto comparado ao original
  Hoje uso Neovim simplesmente porque ele funciona bem. Na verdade, se eu tivesse pedido para um agente de código corrigir minha configuração por 2 minutos, talvez pudesse dizer exatamente o mesmo do Emacs atual (:

  • Tentei o recurso update do Doom algumas vezes, mas sempre dava problema
    Hoje em dia, sempre que quero atualizar ou preciso por causa de uma atualização do Emacs, apago com rm -rf ~/.emacs.d/ e configuro o Doom do zero. Deixo ~/.doom.d/ sob controle de versão
    Nesse fluxo, não tive problemas

• Sou o tipo excêntrico que faz desenvolvimento, escrita e e-mail no Emacs, e já faz uns 15 anos, mas nunca consegui achar tempo ou disposição para aprender elisp
  Mesmo quando mexo nos arquivos de configuração, na verdade não entendo muito bem o que estou fazendo. Ainda assim, ele continua sendo o ambiente em que sou mais produtivo, o que mostra o quão impressionante esse editor é :-)
  Ler Mastering Emacs de verdade está na minha lista de pendências há tanto tempo que até dá vergonha admitir

  • Também sou quase assim. De tanto ajustar configurações e editar coisas, acabei aprendendo um pouco de elisp por osmose, mas sei tão pouco na prática que dá até vergonha
  • M-x high-five
    No meu caso também uso pouquíssimos pacotes e fico com os atalhos padrão. A função high-five nem existe de verdade, mas talvez essa seja a deixa para eu finalmente mergulhar em elisp

• Não gostava da renderização do Vim e já estava cansado de Electron/VSCode e afins, então migrei para o Emacs há cerca de 2 anos
  Fiquei obcecado por avy e alguns plugins de salto, mas o que me prendeu e ainda hoje faz dele minha principal ferramenta para mudanças em código é o magit

• A empresa cliente com que lido no trabalho depende, em toda a operação, do uso de arquivos CSV enormes, mas por lá ninguém parece saber como abrir ou inspecionar dados em um arquivo de 1 GB
  Nem conhecem o comando head para pedir só o cabeçalho do CSV

• Depois de anos usando X/GUI, acabei de mudar para -nw
  Só uso a versão Pgtk quando vou fazer apresentações