Como o NeoVim apagou o histórico do Vim e reacendeu o debate sobre perda de dados

O cientista da computação David Chisnall revelou que a instalação e o uso inicial do NeoVim causaram a exclusão irreversível dos arquivos de histórico de alterações (persistent undo) criados originalmente pelo Vim. O relato, compartilhado na rede social Mastodon e analisado pelo designer e pesquisador Marcin Wichary no projeto editorial Unsung, detalha um incidente em que o novo editor sobrescreveu dados pré-existentes sem realizar migração ou utilizar nomes de arquivos distintos no sistema de arquivos do usuário.

Usuário ativo do Vim desde aproximadamente o ano 2000, David Chisnall construiu ao longo de mais de duas décadas uma rotina profissional amparada na estabilidade da ferramenta. Nesse período, o pesquisador escreveu cinco livros técnicos, uma tese de doutorado (PhD), dezenas de artigos acadêmicos e mais de 150 artigos gerais diretamente no editor de texto, desenvolvendo uma memória muscular tão enraizada que comandos rotineiros como o salvamento via :w passaram a surgir involuntariamente até mesmo em outros editores de texto estruturado.

O ponto central do atrito técnico envolve o recurso de desfazer persistente, identificado formalmente como persistent undo. Conforme explicou David Chisnall, essa funcionalidade permite fechar arquivos, reiniciar o sistema operacional ou retornar a um código após semanas ou meses sem perder o encadeamento de modificações anteriores, mantendo a capacidade de resgatar trechos excluídos acidentalmente antes de um comando de sincronização ou envio para controle de versão.

O papel do persistent undo

Diferente de editores que descartam o histórico de operações ao encerrar a sessão de processos em memória RAM, o Vim mantém o persistent undo gravando arquivos dedicados em disco. David Chisnall destacou que, ao longo de aproximadamente vinte anos e através de múltiplos lançamentos de versões principais do Vim, a estrutura interna desses dados foi preservada sem quebras estruturais ou perdas silenciosas, mantendo a integridade do trabalho acumulado.

Eu não preciso do persistent undo com frequência. Mas nas raras ocasiões em que precisei, ele foi inestimável: 'ops, deletei algo deste arquivo, talvez na semana passada e antes de reiniciar a máquina, o que era?'. Desfazer até encontrar, copiar e colar na versão atual. O Vim manteve isso funcionando através de atualizações de versões principais por um período de cerca de 20 anos.

Essa consistência histórica no Vim oferecia aos desenvolvedores a garantia prática de que modificações antigas em arquivos de texto poderiam ser recuperadas com precisão temporal. Como apontado por David Chisnall, o mecanismo operava de forma invisível: mesmo que o computador sofresse uma falha crítica ou um encerramento forçado do processo, a cadeia retroativa de edições permanecia acessível quando o arquivo voltava a ser aberto meses depois no mesmo ambiente de trabalho.

A perda de dados no NeoVim

A decisão de testar o NeoVim surgiu logo no período inicial do projeto, divulgado amplamente pela comunidade de código aberto como uma bifurcação moderna (fork) desenhada para revitalizar a base legada do Vim. Atraído pela promessa de encontrar a experiência tradicional do editor clássico sob uma arquitetura supostamente aprimorada, David Chisnall executou o binário sobre arquivos que já continham árvores de modificações registradas.

Ao carregar o primeiro documento no NeoVim, o cientista da computação constatou de imediato que o comando para desfazer ações não respondia. O problema agravou-se no momento em que David Chisnall tentou reabrir o mesmo arquivo no próprio Vim tradicional: o histórico pré-existente de modificações havia desaparecido por completo, quebrando a cadeia de restauração que vinha sendo sustentada há anos no sistema de arquivos local.

A investigação do comportamento do software revelou a mecânica da falha de interoperabilidade: o NeoVim alterou o formato binário dos arquivos de persistent undo em relação ao padrão adotado pelo Vim. Em vez de migrar o conteúdo anterior, criar extensões de nomenclatura próprias ou ignorar o arquivo em caso de incompatibilidade técnica, o novo editor simplesmente detectou o arquivo gerado pelo Vim, deletou-o do disco rígido e gravou uma nova versão incompatível no lugar.

O Neovim havia alterado o formato dos arquivos de undo. Ele não converteu o antigo. Não usou um nome diferente para seus arquivos de undo. Ele apenas notou a existência de um arquivo de undo do Vim, deletou-o (perdendo todos os dados contidos nele) e o substituiu por um que o Vim não conseguia ler.

A exclusão automática destruiu registros de alterações que continham versões históricas de documentos desenvolvidos por David Chisnall. Ao eliminar fisicamente os registros legados sem notificar o usuário por meio de avisos de terminal ou caixas de diálogo, o NeoVim anulou a capacidade de retorno a estados anteriores do código, expondo a fragilidade de adotar ferramentas derivadas sem isolamento estrito de metadados.

A resposta dos mantenedores

Diante da perda de dados em seu ambiente de trabalho, David Chisnall abriu um relatório de erro formal (issue) no repositório oficial do NeoVim para alertar os desenvolvedores sobre a substituição destrutiva de arquivos do Vim. A resposta apresentada pela equipe responsável pelo fork, no entanto, minimizou a gravidade da remoção de arquivos em disco.

Os mantenedores do NeoVim afirmaram ao pesquisador que o formato do persistent undo era considerado instável pela equipe técnica e que os usuários não deveriam presumir que dados seriam preservados sob uma funcionalidade cujo próprio nome técnico continha o termo persistent. A equipe reforçou que a estrutura interna de armazenamento já havia sofrido alterações anteriores e que provavelmente mudaria novamente em versões subsequentes.

Abri uma issue sobre isso e fui informado de que o formato de persistent undo era instável e que os usuários não deveriam confiar na preservação de dados em um recurso explicitamente chamado persistent undo. Ele havia mudado uma vez e provavelmente mudaria de novo.

A postura adotada encerrou em definitivo qualquer uso continuado do NeoVim por parte de David Chisnall. Em sua análise, o cientista da computação enfatizou que erros de programação em rotinas de desfazer podem ser compreendidos como falhas normais do ciclo de engenharia de software, mas a postura dos mantenedores revelou a ausência de um princípio ético básico de custódia e proteção dos ativos digitais que residem na máquina do usuário.

Para o autor, a premissa de que arquivos persistentes em disco podem ser descartados arbitrariamente por um aplicativo novo apenas porque a equipe decidiu modificar uma especificação interna demonstra um desalinhamento grave com padrões consolidados na comunidade de computação. David Chisnall sintetizou a decisão de abandonar a ferramenta ressaltando que desenvolvedores que agem dessa forma mostram que não compreendem o dever de cuidado para com quem utiliza seus sistemas.

As leis de Jef Raskin

A discussão ganhou dimensão metodológica quando Marcin Wichary associou o episódio relatado por David Chisnall aos princípios concebidos pelo pioneiro de interfaces Jef Raskin. Notabilizado pelo trabalho no projeto original do Macintosh e pela criação do computador Canon Cat, Jef Raskin formalizou as bases do design centrado no ser humano em sua obra The Humane Interface, publicada no ano 2000.

O texto de Jef Raskin define três leis fundamentais para a interação entre pessoas e sistemas computacionais, formuladas de maneira análoga às clássicas leis da robótica da ficção científica. A chamada Primeira Lei de Raskin estabelece o princípio central violado pelo comportamento do NeoVim ao manipular os dados do Vim:

• Primeira Lei: Um computador não deve prejudicar o seu trabalho ou, por inação, permitir que o seu trabalho seja prejudicado.
• Segunda Lei: Um computador não deve desperdiçar o seu tempo ou exigir que você realize mais trabalho do que o estritamente necessário.
• Terceira Lei: Uma interface é humana se for responsiva às necessidades humanas e atenciosa com as fragilidades humanas.

O resgate feito por Marcin Wichary destaca que o livro The Humane Interface serviu como marco estruturante para gerações de designers de software ao estabelecer que a custódia dos dados do usuário é um mandato absoluto. Quando uma aplicação ignora a Primeira Lei de Raskin e deleta intencionalmente arquivos gravados por outro programa, rompe-se o contrato tácito que permite ao profissional confiar seu trabalho diário ao ecossistema digital.

O dever de cuidado com arquivos

A análise conduzida por Marcin Wichary no Unsung sintetiza o motivo pelo qual relatos como o de David Chisnall geram repercussão duradoura: os usuários retêm na memória a experiência de terem seu trabalho danificado ou desrespeitado pela engenharia de uma ferramenta. Frases institucionais como a declaração de que o formato de armazenamento 'havia mudado uma vez e provavelmente mudaria de novo' reforçam uma sensação de instabilidade inaceitável para quem gerencia dados em nível de produção.

Em ambientes de desenvolvimento de software, a integridade do sistema de arquivos baseia-se na segregação segura de espaços de nomes (namespaces). Ao herdar a infraestrutura operacional do Vim, o NeoVim assumiu o ônus de interagir com estruturas já padronizadas, nas quais a remoção silenciosa de arquivos de desfazer gerados desde o ano 2000 representou uma quebra direta de expectativas funcionais.

Para profissionais e equipes de tecnologia, a lição deixada pelo embate entre o Vim e o NeoVim documentado por David Chisnall e Marcin Wichary reside na constatação de que a inovação técnica em bifurcações de código aberto não pode prescindir do respeito aos dados persistentes. Como concluiu Chisnall ao retornar ao editor tradicional com o qual produziu cinco livros e centenas de pesquisas, a estabilidade e a preservação do trabalho acumulado continuam sendo o parâmetro definitivo para a confiança em um software.