Uma carta de amor ao Neovim

• Neovim faz com que a edição de código seja menos sobre digitar rápido e mais sobre um loop repetitivo de navegar, modificar, apagar, reorganizar e verificar testes
• A gramática de edição do Vim reduz o atrito da edição repetitiva ao combinar operações por unidades de significado, como ci", dap, ., macros e objetos de texto
• O Neovim não impõe explorador, terminal nem painel de Git, e coloca o buffer no centro para que o usuário escolha ferramentas como Telescope, Fugitive e LSP
• A configuração pode ser possuída como arquivos no Git e continua sendo parte de um sistema que funciona junto com shell, tmux, ripgrep, git e language server
• Foi modernizado com Lua, LSP embutido, Treesitter e Lazy.nvim, mas seu valor central está no fato de que os comportamentos aprendidos se acumulam por muito tempo e fazem o fluxo de trabalho evoluir diretamente

---

A sensação de trabalho que vai do Vim ao Neovim

• O uso do Vim começou em 2011, e no início houve fases de copiar .vimrc sem entender ou mesmo sem entender por que j não inseria um caractere e movia o cursor
• A primeira semana foi difícil e o primeiro mês pareceu estranho, mas depois que o modelo do Vim se tornou familiar, outros editores passaram a parecer como se houvesse uma camada de amortecimento entre o código e o usuário
• Foram usados vários editores como VS Code, JetBrains IDE, Sublime, Atom e Zed; as ferramentas da JetBrains são muito poderosas, e o VS Code teve sucesso por ser bom o suficiente para quase todo mundo e fácil de expandir
• Mesmo assim, o motivo para continuar usando Neovim é que ele se move de acordo com a forma de trabalhar e dá suporte direto ao loop repetitivo da edição de código

Tratar a edição não como atalho, mas como linguagem

• Editar código não é uma questão de digitar rápido, mas algo mais próximo de um trabalho repetitivo de navegação, pequenas mudanças, remoção de abstrações erradas, reorganização de funções, movimentação de arquivos e verificação de testes e diagnósticos
• A maioria dos editores trata o texto como documento e o teclado como dispositivo de entrada, mas o Vim trata a edição como gramática
• ci" altera o conteúdo entre aspas, dap apaga um parágrafo, e . repete a última mudança
• Macros permitem ensinar uma pequena rotina uma vez e repeti-la por um arquivo inteiro, e os objetos de texto permitem aplicar operações a unidades de significado em vez de contar caracteres
• Quando a gramática do Vim entra nas mãos, diminui a necessidade de arrastar código com o mouse, clicar em barras laterais ou abrir a paleta de comandos para tarefas feitas dezenas de vezes por dia
• Trabalhos frequentes se tornam movimentos pequenos e diretos, e o ruído do editor também diminui

Neovim sem impor um fluxo de trabalho

• Editores centrados em GUI tendem a ter uma visão fixa sobre a posição e a forma do explorador, terminal, painel de Git e depurador, e com o tempo o editor acaba parecendo uma cabine de pilotagem
• O Neovim começa pelo buffer, e o usuário decide o que colocar ao redor
• Se precisar de uma árvore de arquivos, é possível adicioná-la; para busca difusa, dá para escolher uma ferramenta adequada como Telescope ou fzf-lua
• Para integração com Git, é possível usar Fugitive, e LSP, diagnósticos, formatação, snippets, Treesitter, test runner e autocompletar também podem ser usados sem virar um dashboard lento em Electron
• Velocidade não é apenas uma questão de tempo de inicialização, mas de confiança
  • ao pressionar uma tecla, a resposta precisa ser imediata
  • ao abrir arquivos grandes, toda a interface não deve travar
  • em conexão SSH, pareamento com tmux e edições em uma janela pequena de terminal, a sensação do editor usado todos os dias precisa se manter
• Em projeto local, servidor remoto, mudança rápida de configuração, app Rails grande, pequeno script de shell ou escrita em Markdown, é possível usar a mesma navegação, os mesmos comandos e a mesma memória muscular
• Essa consistência se acumula ao longo de toda a carreira

Configuração sob controle e uma ferramenta que continua sendo parte do sistema

• A configuração do Neovim é um conjunto de arquivos no Git, então é possível lê-la, quebrá-la e apagar metade quando se percebe que não precisa mais de certos plugins
• Não há dependência de um banco de dados misterioso de configuração, de um estado de conta sincronizada entendido só pela metade, nem de extensões que passam a se comportar de forma estranha em segundo plano por causa de uma mudança de checkbox de algumas versões atrás
• Muitos editores modernos querem ser o lugar onde tudo acontece, mas o Neovim se contenta em continuar sendo uma parte afiada de um sistema maior
• Ele não tenta substituir o shell e funciona junto com tmux, ripgrep, git, language server, formatter, linter e test runner
• Não precisar possuir a mesa inteira também é um dos motivos pelos quais o Neovim durou tanto
• Desde 2011 surgiram vários editores, ecossistemas de extensões, temas, marketplaces e painéis de IA, mas o Vim já era uma ferramenta antiga, e o Neovim modernizou o que era necessário sem abandonar o motivo pelo qual as pessoas o consideravam importante

Modernização e recompensas de aprendizado que duram

• Lua tornou a configuração melhor, e o ecossistema de plugins também melhorou muito
• O LSP embutido traz recursos de IDE para o editor sem passar uma sensação de inchaço
• O Treesitter modernizou o syntax highlighting e a compreensão de código, e o Lazy.nvim tornou o gerenciamento de plugins rápido e simples
• O principal atrativo do Neovim é que o que se aprende continua útil com o passar do tempo
  • aprender um motion continua ajudando
  • escrever uma macro faz desaparecer uma edição tediosa
  • descobrir um objeto de texto facilita um refactor incômodo
  • ajustar um comando faz com que ele vire parte da mão
• Um editor não melhora porque uma empresa lançou uma nova barra lateral, mas porque o usuário aprende a lidar melhor com ele
• É difícil medir produtividade apenas como “economizei 5 segundos aqui”; ela está na redução do atrito ao longo de milhares de pequenas edições
• Ao alternar entre código, testes, git diff e resultados de busca, é possível manter o foco no problema sem sentir que se mudou para outra sala
• O Neovim tem alta programabilidade e faz com que, em vez de aceitar os padrões, o usuário molde diretamente o próprio fluxo de trabalho
• Se algo incômodo se repete duas vezes, em geral é possível corrigir com um mapeamento, um comando, uma pequena função em Lua, um plugin melhor ou até removendo um plugin
• A configuração evolui de acordo com a forma real de trabalhar, e quando a mudança desejada está clara, há muito pouco entre o pensamento e a edição
• Ao longo de 15 anos, linguagens, frameworks, desempenho das máquinas e modas da indústria mudaram, mas Vim e Neovim continuaram sendo os editores centrais onde o melhor trabalho acontece

[GN⁺]

Opiniões no Lobste.rs

• Comecei a usar vim há 12~14 anos porque precisava de um editor leve que mantivesse o código bem na minha frente
  Comecei a aprender sem usar o mouse e, mais tarde, fiquei feliz ao descobrir que Mitchell Hashimoto também aprendeu vim de forma parecida
  Conheci o neovim por meio do TJ DeVries(https://www.youtube.com/@teej_dv) e do canal dele no YouTube, vendo-o hackear vários projetos como neovim e telescope
  A migração para Lua pareceu natural, e gostei porque já era uma linguagenzinha de que eu gostava
  Os primeiros plugins que usei foram treesitter e telescope, e ainda hoje uso neovim junto com alguns plugins pequenos
  O neovim nunca quebrou para mim, simplesmente funciona bem. Não uso plugins de LLM, e acho que esse ecossistema pode muito bem ficar fora do editor
  Espero que a equipe continue oferecendo apenas um editor de código leve e focado

  • Experiência parecida. Usei vim e emacs por anos e preferia mais o vim, mas sempre invejei o fato de que, enquanto elisp é uma linguagem de programação bem decente, vimscript deixava um pouco a desejar
    Por isso, foi muito atraente ver o neovim adicionar Lua

• Há cerca de 20 anos, pensei no que, além de simplesmente me tornar produtivo, fazia o dia a dia ser agradável
  No topo da lista estavam linux e vim
  Independentemente do tipo de trabalho ou da stack usada, os dois garantiam um ambiente de trabalho ergonômico, familiar e acolhedor

• Em 2009, quando eu estava fazendo entrevistas, comecei a aprender vim para além de :wq, porque todos os funcionários usavam vim e, para trabalhar com eles, não havia outro jeito
  Alguns até desativavam as teclas de seta
  Antes disso, minha experiência com editores de terminal se limitava a usar pico na faculdade, e no dia a dia eu usava os editores GUI populares da época
  Felizmente fui contratado e, desde então, continuei usando vim
  Recentemente percebi que o jeito vim de pensar acabou se espalhando para outras partes da minha vida com software
  Acho que começou quando criei, no macOS com Hammerspoon, um teclado virtual para submapas de gerenciamento de janelas, e no fim do ano passado ficou muito fácil experimentar gerenciamento de janelas em mosaico ao usar Arch Linux
  Já faz um tempo que migrei para neovim e acho ele realmente excelente
  Sei que há muitas piadas e discussões sobre editores, mas, com poucas exceções, ainda tenho dificuldade de entender por que pessoas que escrevem código profissionalmente não usam vim, emacs ou algo parecido
  Em qualquer profissão, é importante escolher a melhor ferramenta para o trabalho, e tratar edição como uma linguagem é uma grande vantagem em software

  • O ponto central do texto é “por que eu amo o Neovim”, não “por que você deveria usá-lo”
    Quanto à parte de “tenho dificuldade de entender” acima, o comportamento, os atalhos e os plugins de editores como VS Code também são muito úteis
    Vale a pena ler a documentação do VS Code com atenção, porque ele realmente faz muita coisa
    E, para algumas pessoas, eu inclusive, mover o cursor com o mouse para qualquer posição do buffer e selecionar qualquer trecho é simples e rápido o bastante
    KISS faz sentido
  • Uso modo vi e comandos de navegação quase everywhere, mas vi, vim, neovim e o viper do emacs só de vez em quando
    Isso porque outros editores muitas vezes são ferramentas melhores para a tarefa
    Em Python, que é o que mais uso hoje em dia, sinto que o PyCharm é uma ferramenta melhor do que eles
    Felizmente existe o IDEAVim, um plugin muito bom, então dá para manter a memória muscular
    No Mac, outra vantagem é que os atalhos do sistema não entram em conflito com os atalhos vi, então dá para escolher o mais adequado ao contexto
    Quando uso C++, acho que o CLion é uma ferramenta melhor, mas o IDEAVim também funciona lá
    Para tarefas avulsas que ficam numa zona meio indefinida, costumo usar o zed, e a emulação de vim dele é bem boa
    É claro que é bom ter um editor de terminal decente ao acessar sistemas remotos, mas quando posso usar uma GUI completa, não gosto tanto assim de editor de terminal
    Gosto de edição modal, mas, se não for preciso abrir mão da memória muscular, acho que há motivos de sobra para usar um editor GUI

• O VS Code, no estado padrão, já é bom o bastante para muitos usos
  Ele já vem com busca de arquivos via ctrl-p, janelas divididas, destaque de sintaxe e suporte a linguagens populares
  Eu esperava que o neovim oferecesse pelo menos algo como ctrl-p por padrão e se tornasse uma espécie de Linux Mint dos editores no estilo vim, com menos preocupações de segurança e uma barreira menor de configuração
  Entendo perfeitamente querer ter a mesma sensação de editor do dia a dia ao fazer pair programming em uma sessão tmux numa máquina acessada por SSH ou ao corrigir problemas numa janelinha de terminal
  Já escrevi muito código profissionalmente em screen/vim sobre SSH e, antes da era das interrupções constantes como o Slack apitando a qualquer momento, isso era de fato extremamente produtivo
  Uma coisa para a qual nunca encontrei um bom substituto em nenhum editor vim foi um depurador visual como os do Visual Studio ou das IDEs da Jetbrains, como CLion e Rider
  Há um poder ali mais acessível do que algo como cgdb
  Velocidade não é só questão de tempo de inicialização, e o neovim também é bom nisso, mas o encerramento padrão do neovim é visivelmente mais lento que o do vim
  Não é algo muito demorado, mas no meu ambiente leva cerca de 1 segundo

• Gosto do modelo do vim. Edição modal é só uma pequena parte disso, e o que valorizo mais no vim do que no helix ou em IDEs comuns é a possibilidade de aprender aos poucos
  Você começa entendendo keybindings e configurando opções, depois coloca condicionais na configuração quando algo não funciona no Windows, em seguida escreve autocmds e funções, e então expande isso para pequenos plugins com base no que aprendeu antes
  Isso não significa que eu ame de verdade vim ou neovim
  O vim ainda tem bugs estranhos que não foram corrigidos há décadas, e o neovim corrigiu muitos bugs, mas trouxe outros no lugar
  O maior pecado do neovim é quebrar a API de Lua a cada atualização
  Cansei de ver avisos de descontinuação toda vez que executo e de ter que corrigir minha configuração antes de fazer o que eu queria fazer
  Se ao menos parte dos recursos novos não fosse exclusiva de Lua, já seria menos ruim
  Caso contrário, eu poderia simplesmente continuar usando vimscript e ficar satisfeito com os mais de 20 anos de compatibilidade