Paneflow 0.8.0: libghostty-vt sustituye a Alacritty en Linux

Paneflow 0.8.0 ahora usa libghostty-vt para cada nueva sesión de terminal en las builds estándar de Linux. Con terminal.backend en auto, las builds Linux para x86_64 y ARM64 seleccionan Ghostty por defecto.

La migración cambia el motor que interpreta los datos VT y mantiene el estado del terminal, no el workspace que lo rodea. Paneflow sigue controlando el PTY, el ciclo de vida de los procesos, el motor de renderizado GPUI, los paneles, las sesiones, el estado de los agentes, los diffs y la persistencia. macOS y Windows continúan usando Alacritty.

Ghostty se incorpora a Paneflow en la capa del motor VT

Hasta Paneflow 0.7.x, las sesiones de terminal se apoyaban en el crate de Rust alacritty_terminal 0.26. Ese motor gestionaba las secuencias de escape, la cuadrícula, el scrollback, los modos de entrada, la búsqueda y parte del modelo de renderizado.

La nueva ruta de Linux usa libghostty-vt, el motor de terminal integrable de Ghostty. Analiza secuencias VT, mantiene el estado del cursor y la pantalla, gestiona grafemas, ajuste de línea y reflow, codifica entradas de teclado y ratón y expone un estado de renderizado incremental a la aplicación anfitriona.

Paneflow no integra la aplicación Ghostty, su interfaz GTK ni su motor de renderizado. Ghostty proporciona el núcleo del terminal. Paneflow convierte ese estado en snapshots propios de Rust y los dibuja con su motor de renderizado GPUI existente. La interfaz del producto y el flujo multiagente siguen bajo el control de Paneflow.

Una frontera de Paneflow separa ahora el motor del producto

Sustituir el parser era solo una parte del trabajo. Los tipos de Alacritty llegaban al bucle PTY, el renderizado, la búsqueda, la selección, los enlaces, la restauración del scrollback y el ciclo de vida de las sesiones. Cambiar una dependencia sin retirar antes ese acoplamiento habría trasladado el mismo problema a otro motor.

Paneflow expone ahora su propia frontera de sesión de terminal. Alacritty y Ghostty producen los mismos comandos, eventos, modos, resultados de búsqueda y snapshots de renderizado de Paneflow. El motor de renderizado ya no necesita saber qué motor de terminal creó una celda.

Esa frontera es la parte duradera de la migración. Linux puede avanzar primero sin modificar macOS ni Windows, y una futura actualización del motor ya no obliga al resto de la aplicación a adoptar sus tipos internos.

La API C inestable queda confinada en un pequeño wrapper de Rust

Ghostty describe libghostty-vt como funcionalmente maduro, aunque las firmas de su API todavía cambian. Por eso Paneflow fija el commit exacto de Ghostty ae52f97d, su header C, los bindings generados, la versión de Zig, la configuración de build y el checksum del archivo.

La ABI C sin procesar queda aislada en un crate -sys. Un segundo wrapper seguro posee cada handle nativo, valida la versión de la API y los layouts C antes de crear un terminal, contiene los panics de los callbacks y libera las asignaciones de Ghostty con el allocator correspondiente.

La regla de ownership importa especialmente durante el renderizado. libghostty-vt expone filas y celdas prestadas que una mutación posterior del terminal puede invalidar. Paneflow copia los datos necesarios mientras el terminal está bloqueado y después entrega a GPUI un snapshot propio de Rust. Ningún puntero C ni slice prestado sobrevive al bloqueo o al límite de un frame.

Esta estrategia exige más mantenimiento que seguir una dependencia sin fijar. Cada actualización de Ghostty requiere regenerar y revisar el header, los bindings, los archivos estáticos, checksums, símbolos y licencias para ambas arquitecturas Linux. El coste es explícito y está contenido, en lugar de convertirse en incertidumbre en runtime.

Alacritty sigue siendo la referencia diferencial y el rollback

El resultado visible buscado es la continuidad. Shells, agentes de código, TUI a pantalla completa, búsquedas, selecciones, operaciones del portapapeles, scrollback, eventos OSC, cambios de tamaño, reflow y cierre de procesos deben seguir comportándose como antes del cambio de motor.

Paneflow envía los mismos flujos VT deterministas a Alacritty y Ghostty con varios tamaños de fragmento, y después compara sus snapshots normalizados y eventos ordenados. Objetivos de fuzzing separados cubren secuencias malformadas o truncadas, codificación de entrada, cambio de tamaño, reflow y límites donde una secuencia llega en varias lecturas del PTY. Las comprobaciones de paquetes también rechazan un artefacto Linux si depende de libghostty.so en runtime, contiene una identidad de build incorrecta u omite los avisos nativos revisados.

Alacritty no se ha eliminado. Para usarlo en las nuevas sesiones de Linux, configura el backend en paneflow.json:

{
  "terminal": {
    "backend": "alacritty"
  }
}

Una sesión activa nunca cambia de motor en memoria. Ciérrala y abre un panel nuevo después de modificar el ajuste. auto selecciona Ghostty en las builds estándar de Linux y Alacritty en macOS, Windows o builds Linux compiladas con --no-default-features.

Enlace estático sin instalar Ghostty

Los paquetes oficiales para Linux contienen un archivo estático libghostty-vt fijado para x86_64 o ARM64. No necesitas instalar Ghostty, Zig ni una biblioteca compartida en tu máquina. Un cargo build normal desde un checkout limpio de Paneflow también usa el archivo verificado incluido en el repositorio y nunca descarga código fuente nativo durante build.rs.

Linux es la primera plataforma que recibe este backend. Extenderlo a Windows o macOS y retirar Alacritty en el futuro son decisiones separadas. Paneflow 0.8.0 limita el radio de impacto: un nuevo valor por defecto, dos motores compatibles y un rollback inmediato para las sesiones nuevas.

Actualiza a Paneflow 0.8.0, abre un panel nuevo y ejecuta el shell, la TUI o el agente de código que usas habitualmente. Si aparece una regresión del terminal, devuelve las sesiones nuevas a Alacritty e indica el comando, tu distribución Linux y si la sesión se ejecutaba bajo Wayland o X11.