NeoVim rompe el undo persistente y revela falta de deber de cuidado

David Chisnall, científico informático con décadas de uso de vim, publicó en Mastodon una reflexión que parte de su experiencia personal: lleva usando vim desde el año 2000, ha escrito libros, una tesis y cientos de artículos, y confía en el persistent undo para recuperar cambios incluso meses después.

Para Chisnall, esa capacidad encarna la primera ley de Jef Raskin – un programa no debe dañar los datos del usuario ni, por inacción, permitir que se dañen – y es esencial para flujos de trabajo donde la estabilidad del historial de ediciones es crítica.

Cuando probó NeoVim en sus primeras versiones, descubrió que el deshacer ya no funcionaba. El fork había cambiado el formato de los archivos de undo, eliminó los existentes y los sustituyó por uno que Vim no podía leer. Chisnall abrió una incidencia en GitHub y recibió la respuesta de que el formato era “inestable” y que los usuarios no debían confiar en él.

Esa actitud, según el autor, muestra una ausencia de duty of care: si un programa crea archivos persistentes que el usuario espera que sobrevivan, no debería borrarlos arbitrariamente. La confianza en la herramienta se rompe y el daño potencial es real: pérdida de semanas de trabajo o de correcciones realizadas bajo presión.

El caso ilustra dos puntos clave para desarrolladores y administradores de sistemas:

• La compatibilidad de formatos de datos entre versiones y forks debe mantenerse o, al menos, documentarse con antelación. Cambios silenciosos generan interrupciones en pipelines de CI/CD y en entornos de desarrollo.
• Las decisiones de diseño que afectan la integridad de los datos deben acompañarse de una política clara de migración o de advertencias explícitas. Ignorar la responsabilidad de preservar la información del usuario vulnera principios de usabilidad y fiabilidad.

Chisnall también cita a Jef Raskin y sus tres leyes de la interacción humana, recordando que la primera ha sido olvidada en muchos proyectos de código abierto que priorizan la innovación sobre la preservación de datos. El debate sigue vivo en los comentarios de la publicación original, donde varios usuarios comparten experiencias similares con otras herramientas que modifican formatos de archivo sin aviso.

Qué sigue: la comunidad de NeoVim tendría que publicar un plan de migración para el formato de undo o, como mínimo, ofrecer una opción de compatibilidad. Mientras tanto, los usuarios que dependen del persistent undo deberán seguir con Vim o implementar scripts que respalden los archivos de undo antes de actualizar.

---

Este artículo se basa en la publicación de David Chisnall en Mastodon y la discusión que generó en la comunidad de Vim/NeoVim.