Aprender Vim con dolor de muñeca: expectativas realistas

La motivación con la que uno empieza a aprender Vim casi nunca coincide con la motivación con la que termina usándolo. En mi caso, el detonante no fue la elegancia del editor ni la promesa de productividad, sino un dolor sordo en la muñeca derecha, la del mouse, que aparecía al final de las jornadas largas. Me dijeron, medio en broma, que Vim curaba la tendinitis. Llevo dos años con él y puedo decir dos cosas: la tendinitis no se cura solo con un editor, y aun así no volvería al anterior.

Contexto

El argumento ergonómico de la edición modal es razonable: si las manos no abandonan la fila central, no hay desplazamientos al ratón, no hay viajes al cursor con la mano derecha y no hay estiramientos hacia las flechas. La cuenta es atractiva sobre el papel. Lo que no dice el folleto es que aprender Vim, en términos de productividad neta, te hace más lento durante semanas, posiblemente meses, antes de devolverte la inversión. Si uno empieza esperando alivio inmediato, abandona en tres días.

Tras varios intentos fallidos años atrás, esta vez establecí dos reglas: nada de cambiar de editor de la noche a la mañana, y dolor que persistiera se vigilaría con el fisioterapeuta, no con el .vimrc. La primera me obligó a usar el modo Vim de VS Code durante el primer mes; la segunda me ahorró atribuir a las teclas lo que en realidad era postura y descanso.

Modos, movimientos y objetos de texto

Lo que distingue a Vim no es el editor en sí, sino su gramática. Las teclas no son sólo acciones: son verbos, sustantivos y modificadores que se componen. d borra, i' significa "dentro de las comillas simples", y di' borra lo que hay dentro de unas comillas simples. Esa composición (que en un editor tradicional habría requerido seleccionar con el ratón, cortar y reescribir) es lo que de verdad transforma el ritmo de escritura una vez interiorizada.

Los primeros movimientos esenciales son sencillos: h j k l para el cursor, w y b para palabras enteras hacia adelante y hacia atrás, e para el final de palabra, 0 y $ para inicio y fin de línea, gg y G para inicio y fin del archivo. El cambio cualitativo llega con f y t: fx salta al próximo carácter x de la línea, t, se posa justo antes de la próxima coma. Combinados con verbos (df. borra hasta el próximo punto, ct" cambia hasta antes de la próxima comilla) se evaporan docenas de microoperaciones cotidianas.

Los objetos de texto son la otra mitad de la magia. iw es "una palabra", ip es "un párrafo", i( es "lo que hay entre paréntesis". Cualquier verbo se compone con cualquier objeto: yi) copia lo que hay entre los paréntesis donde está el cursor; da{ borra todo el bloque, incluidas las llaves. Una vez asimilados, escribir código deja de ser un ejercicio de mover el cursor para convertirse en uno de declarar intenciones.

El ecosistema Neovim

Pasé de Vim a Neovim por dos razones: el soporte nativo de Lua como lenguaje de configuración y la integración madura con LSP. Mi gestor de plugins es lazy.nvim, que carga cada plugin bajo demanda y mantiene los arranques del editor por debajo de 50 ms incluso con docenas de extensiones.

-- ~/.config/nvim/init.lua
vim.g.mapleader = " "
vim.g.maplocalleader = " "
 
vim.opt.number = true
vim.opt.relativenumber = true
vim.opt.expandtab = true
vim.opt.shiftwidth = 2
vim.opt.tabstop = 2
vim.opt.signcolumn = "yes"
vim.opt.termguicolors = true
vim.opt.timeoutlen = 350
 
-- kj para salir del modo inserción sin abandonar la fila central
vim.keymap.set("i", "kj", "<Esc>", { silent = true })
 
require("lazy").setup({
  {
    "nvim-telescope/telescope.nvim",
    dependencies = { "nvim-lua/plenary.nvim" },
    keys = {
      { "<leader>ff", function() require("telescope.builtin").find_files() end, desc = "Buscar archivos" },
      { "<leader>fg", function() require("telescope.builtin").live_grep()  end, desc = "Buscar texto" },
      { "<leader>fb", function() require("telescope.builtin").buffers()    end, desc = "Buffers abiertos" },
    },
  },
  {
    "neovim/nvim-lspconfig",
    config = function()
      local caps = vim.lsp.protocol.make_client_capabilities()
      local lsp = require("lspconfig")
      lsp.ts_ls.setup({ capabilities = caps })
      lsp.lua_ls.setup({
        capabilities = caps,
        settings = { Lua = { diagnostics = { globals = { "vim" } } } },
      })
      vim.api.nvim_create_autocmd("LspAttach", {
        callback = function(args)
          local buf = args.buf
          local map = function(k, f) vim.keymap.set("n", k, f, { buffer = buf }) end
          map("gd", vim.lsp.buf.definition)
          map("gr", vim.lsp.buf.references)
          map("K",  vim.lsp.buf.hover)
          map("<leader>rn", vim.lsp.buf.rename)
          map("<leader>ca", vim.lsp.buf.code_action)
        end,
      })
    end,
  },
})

Dos detalles que parecen menores pero marcan la diferencia: relativenumber permite calcular saltos en cuestión de un parpadeo (10j para bajar diez líneas), y kj como escape suple la falta natural de una tecla Esc cómoda en la mayoría de portátiles. Igual de importante a mi juicio: mapear Caps Lock como Control a nivel de sistema operativo. Sin ese cambio, los atajos de Control, que en Vim son omnipresentes, terminan estirando el meñique.

LazyVim, temas y dotfiles

Aquí conviene aclarar una confusión de nombres: lazy.nvim es el gestor de plugins; LazyVim es otra cosa: una distribución completa de Neovim construida sobre ese gestor, con LSP, Telescope, treesitter y which-key ya configurados. Si no quieres gastar un fin de semana pegando configuraciones, LazyVim es la vía rápida: instalas, abres el editor y ya tienes un entorno serio. Yo mantengo mi configuración propia porque me gusta saber qué hace cada línea, pero le robo ideas a LazyVim cada vez que actualizan algo.

Con los temas alterno entre dos: Catppuccin (en su variante Mocha) y Tokyo Night. Los dos tienen algo que valoro más que la paleta en sí: ecosistema. Hay versiones oficiales para la terminal, tmux, la statusline y prácticamente cualquier plugin, así que todo el entorno queda coherente en lugar de parecer un collage. Cuando pruebo otro tema siempre acabo volviendo a uno de estos dos por esa razón.

Toda esta configuración (Neovim, terminal, tmux, los temas) vive en mi repositorio de dotfiles y se instala con GNU Stow: stow nvim crea los symlinks hacia ~/.config/nvim y listo. Montar una máquina nueva es clonar el repo y correr un par de comandos. De cómo funciona Stow y por qué lo prefiero sobre scripts artesanales escribí aparte en GNU Stow: el secreto detrás de unos dotfiles mantenibles.

La parte ergonómica que Vim solo no resuelve

Aquí viene la honestidad prometida. Tras unas semanas con Vim noté que el dolor de muñeca se mantenía. Reduje el ratón en buena parte, sí, pero el cansancio acumulado por horas de escritura no desapareció. Lo que de verdad cambió la trayectoria fue una combinación más prosaica:

Un teclado partido con inclinación lateral que dejó las muñecas neutras.
Pausas activas cada 25-30 minutos con un temporizador, no negociables.
Un fisioterapeuta que me corrigió la postura de hombro, origen invisible de la queja de muñeca.
Reducir la altura del asiento para que los codos quedaran a 90 grados.

Vim aportó su parte (menos viajes al ratón, menos extensión del meñique para alcanzar flechas), pero presentarlo como solución ergonómica completa sería deshonesto. Es un componente de un cambio más amplio, no la pieza central.

Hallazgos

La curva de aprendizaje es de tres semanas a productividad mínima y de tres meses a productividad superior a la anterior. Antes de eso, hay que tener paciencia o un trabajo que la consienta.
El modo Vim de VS Code es un punto intermedio honesto: permite practicar movimientos sin renunciar a la integración del editor completo.
which-key.nvim acelera el aprendizaje al recordar los atajos disponibles tras pulsar la tecla líder.
Las macros (q para grabar, @ para reproducir) son la herramienta menos enseñada y más poderosa para tareas repetitivas que un script aún no justifica.
No subestimar :help. La documentación de Vim es un libro técnico bien escrito, raro en el software libre.

Closure

Si alguien me pregunta hoy si recomiendo aprender Vim por motivos de salud, respondo con cautela: si el dolor es leve y la curiosidad es genuina, sí. Si el dolor es agudo, conviene resolver primero lo físico y dejar el editor para después. Lo que me llevo, más allá de la productividad, es una manera distinta de entender la herramienta: dejé de pensar en "dónde hago clic" y empecé a pensar en "qué quiero hacerle a este texto". Esa diferencia, pequeña sobre el papel, ha cambiado la forma en que programo, escribo y reviso código todos los días.