Ratatui, librería TUI en Rust, propone bordes sin celdas

Qué propone Ratatui: bordes que no ocupan una celda

El mantenedor de Ratatui, la librería de interfaces de terminal en Rust, publicó un protocolo que dibuja líneas finas en los bordes de las celdas en lugar de usar un carácter por línea. El resultado: los paneles de una TUI dejan de gastar una fila y una columna por cada lado.

El número que dimensiona el problema lo da el propio autor: en su laptop de 16 pulgadas, con una fuente que puede leer, la terminal es de unas 200×50 celdas. Las columnas suelen alcanzar. Las filas no. Un layout con dos niveles de paneles anidados puede gastar 6 u 8 de esas 50 filas solo en líneas decorativas.

La implementación existe como parche a Ghostty y tuvo una versión anterior en Rio. El autor construyó demos con Ratatui y pide feedback explícito a autores de terminales y de librerías TUI.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Por qué los bordes de caja son un problema de diseño

El bloque Unicode de dibujo de cajas tiene 128 caracteres para líneas, esquinas y uniones. Aun así no alcanza, y la raíz es que cada línea es texto: un glifo que ocupa una celda completa. Casi todo lo molesto se desprende de ahí.

No puedes poner una línea entre dos celdas que ya tienen contenido. Por eso no hay forma de subrayar un campo de texto justo debajo del texto, ni de delinear un botón, sin agregar padding alrededor.
Las esquinas redondeadas traen un defecto de color. El glifo de esquina tiene un solo color de fondo, así que cuando el fondo del panel difiere del que está detrás aparece un cuadradito del color equivocado en cada esquina.
El grosor y la posición de la línea los decide la fuente, no tu diseño.
Al copiar y pegar, el borde viaja con el texto. Cualquiera que haya pegado desde una TUI en Slack conoce la danza de limpiar los │ a mano.

El propio autor lo resume sin vueltas: muchas TUIs terminan viéndose bastante parecidas entre sí, cajas planas sobre un fondo aburrido, y los bordes son parte del problema.

Cómo funciona el protocolo de cell borders

Un cell border es un atributo de celda, igual que un color de fondo. Cada celda puede llevar hasta doce segmentos de línea: las dos mitades de cada uno de sus cuatro bordes, más cuatro brazos desde su centro. Cada segmento tiene su propio color, grosor, posición y estilo, y la terminal los dibuja por encima de la grilla.

Como el borde vive dentro de la celda, se desplaza, se borra, se inserta y hace reflow junto con el texto. Lo que ocurre al borrar o al hacer scroll ya tiene respuesta: la misma que para los colores.

Los detalles que importan si piensas implementarlo:

Los bordes se dividen en mitades para alinearse con los caracteres de bloque de cuadrante (▖▗▘▝), lo que permite dibujar una forma a media celda de la grilla y aun así rodearla con un borde prolijo.
Los estilos pueden ser sólidos, dobles, discontinuos o punteados. Cada esquina y cada centro puede ser cuadrado o redondeado, con radio configurable y arcos con anti-aliasing.
Cuando dos celdas vecinas ponen línea en su borde compartido, se fusionan en una sola. Gana el trazo de mayor prioridad, después el más ancho, después el de la derecha o el de abajo. Así un panel enfocado puede subir su prioridad y conservar todo su contorno, sin importar en qué orden se dibujaron sus vecinos.
El formato de transmisión es un string DCS con namespace. El camino común es un pen que se sostiene en el cursor como el color de fondo actual: se configura, se imprime texto, y las celdas impresas reciben los bordes.
Hay comandos de rectángulo que ponen o quitan bordes sobre celdas existentes sin tocar el pen, más una consulta de capacidades. La app manda la consulta seguida de DA1; si la respuesta de DA1 llega sin una respuesta de cell-border antes, la terminal no lo soporta y la app cae a caracteres de caja.
El mínimo que una terminal necesita implementar es el pen, los comandos de rectángulo y los trazos sólidos.

El autor llama a esto versión 1, pero aclara que lo dice en el sentido viejo, antes de que todos quedáramos atrapados en semver: no significa terminado ni estable, significa que es la primera versión que estuvo dispuesto a escribir. Hay que leerlo como un borrador.

Qué terminales y librerías ya lo están probando

El parche a Ghostty implementa toda la versión 1 del protocolo, aunque el autor solo lo compiló y corrió en macOS: las builds de GTK y OpenGL están sin probar.

El ecosistema alrededor de Ghostty se mueve. Según XDA Developers, el desarrollador de KDE Eike Hein trabaja en Kwi, una terminal experimental para KDE construida sobre libghostty-vt, la librería del proyecto Ghostty. El medio reporta que Hein afirma un rendimiento de renderizado entre 3 y 35 veces más rápido que Konsole, la terminal de KDE que ya tiene casi 30 años, y que libghostty-vt ya se usa en Neovim y Ghostel. Kwi sigue siendo un experimento sin versión etiquetada.

Antecedentes: no es la primera vez que alguien lo intenta

El autor documenta la prior art con bastante honestidad, y el recorrido sirve para entender por qué el problema seguía abierto:

Las líneas regladas de DEC en DECterm (extensión 43 en la respuesta DA1) dibujan líneas alrededor de rectángulos. Hacen scroll con el texto, pero son una capa aparte: limpiar la pantalla las deja atrás y siempre miden un píxel en el color de texto normal.
SGR 51 a 65 (framed, encircled, overline y las líneas laterales de ideogramas). Algunas terminales dibujan bordes con ellos, pero son atributos de encendido/apagado sin color, grosor ni uniones, y no existe un atributo para el borde inferior.
La consola de Win32 tiene flags de grilla por celda para los bordes superior, izquierdo y derecho. PDCurses y X/Open curses (WATOP, WALEFT y compañía) tienen atributos similares. Son lo más cercano al protocolo, pero no tienen borde inferior, color, grosor ni mitades.
Las terminales IBM 3270 pueden delinear campos de entrada completos.

Ninguno de estos da una línea con color y grosor propios en cada borde. El primer prototipo del autor estuvo en Rio, con una versión anterior del spec que usaba APC en lugar de DCS. El feedback señaló que APC no es seguro de reutilizar: Kermit 95 ejecuta payloads APC como comandos Kermit desde los 90. DCS es donde ya viven los comandos estructurados de terminal, y las terminales ignoran los DCS que no reconocen.

Cuánto cuesta implementarlo

El cambio en Ghostty son unas 1.650 líneas, y buena parte son tests. Cada celda recibe un ID de borde de 16 bits que entra en padding que ya existía, así que las celdas no crecen y una pantalla sin bordes no cuesta nada extra. Los IDs apuntan a una tabla de conjuntos de bordes distintos, de unos 100 bytes cada uno, compartida por toda la terminal. Una TUI típica usa un puñado de conjuntos, pero la tabla nunca se libera: en el peor caso, con los 65.535 IDs en uso, son unos 10-15 MB.

El renderizado solo hace trabajo extra en las celdas que tienen bordes. Cada una mira a sus cuatro vecinas para resolver los bordes compartidos, así que cambiar una fila también reconstruye las filas de al lado. Las líneas rectas son unos pocos quads por celda; las esquinas redondeadas cuestan más. El autor aclara que no hizo benchmarks formales y que es justamente la parte donde más quiere otra mirada.

Los casos difíciles

Los multiplexores fueron la primera pregunta que le hicieron. tmux y compañía redibujan los paneles desde su propia idea de la grilla, así que pasar estas secuencias tal cual dejaría los bordes en el lugar equivocado. Un multiplexor que no conoce el protocolo debería descartarlas y responder DA1 él mismo, y entonces las apps que corren adentro caen a caracteres de caja como en cualquier otra terminal. Uno que sí lo conoce puede guardar los bordes como cualquier otro atributo.

Borrar, insertar y eliminar funcionan igual que con los colores de fondo. El scrollback, la pantalla alternativa y el reflow salen casi gratis, porque el borde vive en la celda.

Qué significa esto para tu startup

Si construyes herramientas para desarrolladores —CLIs, dashboards de observabilidad, paneles de administración, cualquier cosa que corra en una terminal— esto toca directo tu producto. Y si tu equipo usa TUIs internas para operar infraestructura, también.

Prueba el gallery script antes de rediseñar nada. El autor incluye un script que detecta soporte primero, así que sirve como chequeo rápido de cualquier terminal. Si tu equipo corre el fork de Ghostty con la rama joshka/cell-borders, puedes ver tu UI con bordes de celda y compararla contra el fallback en la misma sesión. Es la forma más barata de saber si el problema que resuelve te afecta.
Diseña pensando en el fallback desde el día uno. El protocolo está pensado para degradar: la app consulta capacidades y, si no hay respuesta, reserva el espacio que necesitan los caracteres de caja. Eso significa mantener dos versiones del layout. La de fallback es la que va a ver la enorme mayoría de tus usuarios por un buen tiempo, así que no la trates como un detalle.
Si tu producto es una TUI, la estética es diferenciación real. El diagnóstico del autor es que las TUIs se ven todas parecidas. En un mercado donde las herramientas de desarrollo compiten por atención de equipos técnicos, dejar de perder 6 u 8 filas en decoración es una mejora de densidad de información, no un capricho visual.
Hay una ventana para contribuir. El autor pide feedback concreto: si trabajas en una terminal, qué partes parecen caras de implementar; si trabajas en una librería o app TUI, qué widgets usarían el protocolo y qué les falta. Un equipo chico que aporte ahí gana visibilidad en un proyecto con tracción dentro del ecosistema de terminales.

Vale una nota sobre cómo se hizo: el autor aclara desde el arranque que la nota y el código detrás se escribieron con mucha ayuda de IA. Para un founder, es un dato relevante sobre el estado actual del desarrollo asistido: un protocolo de terminal completo, con spec, rationale, parche a Ghostty y tres demos en Ratatui, salió de ese flujo de trabajo.

Conclusión

El protocolo de cell borders ataca un problema que la mayoría de los desarrolladores de TUIs aceptó como costo fijo: que cada línea cueste una celda. La propuesta es técnicamente conservadora —el borde es un atributo de celda, como el color de fondo— y por eso mismo es plausible que se adopte: no exige repensar el modelo de la terminal, solo agregarle una capa.

El autor lo dice sin ambición de dueño único: no está casado con que esta sea la solución exacta, pero cree que el problema vale la pena resolverse y que debería ser más que la función de una sola terminal. Para quien construye herramientas de desarrollo, la jugada razonable no es esperar a que sea estándar, sino entender ahora cómo se degrada su interfaz cuando no está disponible. Ese es el trabajo que no se puede posponer.