Como eu uso o Windows Terminal – automação extrema de terminal com tmux e um workflow customizado

• tmux, SSH, nvim e scripts poderosos de busca e automação são combinados para implementar um workflow único que permite explorar, editar e pesquisar arquivos em um servidor remoto imediatamente, sem GUI
• Com uma única combinação de teclas, pesquisa automática de nomes de arquivos em várias janelas do tmux e abertura imediata, além de troca de arquivos e gerenciamento de buffers, tudo é feito por atalhos
• Insatisfeito com a lentidão do VSCode e conflitos de keybinds, o autor integrou todas as operações por conta própria com scripts
• Combinando ferramentas Unix como regex, perl, tmux e nvim, ele viabilizou o reconhecimento automático de caminhos de arquivo e informações de linha, além da abertura direta
• Embora o processo de implementação seja muito complexo, ele mostra como é possível maximizar o poder e a extensibilidade do terminal

---

Meu jeito de usar o terminal

• Este texto compartilha a experiência de montar um ambiente de desenvolvimento eficiente combinando terminal e ferramentas
• Como se trata de um processo complexo que normalmente exigiria vídeo, ele conecta texto e gravações reais em vídeo (assistir ao vídeo é essencial)
• Algumas etapas do vídeo (0:11, 0:21, 0:41) são momentos em que muita gente se surpreende e pensa: "isso é possível?"

Resumo passo a passo do workflow de terminal mostrado no vídeo

• 0:00 : Executa o Windows Terminal no notebook
• 0:02 : Abre uma nova aba do terminal com o atalho ctrl + shift + 5, conecta ao desktop de casa com ssh e executa tmux imediatamente
• 0:03 : Executa o shell padrão zsh no tmux, mostra o prompt e carrega toda a configuração de forma assíncrona
• 0:08 : Usa zoxide para fazer busca fuzzy em diretórios recentes e navegar até eles
• 0:09 : Começa a digitar o comando ripgrep, o zsh completa automaticamente com base no histórico anterior, e ele aceita com ctrl + f
• 0:11 : Com o atalho ctrl + kf, pesquisa nomes de arquivos em todo o scrollback do tmux, com os nomes destacados em azul
• 0:12 : Continua pressionando a tecla n para navegar pela lista de arquivos encontrados na busca
• 0:21 : Com a tecla o, abre o arquivo selecionado no app padrão (nvim), executado por uma nova janela do tmux (ainda funcionando no servidor remoto)
• 0:26 : Tenta navegar por várias referências no código com rust-analyzer; alguns macros não são reconhecidos, mas em 0:32 a navegação funciona normalmente
• 0:38 : Com ctrl + kh, muda o foco do tmux para a janela da esquerda
• 0:39 : Pressiona n novamente para continuar navegando pelos resultados anteriores da busca de arquivos no estado de "copy-mode"
• 0:41 : Com a tecla o, desta vez abre outro arquivo na instância existente do nvim
• 0:43 : Com a tecla b, verifica a lista de buffers de arquivos abertos e alterna entre os dois arquivos para encerrar

Por que ele passou a usar esse workflow de terminal?

• O VSCode é lento, especialmente com plugins de vim, e fica travando bastante
  • Entre editor, plugin de vim, terminal e recursos de gerenciamento de janelas, há conflitos frequentes de keybinds, o que atrapalha
  • Ele também testou o editor Zed, mas na época ainda era imaturo e o problema de conflito de keybinds continuava
• Ele começou a usar nvim (Neovim) diretamente no terminal, mas
  • o processo de copiar manualmente os nomes dos arquivos encontrados com ripgrep e colá-los no editor era trabalhoso demais
  • especialmente quando o resultado do ripgrep trazia nome do arquivo e número da linha juntos,
    • surgiam erros de sintaxe a cada colagem
    • e muitas vezes era preciso editar coisas desnecessariamente antes mesmo de abrir o arquivo de fato
  • ele sentiu falta de um workflow que abrisse caminhos de arquivo diretamente, como o ctrl-click do VSCode
• Por isso, ele acabou implementando por conta própria os recursos desejados com tmux
  • Quando perguntam por que as pessoas usam tmux, ele explica que é justamente por causa dessa automação e da persistência de sessão
  • O terminal é muito mais poderoso do que parece, mas só com os recursos básicos essa automação não fica evidente
  • Embora o tmux seja antigo, tenha sintaxe complexa e alguns bugs, ele o escolheu pela extensibilidade e possibilidade de customização

Principais formas de implementação

Busca de nomes de arquivos em todo o scrollback no tmux

• Correspondência de padrões de nomes de arquivo com expressões regulares complexas no copy-mode do tmux
• Um script de regex feito por ele (search-regex.sh) destaca caminho do arquivo, linha e coluna
• Exemplo de configuração do tmux:

  bind-key f copy-mode \; send-keys -X search-backward '정규표현식'  
  

Abrir o arquivo selecionado em uma nova janela/na janela atual

• Com atalhos do tmux, o arquivo selecionado é aberto no app padrão ou no editor (nvim, etc.) de forma customizada
• Com suporte a caminhos relativos e expansão de til

  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 arquivos em uma instância do nvim já aberta

• Com um script em perl, o tmux encontra um pane específico do nvim e envia diretamente para ele a entrada de teclas com informações de arquivo/linha
• A sintaxe file:line:column é convertida em um comando do vim para abertura automática

Vantagens e limitações dessa abordagem

• Supera os limites funcionais do terminal local: permite explorar, editar e pesquisar arquivos livremente em um servidor remoto via tmux
• Mesmo que o editor não ofereça suporte a protocolos de edição remota, o mesmo workflow continua possível
• Todos os keybinds, buscas, troca de arquivos e gerenciamento de buffers são integrados exatamente do jeito desejado
• É mais rápido e fácil automatizar assim do que criar um plugin para o VSCode
• Como os scripts feitos por ele são frágeis e difíceis de manter, é difícil recomendá-los para outras pessoas

Soluções alternativas

• Combinações de open source/ferramentas geralmente recomendadas:
  • fish + zoxide + fzf: pode substituir workflows de diretórios com fuzzy search, busca de comandos e parte da busca de arquivos
  • Recursos embutidos do editor (abas, janelas, fuzzy finder etc.) já são suficientes para a maioria dos usuários
  • qf: permite selecionar arquivos a partir da saída do terminal, mas não se integra com ferramentas interativas; usa uma CLI no estilo vi
  • e: pequena ferramenta que reconhece caminhos file:line (exige scripts separados para cada tipo de editor)
  • vim --remote, code filename, emacsclient etc. também produzem efeito semelhante, mas o reconhecimento de file:line é incompleto

Conclusão e lições

• O terminal é muito mais poderoso do que parece e, quando combinado diretamente com scripts, permite automações impossíveis em ferramentas GUI
• Ainda assim, há limitações práticas, como manutenção e bugs inerentes aos scripts
• Se houver interesse em automação de workflows no terminal, o mais realista é começar montando gradualmente um ambiente customizado com tmux/nvim/fzf

[GN⁺]

Comentários do Hacker News

• Eu também uso um truque parecido. Aproveito o scrollback do tmux e canalizo a saída tokenizada para o zsh, então consigo usar autocompletar para tudo que está visível na tela do tmux. Compartilhei um post no Threads relacionado e o código no gist. Foi realmente muito útil

• Gosto muito desse tipo de workflow, então também venho refinando algo parecido há anos, repetidamente. Com o tempo, tenho tentado reduzir ao máximo as camadas de customização, porque quanto mais overlays você adiciona, maior fica o custo de manutenção. Dá para fazer a maior parte do que o post mostra só com Vim puro (sem tmux separado), por exemplo com rg --vimgrep restore_tool | vim -c cb - (vim -c cb - é um dos meus recursos favoritos do Vim, e acho curioso como quase ninguém usa). Claro, rodar a busca do rg de novo toda vez pode ser pesado, então eu costumo analisar os resultados no terminal e, se precisar, uso um comando customizado do tmux para copiar a saída do último comando e mandar para o vim. Às vezes uso esse truque com caractere Unicode no prompt e, em outros casos, passo com tmux saveb - | vim -c cb -

  • Há 10 anos abandonei uma configuração gigantesca de vim com múltiplos arquivos e múltiplos pacotes e venho simplificando cada vez mais, criando só um vimrc bem simples com 1 ou 2 linhas por ano. As configurações padrão de softwares antigos geralmente existem por um motivo, e eu recomendaria entender esse motivo antes de sair mudando tudo
  • (Você disse que vim -c cb - é um dos seus recursos favoritos do Vim; será que pode explicar o que isso faz? Eu testei ls | vim - e ls | vim -c cb -, mas não percebi de imediato qual é a diferença)
  • Queria saber se isso tem a mesma finalidade de vim -q <(ripgrep --vimgrep restore_tool)

• Esse setup fica bonito porque inclui tmux, fzf, rg, zoxide e um nvim limpo. Se ainda não tiver, eu também recomendaria atuin, starship, bat, glow, duf, dogdns, viddy, gum/sesh, dust e btop. Dá para achar todos nas listas Awesome Terminal XYZ no GitHub. O atuin é realmente essencial, e ficar sem zoxide é como ser atleta usando um tênis que não serve direito. Para gravar vídeos de terminal, asciinema é uma escolha melhor. Na verdade, antigamente esse tipo de setup se chamava simplesmente “programador”. Hoje em dia também é obrigatório dominar ferramentas como VSCode, Zed, Cursor etc., além de saber o que delegar para cada LLM. Essas ferramentas são só o novo “mínimo”; elas não substituem o ambiente que já existia. Você pode ser muito bom com Claude Code, gptel e afins, mas às vezes ainda vai quebrar a árvore, e para mim é impensável usar git sem magit. Se alguém realmente acha que Cursor puro é mais rápido que o setup do autor, eu diria para essa pessoa gravar um vídeo usando LLMs em produção de verdade

  • Ser programador não é só configurar ambiente de desenvolvimento. Alguns programadores famosos usam ex, e alguns iniciantes têm uma IDE toda enfeitada, mas ainda sem entendimento fundamental. Claro que boas ferramentas podem ajudar, mas o impacto delas no sucesso real geralmente sempre foi pequeno. Talvez os LLMs mudem isso. Por exemplo, mesmo que um tênis ruim te deixe 5% mais lento, não é esse tipo de detalhe que define sucesso ou fracasso numa startup. Normalmente a causa é algo maior, como conflito entre cofundadores, perda de motivação ou falta de product-market fit
  • Sua lista de ferramentas é boa, mas, para quem não conhece nomes como atuin, dogdns, btop e a maioria dos outros, isso talvez soe um pouco obscuro
  • Adorei a lista de comandos. Eu também acrescentaria fd (do sharkdp) sem falta. É um substituto para o find e é excelente em usabilidade. E o atuin foi o maior upgrade da minha vida em CLI. Ele me permite encontrar com muita facilidade até comandos raros que digitei há 6 meses
  • Parece haver um apego excessivo à escolha de ferramentas. Um desenvolvedor realmente bom entrega resultado rápido até em um ambiente pelado. Claro, boas ferramentas podem ajudar um pouco mais nas margens, mas na maior parte isso é diversão pessoal e gosto. Se você realmente sente que sua produtividade depende muito de uma IDE, isso significa que ainda tem uma longa jornada de aprendizado e evolução pela frente. Nunca existiu essa fórmula de “conhecer ferramentas = ser programador”. Os melhores desenvolvedores que já vi costumavam fazer coisas impressionantes usando basicamente more/grep/vi e reflexão. Geração de valor vem de pensamento. E isso continua valendo até na era dos LLMs

• Todo usuário de vim/tmux provavelmente já construiu, pelo menos pela metade, um “Emacs de imitação” não oficial, meio bugado, mas rápido

  • Eu até fiz um emulador de terminal que troca o prefixo de duas teclas do tmux por uma única tecla com ctrl modificada para todos os comandos. Link do projeto
  • Eu uso tanto vim/tmux quanto emacs (e antes usei só emacs por muito tempo), e o meu ambiente em emacs sempre foi muito mais improvisado, menos documentado e com mais bugs. O setup com vim+tmux é relativamente mais estável
  • Me identifiquei demais com isso. No meu workflow atual, eu rodo :Term dentro do nvim
  • O ambiente vim+tmux depende bastante de primitivas do sistema, como pipes, arquivos, sinais e scrollback. Por isso, ele funciona de forma natural e transparente em ambientes com ferramentas variadas, por SSH e até em shells restritos. Isso é uma grande vantagem em portabilidade e depuração. Em outras palavras, como meu workflow pode se fragmentar livremente sobre essas garantias básicas, montar minha própria configuração de vim parece uma escolha totalmente natural

• Ele diz que usa tmux no Windows, mas queria entender como isso funciona na prática. Seria bom se alguém pudesse explicar

  • Pelo que entendo, ele acessa remotamente um sistema Unix e faz o trabalho real lá. Dá para rodar tmux perfeitamente em um servidor Unix. Eu também às vezes acesso por SSH uma VM no VirtualBox e acho isso uma camada de compatibilidade mais limpa do que WSL. Esse também é um dos pontos em que o tmux é mais forte do que outras abordagens: se estiver instalado no servidor, ele continua cumprindo perfeitamente seu papel de forma remota. Link com explicação relacionada

• Gosto muito desse jeito de compartilhar workflows. É perfeito para o público-alvo. Eu queria que o vídeo tivesse áudio, mas também foi legal poder ler a lista de ações depois. Aprendi algumas coisas que posso aproveitar no meu próprio workflow. Ele mencionou os atalhos de teclado esotéricos do tmux; alguém aqui já usou byobu? O byobu é um wrapper para tmux que coloca a maioria dos comandos nas teclas F#. Conheci isso há 10 anos e uso desde então. Antes disso, passei alguns anos só com tmux puro

  • Fico feliz que tenha gostado do conteúdo :) Tentei deixar tudo o mais claro possível e fácil de entender de relance. Eu remapeei a maior parte dos atalhos do tmux. ctrl-k é o meu prefixo, e h não fica com o padrão de “selecionar painel à esquerda”. Nunca usei byobu, mas pela descrição parece mais uma forma de deixar os atalhos padrão um pouco mais confortáveis, então eu não teria tanta vontade de adicionar mais uma camada por cima

• Dá para expandir recursos como o modo de cópia com plugins do tmux, sem precisar fazer tudo manualmente com regex gigantes. Existem tmux-fpp, tmux-copycat, tmux-fingers e tmux-urlview. Vale lembrar que depender o máximo possível dos recursos embutidos pode ser melhor para desempenho. Eu também gosto muito de tmux-resurrect (salvar/restaurar sessões), tmux-continuum (automação) e tmux-zen para Oh-My-Fish. Apresento tmux-resurrect, tmux-continuum e tmux-zen. Quero destacar que montar um ambiente tmux muito legal é mais fácil do que parece

  • Eu também peguei a regex original do tmux-copycat. Mas a) ela não lida bem com :, e b) o copycat usa sua própria abstração de visualização, então só dá para fazer uma ação por busca. A minha abordagem reaproveita a busca embutida do tmux, então posso associar livremente a ação que eu quiser aos arquivos destacados. A razão de a maioria dos plugins oferecer só copiar/colar ou criar seu próprio modo é que o tmux praticamente só permite controlar destaque pela busca embutida

• Esse tipo de setup é realmente lindo. Mas ainda acho um mistério não existir um typeahead de IA decente para terminal. O tab do Cursor parece servir perfeitamente, mas a aplicação ao terminal continua travada. Às vezes dá vontade de montar rapidinho um produto que canalize a saída do terminal para arquivos falsos e envie isso ao Cursor

• O título do artigo na verdade é “How I use my terminal”

  • O recurso automático do HN corta o primeiro termo do título quando ele é How. Não tem uma justificativa muito boa; o admin diz que é para evitar clickbait, mas na prática só gera confusão
  • No começo eu achei que esse post fosse alguma paródia de “There Will Be Blood” (com o título atual “I use my terminal”, foi isso que me veio à cabeça)
  • Eu também achei que o texto fosse sobre alguém usando um emulador de terminal feito por conta própria
  • Agora eu também descobri isso. Batendo o olho no texto, meu chute é que o título completo seria algo como “I use my terminal (and so should you)”. Posts sobre terminal são sempre bem-vindos e, como usuário de Chromebook, para mim sempre bastaram um navegador e um terminal. Quando vou para o Mac, aquilo parece até excessivo; no dia a dia, normalmente uso só terminal ou navegador
  • No HN, ao registrar títulos, eles geralmente cortam automaticamente prefixos ou sufixos muito comuns