Construir tu propio editor de texto: lecciones reales

Por qué un programador decidió construir su propio editor de texto desde cero

Hay una pregunta que muchos developers evitan hacerse porque saben que la respuesta puede costarles meses de trabajo: ¿y si mi editor de texto actual simplemente no es suficiente? Joshua Barretto, ingeniero de software y contribuidor open source, se la hizo hace dos años, y decidió actuar. El resultado es ZTE, un editor de texto TUI (Text User Interface) escrito en Rust, que hoy usa como su herramienta principal de trabajo todos los días.

Su historia no es solo la de alguien que quería un proyecto de fin de semana. Es la de un profesional que identificó fricciones reales en su flujo de trabajo y tomó la decisión de eliminarlas con código propio. Para cualquier founder o desarrollador en el ecosistema tech, hay lecciones directamente aplicables aquí.

El problema con los editores existentes

Barretto venía usando Howl durante casi una década. Funcional, liviano, pero con limitaciones críticas que se acumularon con el tiempo:

• Desarrollo abandonado: Howl lleva varios años sin mantenimiento activo, lo que obligaba a Barretto a mantener su propio fork de un lenguaje (MoonScript) que no le interesaba dominar profundamente.
• Búsqueda en proyectos demasiado lenta: Para alguien que navega grandes codebases sin depender de un LSP, la búsqueda de texto a nivel de proyecto es crítica. Howl lo sacaba del estado de flujo.
• Imposible de usar por SSH: Con cada vez más trabajo en máquinas remotas, un editor GUI resulta inútil sin acceso a pantalla.
• Sin terminal integrada: La falta de soporte real para escape codes ANSI y la ausencia de interacción en vivo lo limitaban severamente.

Probó alternativas: Helix, VS Code, Vim, Neovim, Zed, Emacs, Sublime Text y varios más. Ninguno le daba lo que buscaba. Lo que él llama fingerspitzengefühl —ese tacto intuitivo, esa sensación de que la herramienta es una extensión natural de uno mismo— simplemente no estaba.

La estrategia del dogfooding: cómo no dejar morir el proyecto

Uno de los puntos más valiosos de su experiencia es metodológico. Muchos side projects de developers mueren porque nunca se convierten en herramientas reales. Barretto implementó tres prácticas que transformaron su editor de experimento a herramienta diaria:

1. Reemplazó nano con su propio editor, sin importar cuánto doliera. Cualquier edición rápida de un archivo del sistema, cualquier nota, tenía que pasar por ZTE.
2. Documentó cada bug, limitación o comportamiento extraño en el README del proyecto, por pequeño que fuera. Esto le daba siempre una lista clara de qué atacar a continuación.
3. Si algo lo molestaba lo suficiente, lo arreglaba en el momento, sin posponer. El umbral de tolerancia cero para las fricciones fue clave.

El efecto fue notable: pasó de trabajar en el proyecto una hora al mes a varias horas por semana. Aproximadamente 10.000 líneas de código aparecieron en los últimos 6 meses de desarrollo, casi nada antes de eso.

Decisiones técnicas que todo developer debería conocer

Manipulación de cursores: más complejo de lo que parece

La lógica detrás de combinaciones como ctrl + shift + izquierda es deceptivamente compleja. El consejo de Barretto: implementar operaciones de alto nivel en términos de primitivas más simples. El backspace por palabra, por ejemplo, se puede descomponer en movimiento de cursor, selección del rango y borrado. Esto también simplifica el sistema de undo/redo.

El buscador de archivos: un problema mal resuelto en casi todos los editores

Barretto invirtió tiempo en replicar lo que más extrañaba de Howl: su buscador de archivos. Su conclusión, después de considerar algoritmos complejos como la distancia de Levenshtein, fue que la búsqueda predictiva excelente solo necesita tres criterios simples:

1. Si la entrada comienza con el término buscado.
2. Si la entrada contiene el término buscado.
3. La fecha de modificación o acceso más reciente del archivo.

Con estos tres criterios bien ordenados, el archivo correcto aparece en los primeros dos resultados después de dos teclas en el 95% de los casos, incluso en proyectos con decenas de miles de archivos.

Motor de regex construido desde cero

Para la búsqueda a nivel de proyecto, el resaltado de sintaxis y la búsqueda en buffer, Barretto construyó su propio motor de regex. Las optimizaciones incluyen:

• Un optimizador de un solo paso que simplifica patrones recurrentes.
• Detección de prefijos comunes para acelerar búsquedas (por ejemplo, hel[(lo)p] siempre empieza con hel).
• Implementación de las instrucciones del VM en términos de bytes, aprovechando el diseño de UTF-8 que mantiene muchas optimizaciones de ASCII.
• Un enfoque en Continuation-Passing Style (CPS) que permite al compilador optimizar tail calls.

El resultado: resaltar sintácticamente un archivo Rust de 50.000 líneas desde cero tarda menos de 10 milisegundos. Más rápido que el refresco de pantalla.

Resaltado de sintaxis por demanda

En lugar de re-resaltar el archivo entero en cada cambio, Barretto implementó un caché por chunks que solo invalida las secciones afectadas por el cambio. Al ser demand-driven, nunca procesa lo que no es visible en pantalla, lo que lo hace extremadamente eficiente incluso con múltiples paneles abiertos en el mismo buffer.

Búsqueda de proyecto multi-thread

La búsqueda en proyectos es multi-hilo con un sistema de work-stealing entre threads. Un detalle interesante: determinar cuándo todos los hilos terminaron requirió resolver un problema poco común —cada hilo es simultáneamente consumidor y productor de trabajo— que Barretto resolvió con un contador atómico y una sección crítica compartida.

Emulador de terminal integrado

En lugar de reinventar la rueda para el parsing de secuencias ANSI, Barretto optó por construir sobre alacritty_terminal, la librería central del emulador Alacritty. Esto le permitió implementar soporte completo de terminal —incluyendo Kitty keyboard extensions y OSC52— con un esfuerzo relativamente bajo. ZTE ahora puede reemplazar a tmux o screen en sus casos de uso principales.

Renderizado eficiente sobre SSH

El editor mantiene un doble buffer interno del estado del terminal. En cada redraw, solo emite secuencias ANSI para las celdas que cambiaron, minimizando el ancho de banda. Esto lo hace más eficiente que hacer cat de un archivo grande directamente en la terminal host.

Qué aprendió Barretto (y qué pueden aprender los founders)

La conclusión de Barretto desafía la sabiduría convencional que dice que construir tus propias herramientas es un ejercicio en dolor innecesario. Sus argumentos a favor:

• Ajusta perfectamente: El editor hace exactamente lo que él necesita, ni más ni menos.
• Aprendizaje profundo: Construirlo requirió dominar regex, ANSI, pseudoterminales, diseño TUI y el comportamiento interno de UTF-8.
• Mayor productividad a largo plazo: Conocer tu herramienta de adentro hacia afuera y construir flujos de trabajo personalizados desplaza el tiempo de trabajo intelectual de tareas burocráticas a pensamiento creativo.
• Simplemente es divertido: Barretto describe haberse encontrado sonriendo y riendo solo mientras programaba, algo que no experimentaba hace años.

Para un founder tech, la moraleja va más allá del editor de texto: las herramientas que construyes para ti mismo son las que mejor entienden tu problema real. No porque sean perfectas desde el inicio, sino porque el proceso de construirlas, usarlas y mejorarlas te convierte en un experto en tu propio flujo de trabajo.

¿Vale la pena construir tus propias herramientas?

La respuesta honesta es: depende. Según datos del ecosistema dev, solo alrededor del 12% de los desarrolladores elige editores o herramientas completamente personalizadas para necesidades específicas. El resto prioriza velocidad de adopción y estándares de equipo, lo cual también tiene sentido.

Pero para founders y developers que sienten que sus herramientas actuales generan fricciones concretas —especialmente aquellas que los sacan del estado de flujo repetidamente— la historia de ZTE es un argumento poderoso a favor de invertir tiempo en construir algo propio.

La clave no está en construir algo perfecto desde el día uno. Está en el dogfooding riguroso: usar lo que construyes, documentar lo que falta, y arreglar lo que duele. Esa disciplina es lo que convierte un proyecto de hobby en una herramienta que cambia tu manera de trabajar.

Conclusión

La experiencia de Joshua Barretto con ZTE ilustra algo que los mejores founders tech ya saben: las restricciones que aceptas como inevitables en tus herramientas diarias son casi siempre opcionales. Construir tu propia solución —aunque sea parcialmente— te da un control y una comprensión que ningún producto comercial puede darte.

No tienes que construir un editor de texto. Puede ser una pipeline de automatización, un dashboard interno, un script que elimina una tarea repetitiva. El principio es el mismo: identifica la fricción, elimínala con código, y úsala todos los días. El retorno compuesto de esa inversión, en productividad y en aprendizaje, es difícil de sobreestimar.

Fuentes

1. https://blog.jsbarretto.com/post/text-editor (fuente original)
2. https://flexum.io/post/how-advanced-text-editors-are-shaping-modern-software-usability (fuente adicional)
3. https://techblog.bozho.net/developers-are-obsessed-with-their-text-editors (fuente adicional)
4. https://www.tiny.cloud/blog/rte-motivation-expectations (fuente adicional)

Artículos relacionados:

De VS Code a Helix: Guía para Fundadores Tech en la Adaptación Ferrite: editor Markdown en Rust con diagramas Mermaid nativos Photopea: Editor de Fotos Online Gratis para Startups 2026 Google Photos: edición con IA basada en texto llega a nuevos mercados LibreSprite: editor de pixel art open source y gratis