Cómo uso Windows Terminal: automatización extrema del terminal con tmux y un flujo de trabajo personalizado

 (jyn.dev)
23 puntos por GN⁺ 2025-06-24 | 1 comentarios | Compartir por WhatsApp
  • Combina tmux, SSH, nvim y potentes scripts de búsqueda y automatización para implementar un flujo de trabajo único con el que explora, modifica y busca archivos en servidores remotos al instante, sin GUI
  • Con una sola combinación de teclas, busca automáticamente nombres de archivo en múltiples ventanas de tmux y los abre al instante; incluso el cambio de archivos y la gestión de buffers se resuelven solo con atajos
  • Insatisfecho con la lentitud de VSCode y los conflictos de keybindings, integró personalmente todas las operaciones mediante scripts
  • Combinando herramientas Unix como regex, perl, tmux y nvim, logró el reconocimiento automático de rutas de archivo e información de línea, además de su apertura
  • Aunque el proceso de implementación propia es muy complejo, demuestra que es posible maximizar al extremo la potencia y extensibilidad del terminal

Mi propia forma de usar el terminal

  • Este artículo comparte la experiencia de construir un entorno de desarrollo eficiente combinando el terminal con distintas herramientas
  • Como se trata de un proceso complejo que normalmente requeriría video, acompaña el texto con video real de funcionamiento (ver el video es esencial)
  • Algunas etapas del video (0:11, 0:21, 0:41) son puntos en los que mucha gente se sorprende y piensa: "¿de verdad se puede hacer eso?"

Resumen paso a paso del flujo de trabajo del terminal en el video

  • 0:00 : Ejecuta Windows Terminal en una laptop
  • 0:02 : Con el atajo ctrl + shift + 5 abre una nueva pestaña del terminal, se conecta por ssh a su desktop en casa y ejecuta tmux de inmediato
  • 0:03 : Ejecuta el shell predeterminado zsh dentro de tmux, muestra el prompt y carga toda la configuración de forma asíncrona
  • 0:08 : Usa zoxide para hacer una búsqueda difusa de directorios recientes y moverse a uno de ellos
  • 0:09 : Empieza a escribir un comando de ripgrep; zsh autocompleta según el historial previo y lo acepta con ctrl + f
  • 0:11 : Con el atajo ctrl + kf busca nombres de archivo en todo el scrollback de tmux y los nombres aparecen resaltados en azul
  • 0:12 : Presiona repetidamente la tecla n para recorrer la lista de archivos encontrados hasta el que quiere
  • 0:21 : Con la tecla o abre el archivo seleccionado en la app predeterminada (nvim), y tmux lo ejecuta en una nueva ventana (siguiendo en el servidor remoto)
  • 0:26 : Intenta moverse entre varias referencias del código con rust-analyzer; algunos macros no se reconocen, pero en 0:32 el salto funciona correctamente
  • 0:38 : Con ctrl + kh cambia el foco de tmux a la ventana izquierda
  • 0:39 : Vuelve a presionar la tecla n para seguir recorriendo resultados previos de búsqueda de archivos en estado de "copy-mode"
  • 0:41 : Con la tecla o, esta vez abre otro archivo en la instancia de nvim ya existente
  • 0:43 : Con la tecla b revisa la lista de buffers de archivos abiertos y termina alternando entre los dos archivos

¿Por qué terminó usando este flujo de trabajo en el terminal?

  • VSCode es lento y, sobre todo, con plugins de vim se vuelve muy trabado
    • Además, los conflictos de keybindings entre el editor, el plugin de vim, el terminal y la gestión de ventanas son frecuentes e incómodos
    • También probó el editor Zed, pero en ese momento aún estaba inmaduro y el problema de los conflictos de keybindings seguía igual
  • Empezó a usar nvim (Neovim) directamente en el terminal, pero
    • el proceso de copiar y pegar manualmente en el editor los nombres de archivo encontrados con ripgrep y similares era demasiado molesto
    • En especial, cuando en los resultados de ripgrep aparecían juntos el nombre del archivo y el número de línea,
      • se producían errores de sintaxis cada vez que pegaba
      • y terminaba editando cosas innecesariamente antes de abrir realmente el archivo
    • Sintió que necesitaba un flujo de trabajo para abrir rutas de archivo directamente, como el ctrl-click de VSCode
  • Por eso terminó implementando por su cuenta la funcionalidad que quería usando tmux
    • Cuando la gente le pregunta por qué usa tmux, explica que es precisamente por esta automatización y por la persistencia de sesión
    • El terminal es mucho más potente de lo que parece, pero con las funciones básicas esta clase de automatización no se hace evidente
    • Aunque tmux es viejo, tiene una sintaxis compleja y hasta bugs, lo eligió por su extensibilidad y capacidad de personalización

Principales métodos de implementación

Buscar nombres de archivo en todo el scrollback desde tmux

  • Hace matching de patrones de nombres de archivo con expresiones regulares complejas en el copy-mode de tmux
  • Con un script regex hecho por él mismo (search-regex.sh), resalta incluso la ruta del archivo, la línea y la columna
  • Ejemplo de configuración de tmux: 
    bind-key f copy-mode \; send-keys -X search-backward '정규표현식'

Abrir el archivo seleccionado en una nueva ventana o en la ventana actual

  • Personaliza atajos de tmux para abrir el archivo seleccionado en la app predeterminada o en el editor (nvim, etc.)
  • Incluye soporte para rutas relativas y expansión de tilde 
    bind-key -T copy-mode-vi o  send-keys -X copy-pipe 'cd #{pane_current_path}; ...'  
bind-key -T copy-mode-vi O  send-keys -X copy-pipe-and-cancel 'tmux send-keys ...'

Abrir archivos en una instancia de nvim ya abierta

  • Con un script en perl, tmux encuentra un pane específico de nvim y le envía directamente la entrada de teclado con la información del archivo y la línea
  • Convierte la sintaxis file:line:column en comandos de vim para abrirlos automáticamente

Ventajas y límites de este enfoque

  • Supera las limitaciones funcionales del terminal local: permite explorar, modificar y buscar archivos libremente en un servidor remoto mediante tmux
  • Permite el mismo flujo de trabajo aunque el editor no soporte protocolos de edición remota
  • Integra completamente keybindings, búsquedas, cambio de archivos y gestión de buffers a su gusto
  • Permite automatizar más rápido y más fácil que creando un plugin para VSCode
  • Como los scripts hechos por él son frágiles y difíciles de mantener, resulta complicado recomendárselos a otros

Soluciones alternativas

  • Combinaciones de open source/herramientas que en general recomienda:
    • fish + zoxide + fzf: puede reemplazar flujos de trabajo de búsqueda difusa de directorios, búsqueda de comandos y parte de la búsqueda de archivos
    • Las funciones integradas del editor (tabs, ventanas, fuzzy finder, etc.) también son suficientes para la mayoría de usuarios
    • qf: permite seleccionar archivos desde la salida del terminal, pero no puede integrarse con herramientas interactivas y usa una CLI estilo vi
    • e: pequeña utilidad que reconoce rutas file:line (requiere scripts separados según el tipo de editor)
    • vim --remote, code filename, emacsclient, etc. también logran un efecto parecido, aunque el reconocimiento de file:line es incompleto

Conclusión y lecciones

  • El terminal es muchísimo más potente de lo que parece y, si se combinan scripts manualmente, permite automatizaciones imposibles en herramientas con GUI
  • Aun así, existen límites prácticos como la mantenibilidad y los bugs inherentes de los scripts
  • Si te interesa automatizar flujos de trabajo en el terminal, lo más realista es empezar construyendo gradualmente un entorno personalizado con tmux/nvim/fzf

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-06-24
Opinión de Hacker News

  • Yo también uso un truco parecido. Aprovecho el scrollback de tmux y canalizo la salida tokenizada a zsh para poder usar autocompletado sobre todo lo que aparece en la pantalla de tmux. Comparto el post relacionado en Threads y el código del gist. Me ha sido realmente muy útil

  • Me encanta este tipo de workflow, y yo también llevo años iterando y puliendo algo parecido. Con el tiempo he intentado reducir al mínimo las capas personalizadas, porque mientras más overlays agregas, mayor es el costo de mantenimiento. Incluso en Vim puro (sin tmux aparte) se puede hacer la mayor parte de lo que se muestra en el post, por ejemplo con rg --vimgrep restore_tool | vim -c cb - (vim -c cb - es de mis funciones favoritas en Vim, y hasta me sorprende que casi nadie la use). Claro, volver a ejecutar la búsqueda con rg cada vez puede ser pesado, así que yo suelo analizar los resultados en la terminal y, si hace falta, uso un comando personalizado de tmux para copiar la salida del último comando y mandarla a vim. A veces uso este truco con caracteres Unicode en el prompt y otras veces lo paso con tmux saveb - | vim -c cb -

    • Hace 10 años tiré una configuración enorme de vim con múltiples archivos y paquetes, y desde entonces la he ido simplificando hasta dejar un vimrc muy sencillo al que le agrego apenas 1 o 2 líneas por año. Las configuraciones por defecto en software veterano suelen estar así por una razón, y recomiendo entender primero esa razón antes de cambiarlas sin más
    • (Mencionaste que vim -c cb - es de tus funciones favoritas en Vim; me da curiosidad si podrías explicar qué hace. Probé ls | vim - y ls | vim -c cb -, pero no me queda claro cuál es la diferencia de inmediato)
    • Me pregunto si sirve para lo mismo que vim -q <(ripgrep --vimgrep restore_tool)

  • Esta configuración se ve bien porque incluye tmux, fzf, rg, zoxide y un nvim limpio. Si no están, también recomendaría atuin, starship, bat, glow, duf, dogdns, viddy, gum/sesh, dust, btop, etc. Todo eso se encuentra en las listas de Awesome Terminal XYZ en GitHub. atuin de verdad es casi indispensable, y no usar zoxide se siente como ser atleta pero con zapatos que no te quedan bien. Para grabar video de terminal, asciinema es mejor opción. De hecho, antes a este tipo de setup se le llamaba simplemente "ser programador". Hoy también son obligatorias herramientas como VSCode, Zed o Cursor, y además hay que saber qué pedirle a qué LLM. Estas herramientas son el nuevo “mínimo”, pero no reemplazan el entorno que ya tienes. Por muy bien que uses Claude Code, gptel y demás, a veces hasta te pueden romper el árbol, y no me imagino usar git sin magit. Si alguien cree que Cursor puro lo hace más rápido que el OP, que grabe un video usando un LLM en una situación real

    • Ser programador no se trata solo de configurar el entorno de desarrollo. Algunos programadores muy conocidos usan con gusto el editor ex, mientras que hay principiantes con IDEs muy vistosos pero con poca comprensión de fondo. Claro que las buenas herramientas pueden ayudar, pero en la práctica su impacto en el éxito real suele ser pequeño. Tal vez los LLM cambien eso. Por ejemplo, aunque tengas unos tenis mal ajustados y eso te haga 5% más lento, en una startup el éxito o el fracaso no suelen definirse por detalles tan pequeños. Normalmente la causa está en cosas más grandes, como conflictos entre cofundadores, pérdida de motivación o un mal ajuste producto-mercado
    • Tu lista de herramientas está bien, pero para alguien que no conoce nombres como atuin, dogdns o btop, la mayoría puede sonar bastante ajena
    • Me encantó la lista de comandos. Yo también agregaría fd (de sharkdp) sí o sí. Es un reemplazo de find y es excelente en usabilidad. Y atuin ha sido la mejora más grande de toda mi vida en la CLI. Me deja encontrar con muchísima facilidad incluso comandos raros que ejecuté hace 6 meses
    • Siento que hay demasiada obsesión con elegir herramientas. Un desarrollador realmente bueno saca resultados rápido incluso en un entorno pelado. Claro, las buenas herramientas pueden ayudar un poco más, pero la mayor parte de esto es diversión personal y preferencia. Si de verdad sientes que tu productividad depende muchísimo del IDE, eso significa que todavía te queda bastante camino por recorrer y crecer. Desde siempre, conocer herramientas no ha sido equivalente a ser programador. La mayoría de los mejores developers que he visto arrasan con poco más que more/grep/vi y mucha reflexión. El valor al final sale del pensamiento. Incluso en la era de los LLM eso sigue siendo cierto

  • Lo más probable es que todo usuario de vim/tmux haya terminado construyendo su propio “Emacs de imitación” no oficial, medio bugueado pero rápido

    • Yo hasta hice un emulador de terminal que reemplaza el prefijo de dos teclas de tmux por una sola tecla modificada con ctrl para todos los comandos. Enlace al proyecto
    • Yo uso tanto vim/tmux como emacs (y antes usé solo emacs durante mucho tiempo), y mi entorno de emacs era mucho más improvisado, menos documentado y más lleno de bugs. Mi setup de vim+tmux es relativamente estable
    • Me identifiqué muchísimo con eso. Ahora mismo en mi workflow corro :Term dentro de nvim
    • El entorno vim+tmux depende mucho de primitivas del sistema como pipes, archivos, señales y scrollback. Por eso suele funcionar de forma natural y transparente en entornos con tooling diverso, por ssh o incluso con shells restringidos. Eso es una gran ventaja para portabilidad y depuración. En otras palabras, siento que mi workflow puede fragmentarse libremente sobre esas garantías básicas, así que construir yo mismo mi configuración de vim se siente como la opción más obvia

  • Me da curiosidad cómo usa realmente tmux en Windows, ya que dice que lo usa ahí. Ojalá alguien pudiera explicarlo

    • Yo asumiría que se conecta de forma remota a un sistema Unix y hace ahí el trabajo real. En un servidor Unix puedes correr tmux perfectamente. Yo también a veces entro por SSH a una VM de VirtualBox y uso una capa de compatibilidad más limpia que WSL. En parte esa es una de las fortalezas de tmux frente a otros métodos: si está instalado en el servidor remoto, sigue cumpliendo su función completa. Aquí hay una explicación relacionada

  • Me encanta esta forma de compartir workflows. Está muy bien pensada para el público objetivo. Me habría gustado que el video tuviera audio, pero igual estuvo bien poder leer después la lista de acciones. Aprendí varias cosas que me sirven para mi propio workflow. Mencionaron los atajos de teclado crípticos de tmux; ¿alguien aquí ha usado byobu? byobu es un wrapper de tmux que asigna la mayoría de los comandos a teclas F#. Lo conocí hace 10 años y desde entonces lo sigo usando. Antes de eso pasé varios años con tmux puro

    • Me alegra que el contenido te haya parecido entretenido :) Intenté hacerlo lo más claro y fácil de escanear posible. Tengo la mayoría de los atajos de tmux remapeados. ctrl-k es mi prefijo, y h no conserva el valor por defecto de "seleccionar panel izquierdo". Nunca he usado byobu, pero por lo que describes parece más bien una capa para hacer más cómodos los atajos por defecto, y no siento que quiera agregar mucho más encima

  • También puedes extender cosas como el modo de copia sin escribir un regex gigante tú mismo, usando plugins de tmux como tmux-fpp, tmux-copycat, tmux-fingers y tmux-urlview. Tal vez te convenga apoyarte lo más posible en las funciones integradas por velocidad. A mí en particular también me encantan tmux-resurrect (guardar/restaurar sesiones), tmux-continuum (automatización) y tmux-zen para Oh-My-Fish. Comparto tmux-resurrect, tmux-continuum y tmux-zen. Quiero recalcar que montar un entorno tmux genial es más fácil de lo que parece

    • Yo también tomé el regex original de tmux-copycat. Pero a) ese regex no detecta bien :, y b) copycat usa su propia abstracción de visor, así que en una sola búsqueda solo puedes hacer una acción. Mi método reutiliza la búsqueda integrada de tmux, así que puedo vincular libremente la acción que quiera a los archivos resaltados. La razón por la que la mayoría de plugins solo soportan copiar/pegar o montan su propio modo es que tmux prácticamente solo permite controlar el resaltado a través de la búsqueda integrada

  • Este setup es realmente hermoso. Pero sigue siendo un misterio que todavía no exista un typeahead de IA realmente bueno para la terminal. Cursor Tab parecería encajar perfecto, pero está bloqueado para usarlo en la terminal. Hasta dan ganas de improvisar un producto temporal que canalice la salida de la terminal a un archivo falso y luego la mande a Cursor

  • El título del artículo en realidad es "How I use my terminal"

    • La función automática de HN recorta el primer término del título cuando es How. No tiene una base muy clara; los admins dicen que es para evitar clickbait, pero en la práctica solo genera confusión
    • Al principio pensé que este post era una parodia de la película 'There Will Be Blood' (porque el título actual es 'I use my terminal')
    • Yo también pensé que era una reseña sobre un emulador de terminal hecho por alguien
    • Yo también me di cuenta de eso. Viendo el post por encima, el título completo probablemente era algo como "I use my terminal (and so should you )". Los posts sobre terminal siempre son bienvenidos, y como usuario de Chromebook, con el navegador y la terminal siempre me bastó. Cuando me paso a Mac se siente demasiado disperso, así que en el día a día uso solo terminal o navegador
    • En HN, al registrar un título, normalmente recortan automáticamente prefijos o sufijos comunes