El problema de las expresiones regulares

Durante treinta años Vim coloreó código con expresiones regulares, y funcionó lo bastante bien como para que casi nadie preguntase por qué a veces fallaba. La respuesta no es que el motor estuviera mal escrito: es que la tarea que se le pedía era formalmente imposible. Un lenguaje de programación no es un lenguaje regular, y ninguna cantidad de patrones bien afinados convierte un autómata finito en algo que entienda anidamiento. Treesitter no es un resaltador más bonito; es la sustitución de una aproximación por un modelo.

Un lenguaje regular no puede contar

La jerarquía de Chomsky ordena las gramáticas por poder expresivo. En el escalón más bajo están los lenguajes regulares, exactamente los que reconoce un autómata finito: una máquina con un número fijo de estados y ninguna memoria auxiliar. Ese es el poder de una expresión regular clásica. Un escalón por encima están los lenguajes libres de contexto, que necesitan una pila para reconocerse, y ahí es donde vive prácticamente todo lenguaje de programación.

La diferencia se ve en el caso más simple imaginable: emparejar delimitadores anidados. Para decidir si los paréntesis de una expresión están balanceados hay que recordar cuántos llevas abiertos, y ese contador no tiene cota superior. Un autómata finito tiene, por definición, un número finito de estados: no puede almacenar un número arbitrariamente grande. El lema de bombeo formaliza la intuición: todo lenguaje regular admite, a partir de cierta longitud, repetir un fragmento intermedio indefinidamente sin salirse del lenguaje, y el anidamiento balanceado no tolera eso.

El motor de sintaxis de Vim esquiva el límite con regiones, que simulan a mano una pila poco profunda:

syntax region cComment start="/\*" end="\*/" contains=cTodo
syntax region cString  start=+"+ skip=+\\"+ end=+"+ contains=cFormat
syntax match  cNumber  "\<\d\+\>"
highlight link cComment Comment

Los casos que rompen el esquema no son rebuscados; están en cualquier repositorio actual:

// tres niveles de anidamiento con el mismo delimitador
const q = `select ${tabla.map((t) => `"${t.nombre}"`).join(", ")} from x`;

// el numero de almohadillas no tiene cota: hay que contarlas
let s = r##"contiene "comillas" y una almohadilla # suelta"##;

En ambos, decidir dónde acaba la cadena exige recordar con qué se abrió y cuántos niveles llevas. Es contar, otra vez, y contar es justo lo que un autómata finito no hace.

Puedes ver esa maquinaria entera con :syntax list en cualquier buffer: cientos de reglas, regiones y enlaces escritos a mano, lenguaje por lenguaje, por voluntarios distintos a lo largo de treinta años. No hay ninguna gramática detrás; hay un catálogo de patrones que alguien fue ampliando cada vez que aparecía un caso mal coloreado.

Las palabras clave contains, contained y containedin construyen una jerarquía declarada por el autor del archivo de sintaxis. Es una pila enumerada a mano, no derivada de la gramática: funciona para los tres o cuatro niveles que alguien previó, y se rompe en cuanto el código real anida más de lo previsto. Una plantilla de JavaScript con una interpolación que contiene otra plantilla, una cadena literal cruda de Rust con almohadillas, o una macro de C que abre un bloque sin cerrarlo en la misma línea son los casos donde el castillo se cae.

Adivinar el contexto: sincronización y retroceso

Al límite teórico se suman dos problemas prácticos que explican síntomas que ya has visto sin saber nombrarlos.

El primero es la sincronización. Para colorear la línea que tienes en pantalla, el motor necesita saber en qué estado sintáctico está: dentro de un comentario, dentro de una cadena, en código normal. Ese estado solo se conoce con certeza leyendo desde el principio del archivo, lo que sería carísimo en un fichero de cincuenta mil líneas. Vim lo aproxima:

" retroceder 200 lineas y esperar acertar
syntax sync minlines=200 maxlines=500

" correcto pero potencialmente lentisimo
syntax sync fromstart

minlines es literalmente una apuesta: si el comentario de bloque en el que estás empezó 300 líneas más arriba, el motor no lo verá y coloreará mal. Por eso el código cambia de color cuando haces scroll rápido y vuelve a su sitio al redibujar: no estabas viendo un fallo de dibujado, estabas viendo dos apuestas distintas sobre el mismo texto.

Observa la naturaleza del compromiso: minlines demasiado bajo produce colores incorrectos, y demasiado alto produce lentitud. No existe un valor bueno, solo un punto elegido en una curva de intercambio entre exactitud y latencia. Cualquier sistema que te obligue a ajustar a mano ese equilibrio te está diciendo, sin decirlo, que no conoce la respuesta correcta.

Y no hace falta creerlo por fe: el propio Vim trae un perfilador que mide cuánto tarda cada patrón en redibujar la pantalla, y basta con abrir un archivo grande para ver a un puñado de reglas concentrando casi todo el tiempo.

:syntime on
" desplazate por el archivo unos segundos
:syntime report

El segundo es el retroceso. Vim incorpora dos motores de expresiones regulares, seleccionables con :set regexpengine=0, 1 o 2: el clásico con backtracking y el basado en autómata. El primero puede degradar a tiempo exponencial ante ciertos patrones, y es la causa habitual de que un archivo grande de TypeScript o de JSON deje el editor a rastras. La solución tradicional era desactivar el resaltado, es decir, renunciar a la funcionalidad para recuperar la latencia.

Qué aporta un parser de verdad

Un parser generado por tree-sitter no busca patrones: reconoce la gramática. Recorre el texto y construye un árbol sintáctico concreto que representa cada nodo del programa con su posición exacta, desde la raíz hasta el último identificador. Ese cambio de salida —de una secuencia de tramos coloreados a una estructura de datos consultable— es el que arrastra todo lo demás.

Tres propiedades lo hacen viable dentro de un editor. Es incremental: al escribir una tecla reparsea solo la parte afectada, no el archivo entero. Es tolerante a errores: como el código está roto la mayor parte del tiempo mientras lo escribes, la gramática produce nodos ERROR y MISSING localizados en vez de rendirse, y el resto del árbol sigue siendo útil. Y es agnóstico del consumidor: el mismo árbol responde a preguntas distintas mediante consultas declarativas en archivos como highlights.scm, folds.scm, indents.scm y textobjects.scm.

flowchart TD
S[Texto del buffer] --> R[Motor de patrones]
S --> P[Parser de treesitter]
R --> T[Tramos coloreados con estado adivinado]
T --> H1[Resaltado aproximado]
R --> I1[Indentacion con sus propios patrones]
R --> F1[Plegado con otros patrones mas]
P --> A[Arbol sintactico concreto]
A --> Q[Consultas declarativas]
Q --> H2[Resaltado]
Q --> F2[Plegado]
Q --> I2[Indentacion]
Q --> O2[Objetos de texto]
style T fill:#f38ba8,color:#11111b
style A fill:#a6e3a1,color:#11111b
style Q fill:#89b4fa,color:#11111b

La tolerancia a errores merece un párrafo aparte, porque es la propiedad que hace que un parser clásico de compilador no sirviera aquí. Un compilador puede permitirse abortar ante el primer error: su entrada es un archivo terminado. Un editor recibe entradas inválidas en la inmensa mayoría de los instantes, porque cada carácter a medio escribir deja el programa temporalmente roto. Una gramática de tree-sitter está diseñada para que un fragmento irreconocible se encapsule en un nodo ERROR acotado y el resto del árbol siga en pie, de modo que mientras escribes el cuerpo de una función el editor sigue sabiendo dónde está esa función, dónde empieza la siguiente y qué hay que colorear en el resto del archivo.

Y una consecuencia de segundo orden, la más subestimada: al existir una representación común, escribir soporte para un lenguaje nuevo deja de ser reescribir cuatro heurísticas. Con la gramática instalada, el resaltado, el plegado, la indentación y los objetos de texto se obtienen escribiendo consultas cortas contra el mismo árbol. El trabajo por lenguaje pasa de miles de líneas de patrones a unas decenas de patrones declarativos.

Los límites del modelo nuevo

Cambiar de modelo no significa cambiar de bando sin mirar. Conviene delimitar con precisión qué resuelve un parser y qué sigue fuera de su alcance, porque confundirlo genera expectativas que después se leen como fallos.

Un parser sintáctico responde preguntas de forma, no de significado. Sabe que un identificador ocupa la posición de una llamada, pero no sabe a qué función se resuelve, ni de qué tipo es, ni si existe. Todo eso es análisis semántico y vive en el servidor de lenguaje: Treesitter y LSP no compiten, se reparten el trabajo. La regla práctica es simple: si la pregunta se contesta mirando un solo archivo y sin resolver nombres, es del árbol; si exige conocer el proyecto entero, es del servidor.

Hay además costes reales. Cada lenguaje necesita su parser instalado y compilado, con la fricción que eso implica. Una gramática puede ir por detrás de la evolución del lenguaje y producir nodos de error en código perfectamente válido. Y el resaltado por árbol es más literal: donde el motor clásico disimulaba con un patrón amplio, el árbol te muestra la estructura real, que a veces no es la que esperabas.