Chameleon: por que decidi não usar o lipgloss no meu CLI?

Faz tempo que me incomoda como a saída do terminal é desencontrada. O git status tem um jeito, o npm tem outro, o docker tem outro, e cada ferramenta "bonita" que eu instalo (bat, eza, delta…) vem com o próprio tema. No fim você junta dez ferramentas e nenhuma conversa visualmente com a outra.

Nesse inicio de fim de semana resolvi mexer nisso. Confesso que o nome veio antes da ideia: "Chameleon" tava na minha lista de nomes bons faz tempo, e quando caiu a ficha de que camaleão = mudar de cor = trocar o tema do terminal, o nome explicava o produto sozinho. Não teve como não ir atrás.

A ideia: em vez de mais um colorizador, o Chameleon não pinta o texto que já existe — ele captura a saída de máquina da ferramenta (tipo git status --porcelain) e remonta do zero, com um tema único que todos os comandos compartilham. Hoje o git status sai assim:

❯ git status

  ⎇ main ↑2  tracking origin/main

  ✚ added      staged_add.txt
  ✗ deleted    willdelete.txt
  ● modified   tracked.txt
  ? untracked  untracked.txt

Quando fui pesquisar a concorrência, levei o primeiro banho de água fria: o espaço é lotado. Tem grc, colout e pipecolor fazendo recolorização por regex faz anos. Tem bat, delta, eza, cada um impecável numa coisa só. E tem a Charm, que praticamente definiu a estética de CLI bonito de hoje. Por um momento pensei "pra quê?".

O que me fez seguir foi sacar que esses caras ou só recolorem (não reestruturam: alinhar coluna, agrupar, glifo por estado), ou são por-ferramenta com tema isolado. A fresta era exatamente o meio: reestruturar de verdade, com um tema pra tudo.

E aí veio a decisão que mais me fez pensar: usar ou não o lipgloss, da Charm. Era o caminho óbvio — o lipgloss faz cor, alinhamento, layout, detecta a capacidade de cor do terminal, tudo de bandeja. Eu escreveria umas 10x menos linhas.

Decidi não usar. Por alguns motivos.

Primeiro, soava contraditório. O Chameleon é um motor de estética de terminal. Depender da Charm — que faz justamente ferramentas de terminal bonito — pra deixar o meu terminal bonito me incomodou. A camada de estilo não é uma dependência do projeto; ela é o projeto.

Segundo, não é tanto código assim. Cor truecolor é uma escape sequence. Alinhar coluna é padding de string (contando runa, não byte, senão glifo e emoji quebram o alinhamento). Decidir se liga cor é checar isatty + NO_COLOR. Meu pacote style inteiro deu umas poucas centenas de linhas, com zero dependência. "O Chameleon não tem dependência de estilo, ele é o estilo" virou até um argumento de posicionamento que eu curti.

Terceiro, o lipgloss é otimizado pra layout de TUI — caixa, borda, flexbox pro bubbletea. Pra cuspir linha colorida no stdout eu usaria 5% dele.

A parte honesta: tem dois pedaços chatos que tô adiando de propósito — downsampling de cor (pra terminal que não faz truecolor) e largura de exibição de CJK/emoji, que é onde quem rola o próprio costuma tomar na cabeça. Pro MVP eu emito truecolor e conto runa, e deixei um ponto único no código pra plugar o go-runewidth quando doer.

Onde tá agora: é um MVP. Só o git status é reformatado de verdade; qualquer outro comando ainda passa cru. Mas a arquitetura (adapter + tema único + style próprio, em Go) tá pronta pra crescer. O próximo passo é um segundo adapter — provavelmente npm ou pytest —, porque é com dois comandos saindo visualmente irmãos que a tese do "tema único" deixa de ser papo e fica óbvia.

Fica a pergunta que eu ainda não respondi: isso é um negócio ou um projeto OSS pra ser amado e juntar estrela? Esse nicho é quase todo de graça. Por ora tô tratando como o segundo e construindo em público.

Se alguém aqui já brigou pra manter coerência visual no terminal, ou tem opinião forte sobre depender (ou não) da Charm pra esse tipo de coisa, tô curioso pra ouvir.