Este post faz parte de uma série de textos sobre LaTeX e sobre a ideia de tratar documentos como código. Ao longo dos anos, acabei montando um workflow para escrever documentos técnicos, artigos, relatórios e apresentações baseado em LaTeX, Emacs, latexmk e Git, e esta série é basicamente uma tentativa de organizar e documentar esse processo.

A ideia não é ensinar LaTeX do zero, mas sim discutir o ambiente de trabalho ao redor dele: editores, compilação automática, organização de projetos, templates e versionamento. Cada post da série aborda uma parte desse sistema.

Quem usa LaTeX por algum tempo acaba percebendo que o mais importante não é o editor, mas o workflow. O editor é apenas uma peça dentro de um sistema maior que inclui compilação, organização de arquivos, templates e versionamento. Isso acontece por causa de como o LaTeX funciona e também de para quê ele é usado. Como ele foge do paradigma “tradicional” de editores WYSIWYG (Word, Google Docs, etc), em última análise não faz diferença qual editor se usa para editar o arquivo .tex. Desde que ele siga a sintaxe adequada e tenha os comandos certos, não faz diferença se foi escrito usando Emacs, Vim, Bloco de Notas ou Borboletas. Então, na prática, podemos considerar que a escolha de um editor para LaTeX se resume à preferência pessoal.

Ainda assim, existem algumas características em editores de texto que podem facilitar bastante a vida de quem se propõe a escrever documentos em LaTeX. Claro, é perfeitamente possível escrever tudo “na marra”, digitando diretamente cada comando no arquivo, gerenciando manualmente referências, verificando se todas as chaves estão fechadas e assim por diante. Mas, com o advento das IDEs (Integrated Development Environments), muitas ferramentas criadas para facilitar a vida de quem programa acabam sendo extremamente úteis para quem escreve LaTeX também. De certa forma, escrever em LaTeX é mais parecido com programar um documento do que com editá-lo visualmente.

A escolha mais difícil é aquela que não faz diferença

Essa liberdade, por outro lado, pode criar um problema: se qualquer editor serve, então como escolher um? A preferência pessoal certamente entra nesse cálculo, mas tem alguns fatores que a gente pode levar em conta nessa hora. Afinal, existe um verdadeiro espectro de editores por aí, com diferentes abordagens e paradigmas de funcionamento. E tem algumas ferramentas que podem ser bem úteis na hora de escrever um documento, principalmente quando se trata de algo um pouco maior, que vá além de um texto curto que possa ser escrito sem muita “firula”.

Quando o documento começa a ficar mais complicado, embora seja possível usar um editor qualquer, a presença dessas ferramentas se torna cada vez mais importante. De um ponto de vista estritamente técnico, não faz diferença como o arquivo foi escrito; o LaTeX só lê o conteúdo e processa o que encontrar ali. É o oposto do Word, por exemplo, onde um arquivo pode ficar diferente, mesmo que esteja no formato do próprio Word, se tiver sido escrito usando outro software como o OpenOffice, por exemplo.

Enfim, a discussão sobre “qual é o melhor editor para LaTeX” não tem resposta objetiva. As funcionalidades que são mais importantes variam de acordo com quem está escrevendo o texto, então a pergunta certa a se fazer é: qual o melhor editor LaTeX para você?

Existem algumas funcionalidades que não são estritamente necessárias, mas que facilitam muito a vida de quem escreve documentos em LaTeX com frequência. Muitas dessas funcionalidades vieram do mundo das IDEs e das ferramentas de programação, e fazem bastante sentido no contexto do LaTeX, já que escrever em LaTeX, como eu falei antes, é mais parecido com programar um documento do que com editá-lo visualmente.

Destaque de Sintaxe

Uma das coisas mais básicas, mas também mais importantes, é o destaque de sintaxe. Em um arquivo LaTeX, há texto normal misturado com comandos, ambientes, matemática, comentários e referências. Quando tudo aparece da mesma forma, o arquivo rapidamente fica difícil de ler e de depurar.

Com destaque de sintaxe, comandos aparecem em uma cor, comentários em outra, matemática em outra, e o texto normal em outra. Isso melhora muito a legibilidade do arquivo e ajuda a encontrar erros mais rapidamente.

Autocompletar comandos

Outra funcionalidade que ajuda bastante é o autocompletar de comandos (autocomplete). O LaTeX tem muitos comandos longos e estruturas repetitivas, como ambientes de figuras, tabelas, equações, listas e assim por diante. Ter o editor sugerindo comandos enquanto você digita economiza tempo e reduz erros de digitação.

Alguns editores também conseguem sugerir labels existentes quando você escreve \ref{...} ou entradas da bibliografia quando você escreve \cite{...}, o que é extremamente útil em documentos grandes.

Snippets e estruturas prontas

Relacionado ao autocomplete, muitos editores permitem usar snippets, que são atalhos para inserir estruturas completas de LaTeX. Por exemplo, um atalho que insere automaticamente um ambiente de figura ou de equação já com \caption e \label. Isso não é essencial, mas depois que você se acostuma, fica difícil viver sem.

Integração com compilação

Escrever o arquivo .tex é apenas parte do processo; a outra parte é compilar o documento e gerar o PDF. Um editor que permite compilar o documento com um atalho de teclado ou um comando interno facilita bastante o processo todo. Melhor ainda se o editor conseguir mostrar mensagens de erro e avisos de compilação de forma integrada.

Visualização de PDF e SyncTeX

Outra funcionalidade muito útil é a visualização do PDF integrada ao editor e o suporte ao SyncTeX. O SyncTeX permite ir do código para o PDF e do PDF para o código, o que é extremamente útil em documentos longos. Já que o LaTeX processa o texto e gera uma versão transformada dele, nem sempre é fácil encontrar o mesmo elemento no fonte e no PDF. Em vez de procurar manualmente onde uma equação ou um parágrafo está no código, você pode simplesmente clicar no PDF ou pedir para o editor mostrar a posição correspondente.

Navegação pela estrutura do documento

Documentos LaTeX normalmente têm uma estrutura bem definida em capítulos, seções, subseções, figuras, tabelas e equações. Alguns editores conseguem mostrar essa estrutura em um painel lateral, funcionando como um índice navegável do documento. Em projetos grandes, isso ajuda muito na organização e na navegação.

Integração com controle de versão

Como arquivos LaTeX são arquivos de texto, eles funcionam muito bem com sistemas de controle de versão como Git. Ter um editor que se integra bem com ele — mostrando mudanças, histórico e diferenças entre versões — é uma grande vantagem, especialmente para quem escreve artigos ou trabalha em colaboração com outras pessoas.

No fim das contas

Nenhuma dessas funcionalidades é absolutamente necessária. É perfeitamente possível escrever documentos LaTeX em um editor simples, compilar pelo terminal e gerenciar tudo manualmente. Muita gente (inclusive eu) fez isso por muitos anos, e muitos ainda o fazem.

Mas, na prática, essas ferramentas tornam o processo muito mais confortável e eficiente. Por isso, quando se escolhe um editor para LaTeX, o mais importante não é qual editor tem mais funcionalidades, mas qual editor oferece as ferramentas que você precisa e se encaixa melhor no seu workflow.

Outra coisa que ressoa muito bem com o meu cérebro autista é que criar esse processo todo, integrar ferramentas diferentes, montar uma configuração que seja estável e funcional, e principalmente, saber como tudo funciona, como cada engrenagem se encaixa com as outras, é um BAITA bônus.

Minha história com editores

Minha relação com editores de texto não foi linear, nem particularmente planejada. Foi mais uma sequência de tentativas, abandonos, descobertas e teimosias ocasionais. Em retrospecto, isso acabou sendo útil, porque me deu uma noção melhor do que realmente importa.

Quando comecei a usar LaTeX, eu usava Emacs, mas com uma configuração praticamente padrão, sem grandes personalizações. Era basicamente a configuração basal do ambiente do Socrates, o servidor Linux que estava disponível pros alunos do IFUSP. Essa configuração foi fruto de uma série de idiossincrasias dos responsáveis do projeto, e de fato me influencia até hoje. Não à toa, eu ainda uso tcsh, e ainda tenho uma estrutura de arquivos de configuração que tem opções que já estavam lá há 27 anos.

Essa configuração funcionava, mas eu não entendia muito bem o que estava acontecendo nos bastidores. Eu basicamente escrevia o arquivo, compilava e seguia a vida. Era suficiente, mas não era exatamente confortável nem particularmente eficiente.

Depois houve um período em que eu usei pouco LaTeX, e acabei passando por vários editores diferentes para outras coisas — programação, texto, anotações — sem me fixar muito em nenhum deles. Nenhuma dessas tentativas foi particularmente memorável, então vamos deixar por isso mesmo.

Em algum momento, quando voltei a programar com maior frequência (mais ou menos nesta época), acabei me interessando pelo Vim. O Vim é um editor fascinante, com uma filosofia muito própria baseada em edição modal e em comandos muito eficientes para manipulação de texto. Para programação, ele pode ser extremamente poderoso. Ele também tem a vantagem de ser um sucessor espiritual do ed, o editor original do Unix. O venerável Brian Kernighan menciona isso aqui, e aqui tem mais detalhes a respeito.

Aproveitando o embalo da programação, tentei usar o Vim também para editar arquivos LaTeX. Funcionava, claro — como qualquer editor funciona — mas eu nunca me senti completamente à vontade. Parte disso provavelmente é falta de prática, mas parte também tem a ver com o fato de que o Vim foi pensado muito fortemente para programação e manipulação de texto em frações pequenas, e menos como um ambiente completo de trabalho integrado.

Depois disso, experimentei o VS Code e rapidamente migrei para o VS Codium. O VS Codium é uma alternativa open source ao VS Code, e tem muitas coisas interessantes: interface moderna, sistema de extensões, autocomplete muito bom, integração com Git, entre outras coisas. A extensão de LaTeX (LaTeX Workshop) é muito poderosa e oferece praticamente todas as funcionalidades que alguém poderia querer: compilação, visualização de PDF, SyncTeX, autocomplete, snippets, navegação por estrutura, etc.

Durante esse período, foi quando comecei a mexer mais seriamente com o latexmk e com o arquivo latexmkrc, tentando automatizar melhor o processo de compilação. Foi aí que comecei a perceber uma coisa que me incomodou bastante: a extensão de LaTeX do VS Code não respeitava completamente as configurações do latexmkrc, e preferia usar as próprias configurações internas. Quando tentei ajustar isso e procurei informações, percebi que esse comportamento era meio intencional e não havia muito interesse dos desenvolvedores em mudar isso.

Isso me incomodou mais do que deveria, provavelmente, mas foi o suficiente para eu começar a olhar de novo para o Emacs. Meio por teimosia, meio por curiosidade, resolvi voltar para o Emacs e tentar montar um ambiente de LaTeX mais bem configurado, em vez de depender de uma extensão que fazia as coisas do jeito dela. Mas, antes disso, acho que vale a pena fugir da experiência pessoal e colocar aqui uma descrição mais imparcial das principais opções que eu mencionei, o que incidentalmente mostra como alguns deles estão profundamente integrados com a própria história da Computação.

Vim e Neovim

Os primórdios: QED

Para entender o Vim e o Neovim, vale a pena olhar para a história dos editores de texto no Unix, já que eles pertencem à linhagem direta do próprio Unix. Nos primórdios, não existiam departamentos de “Ciência da Computação”; o campo em si ainda não existia e era composto por matemáticos e engenheiros. Um dos primeiros conflitos da história da Computação foi justamente decidir se os departamentos que estavam começando a surgir seriam “hospedados” em escolas de matemática ou de engenharia. Os matemáticos ganharam, e por isso não é surpresa que o primeiro editor de texto se chamasse QED, que oficialmente era uma abreviação de “Quick Editor”, mas obviamente era uma piadinha de matemático.

O QED era um editor de texto criado para os sistemas de “time sharing”, que gerenciavam o uso dos computadores na época – lembrando que, nos anos 1960, computadores eram máquinas gigantescas e muito, MUITO caras. Por isso, era comum ter apenas um computador que era usado por vários departamentos, e por isso esses sistemas eram necessários pra garantir que todo mundo tivesse uma fração razoável do tempo de computação disponível.

ed, Unix, e a era dos terminais

Quando um dos maiores cérebros que já abençoou a humanidade, chamado Ken Thompson, criou o Unix, ele criou três ferramentas principais: um assembler, uma shell e um editor, inspirado pelo QED, que ele chamou de ed – pronunciado como as duas letras em inglês: “ee-dee”. Nessa época, até elementos que hoje em dia são obviedades em um computador ainda não tinham sido nem inventados – incluindo uma pequena “pecinha” chamada de monitor. Ou seja, computadores não tinham uma tela onde fosse possível exibir e manipular texto. A interface desses computadores era uma impressora ou um teletipo, e por isso editores eram criaturas completamente distintas do que estamos acostumados hoje em dia. Eles precisavam ter comandos para imprimir as linhas do texto, e depois outro comando era usado para incluir, excluir ou alterar alguma coisa no arquivo.

Incidentalmente, foi nessa época que o Ken Thompson, do alto de sua brilhância inigualável, criou uma ferramenta para alterar sequências de caracteres em arquivos de texto de forma mais conveniente. Assim nasceram as expressões regulares, conjuntos de regras que eram usados para encontrar e alterar padrões no texto, eventualmente culminando na criação de uma das ferramentas mais úteis de todos os tempos: o grep. Essa história é melhor contada pelo Brian Kernighan, aqui.

Ao longo dos anos, o ed por passando por revisões e melhorias, como o em (“editor for mortals“) e o ex (“extended editor“), feitas por várias pessoas. Entre elas estava o Bill Joy, um aluno de pós em Berkeley; ele criou, para o ex, um modo visual, capaz de mostrar o texto do arquivo na tela (que, a essa altura, já tinha sido inventada). Esse modo visual já era, funcionalmente, o vi; uma versão especial do ex foi eventualmente criada, modificada para iniciar diretamente no modo visual (em essência, vi e ex são o mesmo editor). Criado em 1976, o ex/vi rapidamente se tornou o editor padrão no Unix. Ele passou a ser incluído por padrão em várias versões do Unix e continuou sendo largamente utilizado até bem depois da virada do milênio.

O surgimento do Vim e a evolução do Neovim

Mas o vi era limitado a sistemas Unix. Por isso, um holandês chamado Bram Moolenaar criou uma versão inspirada nele, mas para o Amiga. No começo, ele chamou de “Vi IMitation”, eventualmente mudando para “Vi IMproved”. Esse era o Vim, que ele começou em 1988 e lançou em 1991. O fato da licença do Vim ser única, definindo o charityware (a licença só pedia que aqueles que pudessem doassem para causas humanitárias em Uganda), com acesso ao código fonte, fez dele o sucessor do vi, que continha código fonte originário do Unix e, por isso, não podia ser livremente compartilhado. Além disso, ele trouxe funcionalidades que eram, na época, inéditas:

• múltiplos buffers;
• sistema de plugins;
• syntax highlighting;
• macros;
• scripts de configuração;
• janelas e splits;
• integração com ferramentas externas.

Mas, mesmo com todos esses benefícios, o Vim continuou a ser desenvolvido e mantido exclusivamente pelo Bram Moolenaar. A postura dele era bastante conservadora, dando prioridade à estabilidade e evitando implementar novas funcionalidades em nome dessa estabilidade (já que qualquer código novo fatalmente introduz novos bugs). Por causa disso, o editor acabou avançando muito pouco, e sem implementar demandas que a comunidade não cansava de pedir.

Finalmente, no início da década de 2010, um brasileiro chamado Thiago de Arruda resolveu pegar o código do Vim e refatorar, buscando melhorar o código e implementar funcionalidades que muita gente queria ver. Não foram poucas tentativas de fazer isso, mas o que diferenciou o projeto do Thiago foi o ímpeto inicial. Além disso, ele aceitou a contribuição de várias pessoas e rapidamente o processo de desenvolvimento do editor foi modernizado e várias novidades foram sendo implementadas. O Neovim foi, então, lançado em 2014.

Hoje em dia Vim e Neovim compartilham o espaço. As evoluções do Vim eram implementadas pelo Moolenaar e, depois, por outras pessoas que começaram a contribuir com o código, especialmente depois que ele faleceu em 2023. O Neovim é um esforço mais coletivo desde o começo e tem uma rede de contribuidores bem grande. No geral, esses dois editores compartilham essa linhagem nobre, e um conjunto de funcionalidades que é muito convidativo para muitas pessoas. Existe um ecossistema saudável e prolífico de extensões e plugins, que ajudam a expandir as capacidades deles e disponibilizam ferramentas muito úteis que ajudam na edição de arquivos fonte.

VS Code/Codium

Se o Vim e o Neovim representam uma linhagem histórica que remonta aos primórdios do Unix e à filosofia de ferramentas pequenas e altamente eficientes, o Visual Studio Code representa quase o extremo oposto: uma IDE moderna, com interface gráfica, extensões, integração com várias ferramentas e uma experiência mais próxima do que a maioria das pessoas hoje associa a um ambiente de desenvolvimento.

O Visual Studio Code, ou simplesmente VS Code, foi lançado pela Microsoft em 2015 e rapidamente se tornou um dos editores de código mais populares do mundo. Ele é baseado no Electron, ou seja, essencialmente uma aplicação web rodando dentro de um aplicativo desktop. Isso permite uma interface moderna, extensível e relativamente consistente entre diferentes sistemas operacionais, embora essa abordagem também seja alvo de críticas, principalmente por causa do consumo de memória.

A ideia do VS Code é ser um editor leve, mas extensível, que pode se tornar uma IDE completa através de extensões. Hoje existem extensões para praticamente qualquer linguagem de programação, além de ferramentas para Git, containers, acesso remoto, notebooks, e, claro, LaTeX.

Contexto: IDEs em 2010

Para entender melhor o contexto desse projeto, é importante voltar um pouco no tempo. Por volta de 2010, IDEs eram algo completamente distinto do que existe hoje em dia. Havia as IDEs grandes e poderosas, dominantes no mercado corporativo, como IntelliJ IDEA, Eclipse e NetBeans, além do Visual Studio. Mas eram ambientes voltados a linguagens específicas (por exemplo, Java), eram pacotes muito grandes e eram também bastante pesados (em termos de capacidade de processamento e necessidade de memória).

Na outra ponta do espectro, estavam os editores mais “tradicionais” como Vim e Emacs, além de outros como Notepad++ e, principalmente, o Sublime Text. No geral eles eram bastante genéricos e (ainda) não tinham tantas funcionalidades. O Sublime Text era a exceção nisso tudo, porque era visualmente muito agradável, era leve e extensível. E tinha um defeito crítico: tem uma versão gratuita, mas para desbloquear todas as capacidades do editor, é necessário comprar uma licença.

Existia, então, um espaço “vazio”, já que as opções que existiam eram muito pesadas, muito manuais, ou incompletas (e, casos como o Sublime Text, pagas). Esse espaço estava apenas esperando para ser ocupado por um editor que tivesse as características e capacidade de uma IDE, mas que fosse acessível.

O Electron por si só é uma plataforma, no mínimo, controversa. Ele facilita o desenvolvimento mas algumas pessoas argumentam que um aplicativo feito com ele não é um programa genuíno, já que é basicamente um fork do Chromium, rodando uma interface customizada. Mas, em 2015, a maior preocupação dessa abordagem, que era o uso de memória, não era tão crítica assim, já que memória RAM não era um problema.

A ironia disso não é pouca enquanto eu escrevo este post, em Março de 2026, quando memória RAM de repente voltou a ser artigo de luxo e os preços estão disparando loucamente.

Code ou Codium?

Um dos diferenciais mais importantes do VS Code é que ele é bastante poderoso, mas é gratuito. Não só isso, mas o projeto-raiz dele, segue a licença MIT, que não apenas é open source mas é também considerada software livre. O Visual Studio Code, por sua vez, é uma versão do software desse repositório, que passa pelas mãos da Microsoft. O binário que pode ser baixado e instalado contém alguns itens… “adicionais”… que não seguem, necessariamente, a mesma licença livre do resto do software. Em outras palavras, o que a maioria das pessoas chama de “VS Code” é, na verdade, uma ferramenta da Microsoft que não deixa de ser mais um sintoma do processo pelo qual o mundo vem passando ultimamente – em que tudo se transforma gradualmente em serviço, onde as pessoas não são donas de nada – apenas pagam uma assinatura.

Por causa disso surgiu o VS Codium, que é basicamente o mesmo editor, mas compilado a partir do código open source sem os componentes proprietários e sem telemetria. O próprio projeto VSCodium se descreve como uma forma de fornecer “binários do VS Code construídos a partir do código open source, sem as customizações proprietárias da Microsoft”. Na prática, para o usuário, o VS Code e o VS Codium são quase idênticos em aparência e funcionamento, mas o VS Codium é a versão totalmente open source.

O problema do ecossistema

Existe também uma crítica mais estrutural ao VS Code que não tem a ver apenas com telemetria ou licença, mas com o controle do ecossistema. Embora o código do editor seja open source, o “marketplace” oficial de extensões é controlado pela Microsoft e não é aberto para clientes alternativos. Isso significa que versões open source como o VSCodium não podem usar oficialmente o mesmo marketplace e precisam recorrer a repositórios alternativos. Na prática, isso cria uma dependência do ecossistema da Microsoft, mesmo que o editor em si seja baseado em código aberto. Esse tipo de estratégia — abrir o código da ferramenta, mas controlar a infraestrutura ao redor — é relativamente comum e explica parte da posição dominante do VS Code hoje.

Ou seja, eles criam uma ferramenta extremamente atraente, e quando “todo mundo” se torna tão dependente dessa ferramenta que as pessoas não conseguem nem mesmo distinguir o nome da ferramenta do papel que ela desempenha, transformam todo mundo em refém, efetivamente criando um monopólio. E isso nem é um caso isolado – aconteceu com os softwares de “escritório”, como processadores de texto e planilhas de cálculo por exemplo. Nos anos 90 existiam várias alternativas, todas competindo, no mesmo nível de capacidade. Hoje em dia, quando as pessoas falam de “Word” e de “Excel” mesmo quando falam de outros softwares que fazem a mesma coisa. Vou parar com o proselitismo por aqui, mas eu recomendo fortemente ler isto aqui.

Então, desde já, se for usar, use o Codium. Ele tem um marketplace alternativo onde dá pra instalar as mesmas extensões que são usadas no VS Code, sem ficar refém da MicroSlop.

VS Codium e LaTeX

Para LaTeX, o VS Codium costuma ser usado com a extensão LaTeX Workshop, que transforma o editor em um ambiente bastante completo para escrita de documentos LaTeX. Com essa extensão, o editor oferece:

• destaque de sintaxe;
• autocomplete de comandos e ambientes;
• snippets para estruturas comuns;
• compilação automática;
• integração com latexmk;
• visualização de PDF integrada;
• SyncTeX;
• navegação pela estrutura do documento;
• integração com bibliografia;
• integração com Git;
• gerenciamento de projetos.

Filosofia

A filosofia do VS Codium é bastante diferente da filosofia do Vim ou do Emacs. Enquanto esses editores mais antigos são extremamente configuráveis e muitas vezes exigem que o usuário monte o próprio ambiente de trabalho, ele tenta oferecer uma experiência mais integrada e pronta para uso, onde a maior parte das funcionalidades é adicionada através de extensões e configurada por arquivos JSON. Isso faz com que ele seja, em geral, mais fácil de começar a usar, especialmente para quem já está acostumado com IDEs modernas. Por outro lado, ele também é uma ferramenta mais pesada e com várias camadas de abstração, o que às vezes torna o comportamento do sistema menos transparente do que em ferramentas mais simples e modulares.

Por isso, para quem não quer ter trabalho montando seu próprio ambiente ou um workflow próprio, o Codium pode ser uma alternativa interessante, principalmente se RAM não for uma preocupação, para LaTeX, especialmente para quem quer uma experiência integrada, com autocomplete, compilação e visualização funcionando com pouca configuração inicial. Não é o nosso caso nesta série, por isso não vamos mais falar disso.

Overleaf

O próximo da nossa lista é o Overleaf. Ele é um terceiro eixo nesse espaço vetorial de ambientes para LaTeX, porque ele não é nem um editor-base que pode ser customizado como Vim ou Emacs, nem um ambiente local como o Codium. O Overleaf é uma plataforma online que funciona como um ambiente completo, integrando edição, compilação e visualização de PDF em um único ambiente web. A ideia é que o usuário não precise instalar nada: nem LaTeX, nem compiladores, nem editores. Basta criar uma conta, abrir o navegador e começar a escrever.

O Overleaf surgiu da fusão de dois projetos: Overleaf (que antes se chamava WriteLaTeX) e ShareLaTeX, que eram duas plataformas concorrentes de edição LaTeX online. Em 2017, os dois projetos se fundiram e o nome Overleaf foi assumido como marca final. A partir daí, a plataforma se tornou provavelmente o ambiente LaTeX online mais utilizado do mundo, especialmente em ambientes acadêmicos. Os dois eram serviços que competiam entre si, e que ofereciam um ambiente integrado para editar documentos em LaTeX, com acesso a todos os pacotes possíveis, compilação automática, visualização de PDF e, principalmente, a possibilidade de várias pessoas colaborarem no mesmo arquivo. Isso facilitou muito o trabalho de muita gente, já que é bem comum várias pessoas trabalharem no mesmo texto, como no caso de relatórios e artigos por exemplo.

Além disso, é necessário admitir que o processo de instalar uma distribuição de LaTeX e gerenciar os pacotes necessários nem sempre é uma tarefa muito fácil, e para muita gente isso pode ser um desafio – ainda mais quando espaço em disco pode ser um problema (a distribuição completa do TeX Live, por exemplo, pode passar de 7 GB. A plataforma também automatiza a compilação, incluindo possíveis usos de BibTeX/BibLaTeX, makeindex e assim por diante.

Controle vs conveniência

É tudo muito conveniente, até o documento começar a ficar grande.

Fiel à tradição de serviços online, o Overleaf tem um plano gratuito e planos pagos. E o plano gratuito é bastante limitado, com restrições severas no tempo de compilação, número de contribuintes no projeto, integração com git, espaço de armazenamento, e assim por diante. Mesmo os planos pagos têm limite, o que de certa forma faz sentido afinal tudo acontece no servidor deles, que é compartilhado por todos os usuários do serviço. Então é possível que um projeto especialmente grande tenha dificuldades em ser concluído, mesmo quando se usa o serviço pago. E isso não é apenas especulação: hoje em dia os limites computacionais podem ser outros, mas quando terminei de escrever a minha tese de doutorado, em 2013, a compilação final durou uma noite inteira (entre os principais responsáveis estavam o microtype e o pgfplots, mas vamos deixar eles para um post futuro).

Além disso, há outro problema: é um serviço online. E, como todo serviço online, depende de coisas que são mais difíceis de avaliar. Em um workflow local com LaTeX, você pode:

• editar arquivos offline;
• compilar offline;
• usar Git offline;
• trabalhar em qualquer lugar.

Com o Overleaf, tudo depende da plataforma online:

• você depende da existência do serviço;
• você depende das políticas da empresa;
• você depende dos limites da plataforma;
• você depende das ferramentas que eles disponibilizam;
• você não controla totalmente o ambiente de compilação;
• automações e scripts personalizados são mais difíceis de usar;
• organização de arquivos fica limitada ao modelo da plataforma.

Em outras palavras, você troca controle por conveniência. O Overleaf é provavelmente a forma mais fácil de usar LaTeX hoje, mas não necessariamente a melhor para quem quer construir um workflow próprio e ter controle total sobre edição, compilação, organização de arquivos e versionamento de documentos.

Emacs

Origens: TECO e Macros

Se o Vim e o Neovim vêm de uma linhagem nobre no universo do Unix, o Emacs também tem sua própria linhagem, que pode não ser tão conhecida mas é igualmente importante. Enquanto os dois primeiros vieram da tradição do Bell Labs, o Emacs tem suas origens diretamente no MIT (Massachusetts Institute of Technology), onde ele nasceu a partir de um editor chamado TECO – Text Editor and COrrector. Originalmente ele era chamado de Tape Editor and Corrector, porque os programas eram armazenados em fitas de papel perfurado. Ele era usado para editar os programas construídos dessa forma, e possuía uma série de comandos que eram usados para escrever e corrigir os programas. A linguagem de script dele, para atender às necessidades de edição, ficou tão complexa que se tornou turing-completa, isto é, poderia ser usada para escrever qualquer programa.

O TECO foi desenvolvido no MIT para ser usado em dois sistemas PDP-1. O objetivo dele era oferecer um meio mais eficiente para editar os programas a serem usados no computador. Desnecessário dizer, naquela época recursos computacionais eram extremamente limitados. Estamos falando de uma época tão distante que é difícil fazer qualquer comparação – as arquiteturas de computadores muito diferentes, e um padrão ainda não tinha sido atingido. O próprio conceito de byte ainda nem existia.

Foi no manual do TECO que o acrônimo oposto ao WYSIWYG foi criado: YAFIYGI – You Asked For It You Got It. Por causa das limitações do sistema, assim como no caso do ed os comandos do TECO eram igualmente crípticos. Mas o TECO tinha uma linguagem de script extremamente poderosa, e por isso era possível criar macros para facilitar as diversas operações necessárias para a edição de texto.

Note que, quando falamos de macros, estamos falando até de coisas básicas. Por exemplo, mover o cursor em qualquer direção, ou inserir um caractere. Normalmente isso está oculto no Emacs, mas por trás da cortina, quando pressionamos, por exemplo, o “J”, existe uma macro que faz a tarefa de inserir o caractere “j” no buffer ativo.

Além disso, assim como o ed (e os sucessores dele), o TECO era um editor modal. As macros de inserção dele entravam no modo de inserção, adicionavam caracteres, e voltavam para o modo de comando. Aos poucos, ele evoluiu para um editor chamado E, que tinha um comportamento que seria equivalente ao WYSIWYG (que significava algo mais simples na época). É nesse ponto da história que surge um tal de Richard Stallman, aluno do MIT, que viu o comportamento do E em Stanford e voltou para o MIT, onde ajudou o Carl Mikkelsen a implementar um modo chamado de “Control-R“, que atualizada o texto na tela toda vez que uma tecla era pressionada (algo trivial hoje em dia mas que na época representava um avanço significativo). Aos, pacotes de macros foram surgindo conforme usuários avançados os criavam – TECMAC, TMACS, RMODE, entre outros.

Uma versão consolidada desses pacotes, criada pelo Stallman com Guy Steele, ficou conhecida como “E with MACroS“, ou EMACS para encurtar. Eventualmente, em verdadeira tradição do meio, a sigla virou um acrônimo recursivo: Emacs Makes All Computing Simple. Já nessa versão primordial, ele incluía uma mensagem pedindo para que as pessoas enviassem suas contribuições para ele, para que o editor pudesse incorporar melhorias de uma forma homogênea.

Com o passar dos anos, começaram a surgir vários editores “sabor Emacs”, que seguiam a mesma filosofia mas sempre com alguma variação (e um acrônimo recursivo engraçadinho para chamar de seu): EINE (Eine Is Not Emacs), ZWEI (Zwei Was Eine Initially), SINE (Sine is Not Eine), NILE (Nile Is Like Emacs), e assim por diante. Um desses, chamado de Gosling Emacs, foi escrito por James Gosling, que futuramente seria o criador do Java. Esse foi, supostamente, o primeiro editor “sabor Emacs” a rodar no Unix. Escrito em C, naturalmente.

GNU Emacs

O Stallman identificou um problema com essas várias versões do Emacs: eram várias versões do “mesmo” software, cada uma com sua peculiaridade. Pior ainda: empresas particulares começaram a desenvolver seu próprio software, distribuindo binários sem fornecer acesso ao código fonte. Sem acesso ao fonte, não é possível inspecionar o código para ter certeza de que aquele software não vai fazer algo indesejado com seu computador ou com seus dados. Isso quebrou o costume que havia sido cultivado no meio acadêmico, onde o código fonte era livremente compartilhado, sem preocupação com licenças ou burocracia.

RMS (como ele ficou conhecido) entendeu isso como uma perda enorme para a comunidade científica e para a cultura hacker. Mais ainda, ele concluiu que licenças proprietárias de software, que impedem que o código fonte seja compartilhado livremente, não são um problema apenas técnico, mas também social e ético.

Software Livre e o Projeto GNU

Como resposta a esse problema, em 1983 ele finalmente criou o Projeto GNU, uma iniciativa para criar um sistema operacional completo, baseado nos princípios do Unix, mas totalmente livre de código proprietário. Dentro da tradição de acrônimos recursivos, GNU significa “GNU is Not Unix”. Esse sistema seria compatível com Unix, mas totalmente livre, oferecendo liberdade para que qualquer um usasse, estudasse, modificasse e redistribuísse o software como bem entendesse. Esses conceitos mais tarde levaram às Quatro Liberdades do Software Livre:

1. Liberdade de executar o programa para qualquer propósito.
2. Liberdade de estudar como o programa funciona.
3. Liberdade de redistribuir cópias.
4. Liberdade de modificar o programa e distribuir versões modificadas.

Essas ideias levariam depois à criação da GNU General Public License (GPL), uma das licenças de software livre mais importantes da história – mas isso é um tópico para outro dia.

Em 1985, ele publicou o Manifesto GNU, explicando detalhadamente os motivos pelos quais o Software Livre é importante. Esse documento descreve o funcionamento do Projeto e explicando as bases filosóficas para o Software Livre.

O primeiro software lançado dentro do Projeto GNU foi o GNU Emacs, uma reimplementação, feita do zero, do editor que já havia sido consagrado anteriormente. Ele tinha um núcleo implementado em C, que era um interpretador Lisp sobre o qual o editor era construído. Ou seja, o Emacs tem um “coração” feito em C, que é um interpretador Lisp, e usa essa linguagem para construir basicamente toda a funcionalidade do programa. O (GNU) Emacs está profundamente ligado à cultura de:

• programabilidade;
• extensibilidade;
• automação;
• compartilhamento;
• controle do próprio ambiente;
• liberdade de modificar ferramentas.

Isso explica por que tantas pessoas que usam Emacs têm uma relação quase filosófica com a ferramenta – e também porque esse desvio histórico-filosófico era necessário.

Essa extensibilidade fez do Emacs um terreno fértil para o desenvolvimento de um número enorme de ferramentas, de forma que ele ficou conhecido por ser capaz de fazer qualquer coisa. Uma piada corrente entre os detratores costuma dizer que o Emacs é “um sistema operacional disfarçado de editor”. Por muitos anos, a minha assinatura de email foi uma frase do Chris diBona: “calling Emacs an editor is like calling Earth a hunk of dirt”. Até a descrição do pacote na Debian costumava entrar na dança, descrevendo ele como “text editor and kitchen sink”.

No que se refere ao que nos interessa nesta série, esse ambiente receptivo a extensões e customizações levou ao nascimento de um pacote para o Emacs chamado AUCTeX: Advanced Unified Comprehensive TeX. Esse pacote transforma o Emacs em um ambiente poderoso para editar documentos LaTeX, trazendo uma série de funcionalidades e facilitando o uso de todas as ferramentas que o LaTeX pode oferecer. Ele facilita o uso de ambientes e comandos de seccionamento, a criação de ambientes matemáticos, tabelas e figuras, autocompleta comandos, busca palavras-chave de referências e citações, agiliza a navegação pelo documento, gerencia a compilação do documento (sozinho ou através do latexmk), ajuda a identificar e corrigir erros, suporta o SyncTeX e suporta múltiplos arquivos.

Finalmente, uma das vantagens únicas do Emacs é que ele é, de certa forma, “auto-consciente”, isto é, ele tem um jeito de saber quando as configurações dele foram alteradas, e na hora de apresentar um texto de ajuda ou encontrar algum comando, essas ferramentas levam isso em consideração. Por exemplo: normalmente, a combinação “Ctrl-X Ctrl-F” abre um arquivo. Mas, se por algum motivo, essa combinação de teclas for alterada para “Ctrl-A Ctrl-A”, ao perguntar para a ajuda do Emacs como fazer para abrir um arquivo, ele vai mostrar o comando correto.

Por que usar Emacs?

Como eu mencionei acima, a escolha de um editor é, no caso do LaTeX, algo bastante pessoal. Existem vários editores que funcionam muito bem, e que têm capacidades ótimas de facilitar o trabalho. Mas, no caso particular desta Série, vamos usar o Emacs. Por quê? Porque é o que eu uso. Se essa resposta não te satisfaz, considere o seguinte.

Depois de explorar a história do Emacs, sua relação com o movimento de software livre e o papel de extensões como o AUCTeX, fica a pergunta natural: por que alguém escolheria o Emacs hoje, quando existem tantas alternativas modernas como VS Code, Overleaf, etc.?

A resposta não é simples, mas ela passa por algumas ideias centrais: controle, extensibilidade, integração e longevidade.

Emacs como ambiente de trabalho, não apenas editor

A principal diferença entre o Emacs e a maioria dos outros editores é que o Emacs não é apenas um editor — ele é um ambiente de trabalho extensível.

Em muitos editores, você abre o editor para editar um arquivo, depois abre um terminal para compilar, depois abre um visualizador de PDF, depois abre um programa para gerenciar referências, depois abre um cliente Git para versionamento. Cada ferramenta é separada.

No Emacs, todas essas coisas podem existir dentro do mesmo ambiente:

• edição do arquivo .tex;
• compilação com latexmk;
• visualização do PDF;
• navegação por erros;
• gerenciamento de referências;
• terminal;
• Git (Magit);
• organização de projetos;
• anotações (org-mode);
• scripts e automações.

Isso muda completamente a forma de trabalhar. Em vez de alternar entre vários programas, você trabalha dentro de um único ambiente que integra tudo.

Extensibilidade e automação

Outra grande vantagem do Emacs é que ele é programável em Emacs Lisp. Isso significa que o editor não é uma ferramenta fixa: ele pode ser modificado, automatizado e estendido indefinidamente.

Com o tempo, o usuário pode:

• criar atalhos próprios;
• automatizar tarefas repetitivas;
• criar templates;
• integrar scripts;
• integrar ferramentas externas;
• adaptar o editor ao próprio workflow;
• criar comandos personalizados para LaTeX;
• automatizar compilação e organização de arquivos;
• integrar Git e LaTeX;
• etc.

Isso faz com que o Emacs seja uma ferramenta que melhora com o tempo, à medida que o usuário vai refinando seu ambiente.

Estabilidade e longevidade

Isso é um ponto muito subestimado. Ferramentas como IDEs modernas e plataformas online mudam o tempo todo:

• interfaces mudam;
• extensões quebram;
• empresas mudam licenças;
• serviços deixam de existir;
• formatos mudam;
• configurações deixam de funcionar.

O Emacs existe desde os anos 1970 e continua funcionando hoje. Arquivos .tex escritos há 30 anos ainda compilam hoje. Configurações antigas frequentemente continuam funcionando. Ou seja, Emacs + LaTeX é um ambiente extremamente estável a longo prazo, o que é muito importante para quem escreve artigos, livros, teses ou mantém projetos acadêmicos por muitos anos.

Conclusão

O Emacs não é necessariamente o editor mais fácil de aprender, nem o mais moderno visualmente, nem o mais popular. Mas ele é uma ferramenta extremamente poderosa para quem trabalha com texto, programação ou LaTeX, porque ele permite construir um ambiente de trabalho completamente adaptado ao próprio workflow. Com o tempo, o editor deixa de ser apenas um editor e passa a ser o centro de um sistema de escrita, compilação, versionamento e organização de projetos. É por isso que, apesar de todas as alternativas modernas, o Emacs continua sendo uma das melhores ferramentas para quem escreve documentos técnicos e científicos em LaTeX.