Recentemente comecei a me preocupar em otimizar mais o meu fluxo de trabalho. Vou contar de forma resumida a história de como cheguei a essa conclusão e mencionar minhas ferramentas de escolha até o momento.
Como um usuário inconsequente de Linux, já usei gerenciadores de janelas mais esotéricos e brinquei bastante com o Vim, que, inclusive, junto ao WordGrinder, é por onde atualizo este site. Contudo, sempre retornava à minha zona de conforto em um gerenciador de janelas empilhadas e no IntelliJ como editor de código. Não demorou para que eu pensasse em substituir o IntelliJ pelo Geany. Veja, ele é pouco usado, mas ainda possui uma estrutura ortodoxa, e sua extrema leveza me pouparia das eventuais travadas que a IDE proprietária causava na minha máquina.
Como estava estudando desenvolvimento de jogos em Java, migrei e me deparei com uma barreira: Compilação/Interpretação. Java com certeza foi a linguagem que mais usei no meu processo de estudar programação e, mesmo assim, usando ferramentas como o BlueJ, Android Studio e Eclipse, nunca precisei compilar propriamente. Ou seja, sem perceber, havia criado uma dependência do meu fluxo de trabalho a esses programas. Essa é a burrice inerente de hiperautomatizar processos. E ainda há quem prefira trabalhar com game engines; vai entender.
Quebrei a cabeça com alguns tutoriais e, em poucas horas, estava funcionando! Ao pressionar um botão, conseguia compilar o projeto e acessar os assets de forma até mais prática do que no Eclipse, onde é necessário ficar atualizando essa pasta. Daí eu percebi que conseguia trabalhar com o Geany, mas não só com ele. Com qualquer ambiente que eu queira. Nisso surgiu aquela sugestão natural: "e se formos além?".
Tirei a poeira do Vim e dediquei-me a estudar como aproximá-lo da experiência de uma IDE. Outro erro. Ele não é uma IDE. Existe um jeito particular de executar tarefas nesse programa. Um jeito que, como você lerá a seguir, não é sempre o melhor, mas, desde que você entenda o que está fazendo, com as devidas alterações, se torna uma lâmina afiada. Como estava usando várias janelas simultaneamente, também migrei para o Ratpoison como gerenciador de janelas. Já tinha usado, achei interessante, mas nunca mexi o suficiente para torná-lo prático. Também tentei experimentar não usar gerenciadores de arquivos gráficos. Foi no mínimo interessante, e você pode saber com detalhes na próxima seção.
Vim e seus Plugins. Eu admiro um usuário de Vim puro, assim como admiro um bom católico. Infelizmente, eu não sou nenhum dos dois, mas em relação ao primeiro título, eu consigo me justificar.
"Hãã, veja bem..." A ideia do Vim é que você passará a maior parte do seu tempo editando código do que escrevendo. Para isso, é necessário que você pule rapidamente entre diversos arquivos e partes desses arquivos. O editor, por padrão, oferece funções como "find", "grep", "vimgrep" e "edit" para fazer isso. Você consegue, inclusive, procurar recursivamente informações em subdiretórios usando o coringa "*"; com ele, você nem precisa saber o nome inteiro do que está procurando. Não só isso, como existem as "CTAGS", que são geradas por um programa externo e permitem que você pule diretamente para a definição de funções. Porra, perfeito, não!?
Na verdade, mais ou menos. Essas buscas recursivas só vão funcionar se você estiver trabalhando com projetos pequenos ou com o escopo específico de um projeto. Um joguinho pode até funcionar, mas, no mundo real, tenho que trabalhar com coisas mais complexas e essas ferramentas podem levar até 30 segundos para achar o que estou procurando. Mesmo as CTAGS funcionam perfeitamente apenas para tecnologias pré-2015. Depois disso, a linguagem que você estiver usando pode simplesmente não ser suportada. Então será necessário algum plugin.
Essas são as alternativas à disposição: FuzzyFinder+RipGrep e LSP. O primeiro é uma combinação de ferramentas desenvolvidas para procurar nomes de arquivos/conteúdos em arquivos de forma extremamente rápida, interativa e eficiente. Ele funciona em qualquer tipo de projeto e torna obsoletas as ferramentas padrão. Esse é um dos quatro plugins que uso e levaria para qualquer lugar. Infelizmente, não funciona na minha geladeira.
O LSP, o servidor LSP, a grosso modo, é um meio de ter seu código interpretado de forma assíncrona pela sua máquina. É isso que as IDEs fazem. Enquanto você escreve, o plugin levanta sugestões, aponta linhas com avisos, erros e substitui as CTAGS, permitindo que você pule para definições de funções. Eu não gosto de usá-lo por trazer muitas coisas ao mesmo tempo e funcionar como uma caixa preta à qual não sei exatamente o que está acontecendo. Além disso, o compilador já faz a maioria dessas funções de forma síncrona. O ganho de tempo não me parece uma troca tão vantajosa nesse caso.
Agora, sobre autocomplete. Eu admito, eu não quero escrever palavrinhas inteiras, mas há dois detalhes nisso. O Vim já possui um autocomplete síncrono. Você chama ele por meio de comandos como Ctrl+N. Você pode chamar diferentes autocompletes que usam bases de sugestões diferentes, por exemplo: relacionando ao arquivo em que você está, aos buffers abertos, às tags e até o Omnicomplete, que interpreta o seu código (de uma forma mais grosseira que um LSP). O outro detalhe são os plugins que usam o LSP como base para sugestões assíncronas, como o COC.vim (você leu corretamente, eu que não vou usar esta porra!).
Assim como um social-democrata que se orgulha de estar em cima do muro, eu encontrei um meio-termo nisso. Chama-se "vim-auto-popmenu", que utiliza os próprios autocompletes do Vim como base para um autocomplete assíncrono. Você tem que configurar qual tipo vai funcionar (arquivo atual, buffers, etc.), mas já é mais do que suficiente para mim.
Para completar o conjunto de plugins relacionados a códigos, também há o gitbranch, que mostra a branch atual na linha de status. Dá para ter isso direto no vimrc, mas não queria perder muito tempo configurando.
Isso, somado a algumas configurações particulares, constitui menos de 50 linhas do meu ".vimrc". O que quase se encaixa como minimalista para o padrão de usuário médio.
Se você fez as contas, está faltando um plugin, certo? Sim, mas esse já deixa de fazer parte do ambiente de código. Trata-se do Vimwiki. Ele cria uma wiki offline; um ambiente de produtividade com uma linguagem de marcação própria que permite criar listas de afazeres, linkar diferentes arquivos e organizar informações. Uma versão simplificada do orgmode para usuários de Emacs.
É possível converter as páginas em HTML e, não ironicamente, penso em migrar esse site para lá.
Meu uso ficou tão integrado a essa ferramenta que uso inclusive como uma "barra de favoritos" agnóstica. Independente do navegador, ela sempre vai funcionar.
Também pensei em usar o Vim como gerenciador de arquivos. Não vale a pena. Mesmo que você use plugins como Dovish, hora ou outra vai encontrar uma limitação irritante. Existe o Olive.nvim, mas aí precisa usar o Neovim, e isso não me é motivo suficiente para deixar a versão boomer do editor.
Meu último comentário a respeito do Vim é algo que tenho de lembrar a mim mesmo: "Estou fazendo isso da melhor forma possível?" Talvez não, e é sempre interessante pesquisar sobre como outras pessoas fazem, ler os manuais embutidos e testar. O respeito pelos usuários que utilizam o editor de forma pura, além de soar "raiz", vem do fato de terem compreendido profundamente a ferramenta que usam.
Isso conclui a maior parte do texto. As demais ferramentas que uso ainda não foram dedicadas tanto tempo. O que posso dizer sobre o "filemanager" de minha escolha, o nnn, é que ele não perde em nada para as outras alternativas. Nem empata. Leve, extensível e rápido. Para falar a verdade, uso-o somente para manipular grandes volumes de arquivos. Ele permite usar o próprio Vim para renomear todos os arquivos de uma pasta, por exemplo. É brutal, mas muito ocasional.
Já sobre o Ratpoison, é um "window manager" do tipo "tilling" que abre os seus programas formando mosaicos de janelas que não se sobrepõem. O diferencial dele, além de ser muito leve (algo de minha preferência, como pode perceber), é o fato de não focar nas janelas com o mouse. Se quiser trocar de janela, faça-o manualmente. Pode parecer trabalhoso, mas, quando muitos dos seus programas são orientados a teclados, ele disciplina você a não perder tempo indo até o rato. Por isso o nome "veneno de rato".
Para falar a verdade, se utilizá-lo como vem instalado, você terá tendinite em uma semana, então pesquise como remapear os botões. Eu consigo ver o potencial dele em junção com alguns shell scripts, mas não vou entrar muito em detalhes pois quero me apropriar disso primeiro.
Existem programas que não funcionam perfeitamente nele, então abro o jwm, que é do tipo empilhado só para fazer as configurações, mas suspeito que conseguiria fazer pelo evilwm que é o gerenciador de janelas mais leve que conheço.
Há ainda alguns pormenores nisso tudo como praticar digitação a partir de técnicas de datilografia. Isso zerou algumas dores que eu tinha nas mãos e melhorou minha velocidade. Contudo, a nível de notas acho que está mais do que suficiente.