Robustez: errores, cancelación y procesos que no mueren

Todo lo anterior funciona el día que la herramienta existe, responde rápido y termina bien. El código que separa un experimento de un plugin es el que se escribe para los otros días: el binario que no está instalado, el comando que se cuelga esperando una entrada que nunca llega, el proceso que sigue vivo diez minutos después de que cerraras su ventana. Esta lección va de esos días.

Los tres finales

Un proceso hijo no falla de una sola manera. Falla de tres, y confundirlas produce mensajes de error inútiles.

El primer caso es el único que no llega a tu callback, y por eso es el que más se olvida. Una comprobación de existencia por adelantado convierte un error críptico en un mensaje accionable:

local function ejecutar(cmd, opts, cb)
  if vim.fn.executable(cmd[1]) ~= 1 then
    return vim.notify(('no encuentro %s en el PATH'):format(cmd[1]), vim.log.levels.WARN)
  end
  local ok, obj = pcall(vim.system, cmd, opts, cb)
  if not ok then vim.notify(tostring(obj), vim.log.levels.ERROR) end
  return ok and obj or nil
end

Los otros dos casos se distinguen en el callback y merecen ramas distintas. Un code de 124 con signal igual a 15 es tu propio timeout disparándose, y decirle al usuario que la herramienta falló sería mentira: lo que pasó es que tardó demasiado.

Cancelar lo que está en vuelo

En cuanto enganchas un proceso a un evento frecuente —guardar, teclear, mover el cursor— dejas de tener una ejecución y pasas a tener una cola de ejecuciones solapadas. Si no haces nada, todas terminarán y todas publicarán, y el resultado visible será el de la última en acabar, que no tiene por qué ser la más reciente.

El patrón es un solo hueco por buffer, y quien llega mata a quien estaba:

local en_curso = {}

local function relanzar(bufnr, cmd, cb)
  local previo = en_curso[bufnr]
  if previo and not previo:is_closing() then
    previo:kill(15)                    -- SIGTERM al anterior
  end
  en_curso[bufnr] = vim.system(cmd, { text = true, timeout = 10000 }, function(obj)
    en_curso[bufnr] = nil
    if obj.signal ~= 0 then return end -- lo matamos nosotros: no publiques
    cb(obj)
  end)
end

El descarte por signal es la mitad de la lógica. Un proceso que matamos deliberadamente también invoca su callback, con salida parcial y un código sin sentido. Publicar eso produce diagnósticos que parpadean o listas quickfix a medias. La regla es: si yo lo maté, su resultado no me interesa.

Falta el debounce, porque cancelar es caro y arrancar procesos por cada pulsación es caro aunque los mates. Un temporizador de vim.uv que se reinicia con cada evento y solo dispara al cesar la actividad reduce cien ejecuciones a una.

flowchart TB
ev[Evento del editor] --> deb[Temporizador de debounce]
deb --> chk[Hay un proceso en curso para este buffer]
chk --> k[kill con SIGTERM al anterior]
k --> new[Lanzar el nuevo y guardar la manija]
new --> cbk[Callback]
cbk --> sig[Murio por senal nuestra]
sig --> desc[Descartar el resultado]
cbk --> okk[Termino solo]
okk --> pub[Publicar]

Atarlo al ciclo de vida

Un proceso lanzado desde un buffer no tiene ninguna relación con ese buffer. Si el usuario lo cierra, el proceso sigue. Si abandona el archivo, el proceso sigue. Establecer esa relación es trabajo tuyo, y se hace con autocomandos que limpien en cada punto de salida.

vim.api.nvim_create_autocmd({ 'BufWipeout', 'BufDelete' }, {
  callback = function(ev)
    local h = en_curso[ev.buf]
    if h and not h:is_closing() then h:kill(15) end
    en_curso[ev.buf] = nil
  end,
})

vim.api.nvim_create_autocmd('VimLeavePre', {
  callback = function()
    for _, h in pairs(en_curso) do
      if not h:is_closing() then h:kill(15) end
    end
  end,
})

Los dos eventos de buffer cubren el cierre normal; VimLeavePre cubre la salida del editor. Neovim mata por su cuenta los trabajos no desligados al terminar, pero hacerlo tú antes tiene dos ventajas: eliges la señal, y les das la oportunidad de limpiar sus propios archivos temporales en vez de morir de golpe.

Huérfanos, zombis y grupos

Aquí es donde la intuición falla, porque hay dos patologías distintas que la gente llama con el mismo nombre.

Un zombi es un proceso que ya murió pero cuya entrada en la tabla del kernel sigue ahí porque su padre no ha recogido su código de salida. En Neovim esto prácticamente no te va a ocurrir: la biblioteca de eventos que hay debajo recoge a sus hijos automáticamente. Los zombis aparecen cuando el hijo muere y tú cierras su manija sin dejar que el ciclo termine, y por eso la regla es no fabricar manijas que no vayas a cerrar.

Un huérfano es el problema real, y es exactamente el inverso: un proceso que sigue vivo después de que su padre muriera. Ocurre casi siempre por una razón que se ve venir en cuanto se nombra. Cuando lanzas un comando que a su vez lanza otros —un script que invoca al compilador, una tarea que abre un servidor— matar al primero no toca a sus hijos. El proceso al que mataste era el padre; los nietos quedan sueltos, adoptados por el proceso raíz del sistema, consumiendo CPU sin que nada los reclame.

La defensa práctica tiene tres capas y ninguna es opcional. Primero, evita el shell: pasar una lista de argumentos en vez de una cadena elimina un proceso intermedio de la cadena, y con él la mayor fuente de nietos huérfanos. Segundo, pon un timeout a todo, incluso a lo que crees instantáneo, porque el caso que te cuelga es siempre el que no previste. Tercero, cierra stdin con stdin = false salvo que vayas a escribir: un proceso esperando una entrada que nunca llegará es indistinguible de uno colgado, y es la causa número uno de un Neovim que se niega a cerrarse.