El buffer de terminal: un emulador dentro del editor

Hasta ahora el proceso hijo era mudo: le dabas argumentos y te devolvía bytes. Pero hay herramientas que no funcionan así. Un git rebase interactivo, un htop, un depurador, un instalador que pregunta: todos esperan una terminal al otro lado, con su cursor, sus colores y su capacidad de responder. Neovim lleva un emulador de terminal completo dentro y lo expone como lo que ya sabes manejar: un buffer.

Qué es realmente

Un buffer de terminal no contiene texto que tú edites: contiene la pantalla de un emulador. Neovim implementa un terminal VT compatible, interpreta las secuencias de escape que emite el programa —mover cursor, borrar línea, cambiar color— y proyecta el resultado sobre las líneas del buffer. Lo que ves es un reflejo, no una fuente.

De ahí se derivan todas sus rarezas. El buffer no es modificable con los comandos de edición normales, porque la única autoridad sobre su contenido es el proceso. Su historial está limitado por la opción scrollback, y lo que se sale por arriba desaparece. Y su nombre tiene la forma term:// seguida del directorio y del comando, lo que permite reconocerlo con un patrón de autocomando.

Abrirla desde Lua

El comando :terminal es la vía rápida, pero para construir algo reutilizable necesitas control sobre la ventana y el buffer. La forma moderna es jobstart con la opción term activada, que sustituye a la antigua función termopen:

local function abrir_terminal(cmd)
  local buf = vim.api.nvim_create_buf(false, true)
  local win = vim.api.nvim_open_win(buf, true, {
    split = 'below',
    height = math.floor(vim.o.lines * 0.35),
  })
  local chan = vim.api.nvim_buf_call(buf, function()
    return vim.fn.jobstart(cmd, {
      term = true,
      cwd = vim.fs.root(0, '.git'),
      on_exit = function(_, code)
        vim.schedule(function()
          vim.notify('terminado con codigo ' .. code)
        end)
      end,
    })
  end)
  vim.cmd.startinsert()
  return buf, win, chan
end

Hay una condición estricta y poco documentada: la terminal solo puede abrirse sobre un buffer vacío y que sea el actual. Por eso el nvim_buf_call, que ejecuta la llamada con ese buffer como contexto. Si intentas abrirla sobre un buffer con contenido, la llamada falla. Si el buffer ya fue terminal una vez, tampoco sirve: necesitas uno nuevo.

El valor devuelto es el identificador de canal, la única manija que tendrás para hablar con el proceso. Guárdalo.

El modo terminal

Cuando el cursor está en un buffer de terminal y entras en modo terminal, cada tecla que pulsas viaja al proceso. Eso incluye combinaciones que en cualquier otro contexto serían de Neovim, y es lo correcto: un Ctrl-C debe interrumpir al programa, no a tu editor.

La secuencia de salida es incómoda a propósito, porque debía ser una combinación que ningún programa reclamara. Casi todo el mundo la reasigna:

vim.keymap.set('t', '<Esc><Esc>', [[<C-\><C-n>]], { desc = 'salir del modo terminal' })
vim.keymap.set('t', '<C-h>', [[<C-\><C-n><C-w>h]], { desc = 'ventana izquierda' })

El doble Esc es un buen compromiso: un Esc simple lo necesitan vim anidado, los depuradores y cualquier programa con modos, mientras que dos seguidos casi nunca significan nada dentro del proceso.

flowchart TB
n[Modo normal en el buffer de terminal] -->|i o a| t[Modo terminal]
t -->|las teclas van al proceso| p[Proceso hijo]
p -->|secuencias de escape| e[Emulador VT de Neovim]
e -->|pantalla proyectada| b[Lineas del buffer]
t -->|Ctrl barra y Ctrl n| n
b -->|TermClose| c[El proceso ha muerto]

Hablar y escuchar

Escribir en la terminal desde Lua se hace con chansend, que envía bytes crudos al canal. No hay envoltorio: si quieres que el programa reciba un retorno, mándalo tú.

local function enviar(chan, texto)
  vim.fn.chansend(chan, texto .. '\r')
end

Con eso ya puedes construir integraciones reales: enviar la línea bajo el cursor a un intérprete, reejecutar el último comando, alimentar un REPL con la selección visual. Es el mismo mecanismo que usan los plugins de send to terminal, y no tiene más misterio que decidir qué texto mandas.

Del lado de la escucha, dos autocomandos cubren el ciclo de vida completo. TermOpen dispara justo al crearse y es donde configuras el buffer. TermClose dispara cuando el proceso muere, y es donde decides qué pasa después:

vim.api.nvim_create_autocmd('TermClose', {
  callback = function(ev)
    if vim.v.event.status == 0 then
      vim.api.nvim_buf_delete(ev.buf, { force = true })   -- exito: fuera
    end                                                    -- fallo: se queda para leerlo
  end,
})

Ese condicional es la ergonomía que separa una integración usable de una molesta. Si el comando funcionó no quieres ver una ventana con un cadáver; si falló, quieres el error en pantalla hasta que lo cierres tú.

Un último patrón cierra el círculo: la terminal persistente. En vez de crear una nueva cada vez, guardas el buffer y el canal, y el atajo alterna la ventana sin matar el proceso.

local estado = { buf = nil, win = nil, chan = nil }

local function alternar()
  if estado.win and vim.api.nvim_win_is_valid(estado.win) then
    return vim.api.nvim_win_hide(estado.win)      -- oculta, no destruye
  end
  if estado.buf and vim.api.nvim_buf_is_valid(estado.buf) then
    estado.win = vim.api.nvim_open_win(estado.buf, true, { split = 'below' })
    return vim.cmd.startinsert()
  end
  estado.buf, estado.win, estado.chan = abrir_terminal(vim.o.shell)
end

nvim_win_hide es la pieza clave: cierra la ventana dejando el buffer y su proceso intactos, así que tu shell conserva el historial, el directorio y cualquier programa que tuvieras corriendo. Destruir el buffer al ocultar es el error que convierte una terminal integrada en algo peor que cambiar de aplicación.