Gosto da ideia do Emacs de que tudo é um buffer: arquivos, diretórios, shells, resultados de busca. O que não gosto é que cada modo do Emacs vem com as próprias teclas.
No Neovim eu tento ficar com a primeira parte sem a segunda, e manter as teclas do Vim funcionando do mesmo jeito em todo lugar.
Por que buffers
Um buffer é só texto. Tudo que é buffer já funciona com o que eu sei: me mover, buscar, copiar, editar, desfazer.
O que não é buffer normalmente é uma janela nova com as próprias teclas. Instale dez plugins assim e você tem dez ferramentinhas na mesma tela, cada uma com as suas regras. Parece poderoso, mas fica mais difícil de usar, porque o que você aprende numa não ajuda na outra.
Uma pergunta antes de adicionar um plugin
Isso me dá um buffer, ou uma janela nova com as próprias teclas?
Os plugins de que mais gosto diminuem o que eu preciso decorar, e o oil.nvim é o melhor exemplo. Ele mostra um diretório como um buffer. Pra mover um arquivo, dou dd, p em outro lugar e salvo com :w. Pra renomear, edito o nome. Não precisei aprender nada novo.
Recursos nativos muitas vezes ganham pelo mesmo motivo. O nvim.difftool nativo coloca os arquivos alterados de um git difftool -d na quickfix list, que eu já sei usar. O diffview.nvim faz o mesmo trabalho numa janela própria, com as próprias teclas, então fiquei com o nativo.
Sinais de que algo não se encaixa
- Teclas que só funcionam numa janela. Você precisa saber onde está antes de saber o que uma tecla faz.
- Coisas que você não acha de novo. Não aparecem no
:lse não dá pra reabrir depois. - Resultados que não viram texto. Não dá pra buscar neles, filtrar ou rodar de novo.
O último passa despercebido fácil. Um fuzzy picker normalmente esquece a sua busca quando fecha. O :grep não esquece, porque fica no histórico de comandos, e o q: abre esse histórico como um buffer. Subo até a última busca, troco uma palavra e rodo de novo.
Isso só me importa pra buscas. Pra voltar a um arquivo, o :ls basta.
A quickfix list junta tudo
Quase toda busca minha acaba na quickfix list, e a partir dela tudo funciona junto:
| Ferramenta | O que faz |
|---|---|
:grep com ripgrep |
preenche a lista |
:Cfilter |
filtra a lista |
:cdo / :cfdo |
roda um comando em cada resultado, ou em cada arquivo |
:colder / :cnewer |
navega entre listas mais antigas e mais novas |
nvim.difftool |
usa uma quickfix list pras mudanças do git |
Como é sempre o mesmo tipo de lista, os mesmos comandos funcionam em tudo.
O mesmo vale pros mapeamentos
Mapeamentos também se acumulam, e é fácil não perceber porque eles não aparecem em lugar nenhum. Faço uma pergunta parecida: esse mapeamento me poupa de algo, ou é mais uma coisa pra lembrar?
Dois tipos normalmente não valem a pena:
- Um atalho pra um comando que já funciona em todo lugar.
<Space>gpra:grepeconomiza quatro teclas, mas o:grepfunciona em qualquer Vim ou Neovim, sem configuração. - Refazer algo que outra ferramenta já faz. Eu tinha dez linhas de Lua pra abrir um arquivo do lado do atual. Com o oil, o
-já faz isso.
Pra abrir arquivos fiquei com três jeitos, dependendo do que eu sei:
| Quando | Como |
|---|---|
| Não sei o nome, ou está do lado do arquivo atual | - (oil) |
| Sei o nome, em qualquer lugar do projeto | :E, um comando meu (fuzzy match no rg --files) |
| Sei o caminho completo | :e |
Eu tinha quatro mapeamentos pra isso e agora tenho dois: - pro oil, e <Space>r, que começa o :E. Os outros dois não me poupavam de nada.
Onde a regra não vale
- O menu de autocompletar é um popup em qualquer editor, e tudo bem.
- Um picker rápido, que abre e fecha em dois segundos, também está ok, desde que eu não precise daquela busca de novo.
O meu próprio plugin, pathpick.nvim, copia o caminho do arquivo atual em vários formatos. Ele abre sim um popup pequeno, mas cada linha é exatamente o texto que vai ser copiado, então yy, / e o modo visual funcionam como em qualquer outro buffer.
Então a minha regra é mais estreita que “nada de popups”: tudo que eu quero reencontrar deve ficar num buffer.
Minha config hoje
Neovim 0.12 com o gerenciador de plugins nativo, o vim.pack, e três plugins: oil.nvim, pathpick.nvim e treesitter (que só melhora o destaque de sintaxe e não adiciona janela nem teclas). O resto é nativo ou poucas linhas da minha config: a quickfix list, o :Cfilter, o nvim.difftool e o fuzzy matching. Os plugins que tirei não tinham nada de errado; eles só faziam, numa janela própria, coisas que um buffer já fazia.
Por que não usar o Emacs, então?
Eu testei. O Emacs coloca tudo num buffer, e muitas teclas funcionam em todo lugar, mas cada modo acrescenta as próprias teclas por cima, e elas não valem no modo seguinte.
O Vim tem três modos principais (Normal, Insert e Visual), e eles funcionam igual em todo lugar. Você combina uma ação com um alvo: ci" muda o que está dentro das aspas, daw apaga uma palavra, >ip indenta um parágrafo. Isso funciona num arquivo de código, no q: e no oil. Quando aprendo uma ação nova, ela funciona em tudo que eu já conheço. No Emacs, aprender um comando novo normalmente me dava só um comando novo.
Tem também um motivo prático. Trabalho no terminal o dia todo, no foot com tmux (escrevi sobre o meu setup), e o Vim nasceu pro terminal.
Livro recomendado
Practical Vim, do Drew Neil, é um livro incrível. Ele ensina a pensar em como usar o Vim, que é o que você precisa pra entender o Vim de verdade.