O primeiro contato com o LaTeX é uma experiência emblemática pra quem se inicia no Ensino Superior em certas áreas do conhecimento, como Matemática e Física. Mesmo pra quem não usa, eventualmente ele aparece pelo caminho – às vezes, até mesmo camuflado.
Pra quem escreve muito texto com matemática, a qualidade de um documento preparado usando o LaTeX é absolutamente incomparável. O fato de a linguagem ser muito próxima de uma linguagem de programação e conter regras, instruções e definições precisos também ajuda muito a encaixar na forma como o “exatóide” típico pensa.
Pra mim, esse primeiro contato foi quase que espontâneo. Descobri o TeX antes do LaTeX; eu tinha o hábito de fuçar pelos livros da biblioteca e um dia achei um livro sobre ele, e peguei pra ler. Estudei um pouco e logo estava escrevendo uns documentos de teste com TeX; naquela época o PDF ainda não era essa coisa generalizada e hegemônica que é hoje em dia, e por isso o resultado da compilação era um arquivo DVI (DeVice Independent), que a gente podia converter pra PostScript. Daí a gente abria usando o xdvi ou o Ghostscript pra visualizar o arquivo.
Mas, como ficou claro pra mim muito rápido, o TeX ainda é meio bruto. Muita coisa é feita “na mão”, e fica difícil gerenciar o texto em TeX “puro”. Foi logo depois que eu descobri que existia o LaTeX, um conjunto de macros criado em cima do TeX que “automatiza” várias dessas funções. Ele facilitou muito o processo todo de criar um documento: tarefas como definir seções e subseções, figuras, tabelas, referências e citações ficaram bem mais gerenciáveis e o foco passou a ficar muito mais do conteúdo.
Ao longo de mais de vinte anos, eu fui migrando pra lá e pra cá através de diversos esquemas pra escrever meus documentos com LaTeX: emacs, vim, VS Codium, Notepad++, TeX Studio, TeXnic Center… só pra citar alguns. Sempre foi um dos pontos mais desafiadores fazer o “worflow” de produzir um documento em LaTeX ficar um pouco mais prático – uma das vantagens do Word, por exemplo, onde é só “abrir e sair digitando”. No LaTeX, além de tudo, quase sempre é necessário rodar várias ferramentas em uma certa ordem pra conseguir o resultado final (LaTeX x 2, BibTeX, LaTeX de novo, etc etc etc).
Mas a necessidade de terminar o projeto/relatório/dissertação/tese/qualquer coisa que eu estivesse escrevendo sempre acabava falando mais alto, e eu só aceitava as dificuldades do processo como “dores do parto”, e deixava pra depois. E, claro, o “depois” nunca vinha.
Pelo menos, até recentemente. A necessidade de criar um documento com versões em duas línguas diferentes, junto com a perda de paciência com os caras que fazem a extensão de LaTeX do VS Codium, finalmente me empurraram pra lá da barreira de potencial e eu me enfiei no buraco de coelho da configuração do Emacs e do LaTeXMk. Este post não é bem um relato desse caminho, mas sim uma tentativa de documentar o esquema todo de um jeito lógico e de forma que outras pessoas possam usar como referência, caso queiram experimentar.
TeX e LaTeX: qual é a diferença?
O TeX é o sistema de composição tipográfica criado por Donald Knuth no final da década de 1970. Ele não é exatamente um editor nem uma linguagem de marcação no sentido moderno; ele é um motor de composição tipográfica. O objetivo do TeX é pegar um texto com comandos e produzir páginas tipograficamente bem compostas, com controle muito fino de:
- espaçamento entre palavras;
- hifenização;
- quebras de linha;
- quebras de página;
- posicionamento de caixas;
- fórmulas matemáticas.
O TeX funciona em um nível relativamente baixo. Em vez de dizer “faça uma seção”, você muitas vezes está lidando com coisas como:
- caixas;
- colas;
- dimensões;
- penalidades de quebra de linha;
- macros.
Em certo sentido, programar diretamente em TeX é mais parecido com programar um sistema de layout do que escrever um documento. Mas o Knuth foi além: ele não criou “só” o TeX, mas o ecossistema inteiro, já que ele ficou insatisfeito com o resultado que a editora tinha alcançado na montagem da série “The Art of Computer Programming”, que ele tinha escrito. Além do TeX, ele criou também:
- A fonte Computer Modern, que hoje em dia é emblemática do TeX/LaTeX (dá pra identificar um documento preparado com eles só de ver essa fonte);
- A METAFONT, uma linguagem para descrever fontes com base em equações matemáticas e não em desenhos (bitmaps);
- O Metapost, que é uma linguagem parecida com a METAFONT mas voltado para ilustrações, diagramas, figuras e assim por diante.
A qualidade dos documentos produzidos usando esse ecossistema foi tão superior que logo ele se sobressaiu e se espalhou. E, embora para a época fosse um esquema muito melhor pra preprarar documentos, ele ainda era muito complexo. Lembre-se: estamos falando de uma época em que computadores eram criaturas muito mais intimidadoras do que os de hoje em dia. O C era considerado uma linguagem de “alto nível”.
Então, nos anos 80 o Leslie Lamport criou um conjunto de macros, usando a linguagem do TeX, pra facilitar o processo de criar documentos. Isso foi possível porque o TeX era extensível e era possível criar “pacotes” com ele, definindo comandos e automatizando tarefas. De fato, o TeX é uma linguagem “Turing Completa”! Ou seja, seria possível criar qualquer programa com ela. Naturalmente, esse conjunto de macros que o ele criou começou a se popularizar, e foi ficando conhecido como “Lamport’s TeX”, ou “LaTeX”.
Usando as macros do LaTeX, ao criar uma nova seção no texto por exemplo, era possível só usar um comando \section em vez de definir manualmente as propriedades da fonte, a posição do texto, mudar as numerações de figuras e tabelas, e mudar todas as coisas que são alteradas no texto quando se inicia uma nova seção. É o LaTeX que define essa separação entre conteúdo e estrutura, e gerencia (com base nas opções definidas pelo usuário) coisas como capítulos, seções, equações, figuras, tabelas, referências, citações, cabeçalhos, rodapés, e assim por diante.
What You See Is Not What You Get
Uma das barreiras mais comuns hoje em dia pra quem quer começar com LaTeX é que ele NÃO É um editor de texto, muito menos um “processador” de texto (pelo menos não no sentido usual). As pessoas estão muito acostumadas a softwares como o Word ou o Google Docs, onde é possível já sair escrevendo texto assim que se cria um arquivo novo. Esses editores têm a vantagem de tentar mostrar já na mesma hora como o texto vai ficar no documento pronto, exibindo os títulos, formatos e todas as propriedades de formatação do documento enquanto ele é escrito. Isso é comumente conhecido como “WISIWYG” (do inglês, What You See Is What You Get). No caso do LaTeX, o documento é tratado como um código-fonte, e o resultado final só é visualizado quando esse fonte é processado e transformado em um arquivo como PDF. Então não se vê como vai ficar o documento até que ele seja processado – o que se vê NÃO É o que se tem: “YAFIYGI” (You Asked For It You Got It). Em certo sentido, escrever um documento em LaTeX é muito mais parecido com programar do que com usar um editor de texto.
Para quem está acostumado a já ver na mesma hora como o documento “vai ficar”, isso pode ser um pouco desconfortável. Como saber se o que estou escrevendo vai mesmo ficar do jeito que eu quero? Há dois problemas com essa abordagem.
O primeiro deles é que esses programas nunca conseguem de fato fazer o que eles prometem. Primeiro porque justamente por tentar mostrar o resultado final enquanto o texto ainda está sendo escrito causa uma série de transtornos, entre eles o fato de que todas as propriedades do documento – fontes, margens, espaçamento, e todo o resto – são “voláteis”: podem mudar ao longo do documento e causar inconsistências, além de que muitas vezes o resultado final pode depender do computador sendo usado e das versões do software. Além disso, ao tentar escrever um documento, é mais produtivo separar as coisas: definir uma estrutura e depois prestar atenção apenas ao conteúdo. A distração causada pela constante preocupação com a posição das coisas na página acaba desviando o foco do ponto principal do documento, que é o seu conteúdo.
É aqui que o LaTeX brilha: ele pode até ser mais desafiador (inicialmente) para se atingir o resultado final, mas uma vez definida a estrutura e o formato a serem usados no documento, a única preocupação de quem está escrevendo é única e tão somente o conteúdo. Claro, há algumas regras para seguir ao escrever, como por exemplo os comandos para inserir figuras e tabelas, equações, referências e citações, mas todos esses são constantes ao longo do texto, e são independentes de como o documento está sendo formatado.
LaTeX é preciso – um editor de texto não é preciso
Como eu mencionei antes, o LaTeX não é um editor de texto. Mas, pra editar o .tex, precisamos de um. O LaTeX resolve o problema da tipografia e da estrutura do documento, mas ainda precisamos ter um ambiente apropriado pra escrever o texto e os comandos que precisamos pra que o documento saia do jeito que a gente quer.
Isso significa que, ao contrário de quem usa Word ou Google Docs, quem usa LaTeX inevitavelmente precisa montar um pequeno ecossistema de ferramentas: um editor, um sistema de compilação, um visualizador de PDF, uma ferramenta de bibliografia, e assim por diante. Parte da dificuldade inicial do LaTeX não está exatamente na linguagem em si, mas em organizar esse workflow de forma que ele fique prático de usar no dia a dia.
Ao longo dos anos, eu fui passando por vários editores e ambientes diferentes.
Emacs, fase 1
No começo, eu “herdei” o hábito de usar emacs, diretamente das pessoas que me influenciaram a começar a usar o LaTeX. Isso tudo aconteceu em um ambiente chamado “Projeto Sócrates”, um servidor Linux que começou como um ambiente para os alunos da disciplina de Cálculo Numérico no IFUSP, e que acabou se expandindo até acolher todos os alunos do Instituto. O Sócrates oferecia um ambiente Linux controlado, com uma instalação Debian Slink, e com um conjunto de configurações razoavelmente idiossincráticas, baseadas nas preferências da equipe que gerenciava o servidor. Então, foi um passo natural usar as mesmas ferramentas que eles – incluindo o Emacs.
Era uma configuração “padrão”, no sentido de que ele tinha um certo conjunto de preferências pré-definido, e eu não mexi muito nisso. Naquela época não existia muito o conceito de IDE (Integrated Development Environment) ainda, então a gente escrevia tudo na mão mesmo, e no máximo tinha um pouco de syntax highlighting e umas macros pra facilitar alguns passos (como abrir e fechar ambientes por exemplo). Não era nada muito avançado, mas era confortável o suficiente pra eu começar a me aventurar pelo LaTeX.
Eu continuei com versões dessa mesma configuração, com mudanças incrementais ao longo dos anos, por um longo tempo. Até tentei experimentar com algumas coisas aqui e ali, mas fiquei basicamente fixo nos princípios básicos do que eu tinha aprendido a usar – e sendo uma pessoa que gosta de pouca variabilidade, isso foi confortável, pelo menos por um tempo.
Hiato, exploração e Vim
Depois disso, passei por um hiato no uso de LaTeX – houve uma época em que eu não tinha muita demanda por criar documentos no estilo típico dele, e por isso eu usava pouco. As poucas ocasiões em que eu usei, tentei usar diferentes editores – muitos dos quais eu nem lembro mais o nome – e nunca me fixei em nenhum.
Algum tempo depois, quando comecei a me enveredar pela Ciência da Computação, comecei a usar o Vim – um editor muito bom pra quem programa. O Vim tem o bônus de ser um sucessor espiritual do ed, o editor original do Unix (e essa importância história pra mim é muito forte). Montei toda uma configuração pra poder escrever código LaTeX com ele, mas não fiquei muito feliz com o resultado final.
Acontece que o Vim é ótimo pra programar, porque ele é multi-modal. Programação muitas vezes envolve ficar navegando pelo código, avaliando algoritmos, mudando pequenas coisas aqui e ali. LaTeX não funciona assim; é mais sobre a evolução e a progressão do conteúdo, então a gente passa muito mais tempo editando do que revisando. Por isso não me adaptei muito bem com o Vim pra LaTeX. Ainda uso ele pra programar algumas coisas (cheguei até ao paradoxo de usar o Vim pra editar a configuração do Emacs), mas não pro LaTeX.
VS Code Codium
Depois disso, experimentei o VS Code, e rapidamente migrei para o VS Codium, que é a versão open source do mesmo editor. Esse foi, por um tempo, o ambiente que eu mais usei para LaTeX.
O VS Codium tem várias coisas interessantes: auto-complete, integração com extensões, visualização de PDF integrada, gerenciamento de projetos, etc. A extensão de LaTeX (LaTeX Workshop) é, de modo geral, muito boa e bastante poderosa. Dá para montar um workflow funcional com ela sem muito esforço. E, se você não tem mania de ficar fuçando em configuração pra deixar as coisas de um jeito que você ache mais interessante, dá pra parar por aí.
Mas começaram a aparecer alguns problemas.
Primeiro, a configuração é meio esquisita. Existem várias camadas de configuração: configurações do editor, da extensão, do sistema de compilação, recipes de build, caminhos de ferramentas, e assim por diante. Nada disso é impossível de configurar, mas a sensação é de que você está sempre tentando descobrir qual arquivo ou qual opção controla determinado comportamento. E como se isso não bastasse, as opções são documentadas bem porcamente.
O segundo problema foi mais sério para mim: o VS Codium, através da extensão LaTeX Workshop, não respeita completamente as configurações do latexmkrc. Foi justamente durante esse período usando o VS Codium que eu comecei a mexer mais seriamente com a configuração do latexmkrc, tentando automatizar o processo de compilação, organizar diretórios auxiliares, definir engines padrão e outras coisas do tipo. E foi aí que eu percebi que a extensão simplesmente ignorava algumas dessas configurações ou tentava impor o próprio esquema de compilação.
Quando tentei procurar ajuda e entender melhor o comportamento da extensão, a experiência com os desenvolvedores não foi exatamente agradável. Em vez de tentar entender o problema ou considerar mudanças, a resposta foi basicamente que o comportamento era aquele mesmo e pronto.
Nesse ponto, por uma mistura de frustração técnica e pirraça, eu resolvi abandonar o VS Codium e voltar para o Emacs — mas dessa vez com a ideia de configurar o ambiente direito, em vez de usar uma configuração padrão como eu tinha feito muitos anos antes.
Foi aí que o meu setup atual começou a tomar forma.
Fim da historinha
No fim das contas, o LaTeX não é apenas uma ferramenta para escrever fórmulas bonitas ou formatar referências automaticamente. Ele representa uma forma diferente de pensar a escrita: o documento deixa de ser algo que você “edita visualmente” e passa a ser algo que você constrói, compila e organiza como se fosse um programa. Em vez de arrastar coisas pela página, você descreve a estrutura do documento; em vez de ajustar manualmente a formatação, você define regras; em vez de ter um arquivo final que depende de um programa específico, você tem um código-fonte que pode ser recompilado a qualquer momento.
Essa mudança de paradigma costuma ser estranha no começo, principalmente para quem está acostumado com editores WYSIWYG como Word ou Google Docs, mas depois de algum tempo fica difícil voltar atrás. A separação entre conteúdo, estrutura e formatação, junto com a possibilidade de automatizar praticamente tudo no processo de compilação e organização do documento, acaba tornando o LaTeX uma ferramenta extremamente poderosa para quem escreve textos técnicos, científicos ou documentos longos.
Mas o LaTeX, por si só, não resolve tudo. Ele não é um editor de texto, não é um sistema de compilação completo e não é um sistema de versionamento. Para que o workflow realmente funcione de forma confortável, é preciso montar um pequeno ecossistema de ferramentas ao redor dele: um editor, um sistema de compilação automatizado, uma forma de organizar os arquivos do projeto e, idealmente, um sistema de versionamento.
Ao longo dos anos, eu fui passando por vários editores e ambientes diferentes até chegar ao conjunto de ferramentas que uso hoje, baseado principalmente em Emacs, latexmk e Git. Esse setup não surgiu de uma vez só; ele foi sendo construído aos poucos, resolvendo problemas específicos que iam aparecendo ao longo do tempo.
Este post acabou ficando mais conceitual e histórico do que técnico, mas eu resolvi abraçar a ideia. agora, este é o primeiro de uma pequena série de posts sobre LaTeX, workflow e organização de projetos. Nos próximos textos, vou entrar mais na parte prática e técnica: editores, automação de compilação com latexmk, configuração de latexmkrc, estrutura de diretórios para projetos LaTeX, versionamento com Git e outras coisas que foram se acumulando ao longo dos anos.
Em outras palavras, este post é mais sobre por que usar LaTeX e como pensar documentos em LaTeX. Os próximos serão mais sobre como organizar um ambiente de trabalho para que isso funcione de forma eficiente no dia a dia.
Deixe um comentário