Como usar o editor Helix para desenvolvimento em servidores remotos

 (rushter.com)
7 pontos por GN⁺ 2025-10-14 | 2 comentários | Compartilhar no WhatsApp
  • O motivo para escolher o Helix como editor para desenvolvimento em servidores remotos é que ele pode ser usado sem instalar dezenas de plugins, como no Vim/Neovim, além de reduzir o risco de ataques à cadeia de suprimentos
  • Com a integração com tmux, ele compensa a falta de um explorador de arquivos e de recursos Git TUI no Helix, permitindo executar o gerenciador de arquivos yazi, o lazygit e outros em pop-ups
  • Foram migrados atalhos no estilo Vim para que seleção de linhas, movimentação do cursor e exclusão de texto funcionem de forma semelhante ao Vim, além de alterar o ESC para resetar cursores múltiplos
  • A barra de status (statusline) foi aprimorada com informações como branch Git, codificação e posição para aumentar a produtividade
  • Usando injeções do Tree-sitter, foi possível aplicar destaque de sintaxe a consultas SQL dentro de Python/Go e a blocos de código em Markdown, melhorando a legibilidade
  • Configurações avançadas como LSP, salvamento automático e modos de cor ajudam a aumentar a produtividade e permitem personalização detalhada

Contexto da escolha do Helix

  • Devido ao aumento recente de ataques à cadeia de suprimentos e aos problemas de dependência de plugins, o Helix foi adotado no lugar de Vim/Neovim como editor para desenvolvimento em servidores remotos
  • Uma grande vantagem é que ele pode ser usado apenas com recursos nativos, sem precisar de dezenas de plugins do Neovim
  • Após a migração para o Helix, foi feito um trabalho de personalização da configuração para reproduzir o máximo possível a experiência familiar do Neovim
  • O objetivo ao compartilhar isso é ajudar outros usuários a economizar tempo

Configuração do tmux

  • É usado o Tmux como multiplexador de terminal, com atalhos personalizados para suprir a ausência de gerenciador de arquivos e de Git TUI
  • Como o Helix não permite editar arquivos a partir do explorador de arquivos, isso era inconveniente ao navegar rapidamente entre vários arquivos
  • Foram adicionados os seguintes atalhos ao arquivo de configuração do Tmux
    • prefix - y: executa o gerenciador de arquivos Yazi em uma janela pop-up (95% da tela)
    • prefix - g: executa o Lazygit em uma janela pop-up
    • prefix - e: abre o histórico de saída do Tmux no editor Helix para pesquisar e copiar conteúdo
  • O prefixo padrão é Ctrl + b, mas foi alterado para Ctrl + \
  • Isso é útil para trabalho com saída de terminal, especialmente ao copiar para o Slack a saída do cliente ClickHouse (CSV/JSON)
    • Em vez de salvar em arquivo, é possível copiar diretamente, reduzindo etapas no fluxo de trabalho
    • Também daria para usar o mouse, mas como o scroll do buffer do Tmux é desconfortável, processar isso no editor é mais eficiente
  • Yazi e Lazygit normalmente aparecem como sobreposições sobre o editor Helix

Migração de atalhos do Vim

  • Embora já tenha se acostumado aos atalhos do Helix, ainda usa alguns atalhos do Vim migrados
  • Atalhos do modo Select
    • 0: mover para o início da linha
    • $: mover para o fim da linha
    • ^: mover para o primeiro caractere não em branco
    • G: mover para o fim do arquivo
    • D: selecionar até o fim da linha, apagar e voltar ao modo normal
    • k/j: selecionar a linha inteira acima/abaixo (o comportamento padrão do Helix faz seleção parcial, o que era inconveniente)
  • Atalhos do modo Normal
    • D: apaga todo o texto à direita do cursor (foi migrado porque no Helix isso exige teclas demais)
    • V: entra no modo Select e seleciona a linha inteira
    • ESC: reseta cursores múltiplos (o padrão do Helix é vírgula, o que era inconveniente)
  • Como a forma de seleção de linhas no modo visual do Helix não agradava, ela foi alterada para o estilo do Vim
    • Ao mover para cima/baixo, a linha inteira passa a ser selecionada

Barra de status aprimorada

  • A barra de status padrão carece de informações importantes, como a branch Git atual
  • Configuração da barra de status
    • Esquerda: modo, spinner, controle de versão, nome do arquivo, indicador de somente leitura, indicador de modificação
    • Centro: vazio
    • Direita: diagnósticos, diagnósticos do workspace, posição, número total de linhas, percentual de posição, codificação do arquivo, formato de fim de linha, tipo do arquivo, registrador, número de seleções
    • Separador: caractere │
  • Isso permite entender rapidamente o estado do trabalho

Atalhos úteis

  • Com atalhos personalizados, a eficiência de trabalho aumentou bastante, embora tenha levado tempo para descobri-los
  • Os recursos mais úteis: recarregar arquivo, alternar soft wrap, Git undo, Git blame e Git diff
  • Lista completa de atalhos personalizados
    • space - e - w: salva o buffer atual como arquivo
    • space - e - c: fecha o buffer atual
    • space - e - x: fecha todos os outros buffers (útil quando há dezenas deles abertos)
    • space - e - l: alterna dicas de tipo inline (úteis, mas sempre visíveis geram muito ruído)
    • + - f: formata o arquivo atual
    • + - w: renderiza caracteres de espaço em branco (para verificar caracteres invisíveis no documento)
    • + - W: desativa a renderização de caracteres de espaço em branco
    • space - f - .: mostra/oculta arquivos ignorados pelo Git no seletor de arquivos
    • space - f - r: recarrega todos os arquivos (muito útil porque o Helix não oferece recarregamento automático; serve para mudanças externas ou atualização do gutter após commit)
    • space - f - x: faz undo da alteração Git no ponto do cursor atual
    • space - f - w: mostra o Git blame da linha atual
    • space - f - d: mostra o Git diff

Configuração do editor

  • Após 6 meses de uso, foi descoberto que existe um recurso de salvamento automático ao trocar de aba do terminal
  • Alguns recursos recentes do Helix vêm desativados por padrão, para evitar que usuários antigos sejam surpreendidos por mudanças inesperadas
  • É preciso verificar cada opção manualmente para descobrir novos recursos
  • Principais opções de configuração
    • line-number = "relative": exibe números de linha relativos
    • rulers = [120]: define uma régua vertical visual (útil para limitar o comprimento máximo da linha sem autoformatação)
    • true-color = true: força suporte a true color
    • completion-replace = true: o autocompletar substitui a palavra inteira
    • trim-trailing-whitespace = true: remove espaços em branco no fim da linha
    • color-modes = true: diferencia os modos por cores
    • rainbow-brackets = true: usa cores diferentes em parênteses aninhados (recurso recente, ainda não lançado oficialmente)
    • editor.file-picker.hidden = false: mostra arquivos ocultos (dotfiles) no seletor de arquivos
    • editor.indent-guides.render = true: adiciona guias visuais de indentação
    • editor.inline-diagnostics.cursor-line = "warning": melhora a exibição de diagnósticos (veja a captura de tela)
    • editor.auto-save.focus-lost = true: salva automaticamente ao perder o foco (requer suporte do terminal)
    • editor.auto-save.after-delay.enable = true: salva automaticamente após um atraso definido (configurado em 300 segundos)

Ajustes de LSP

  • Foi adicionado o LSP harper-ls para todas as linguagens, para destacar erros gramaticais em comentários

Injeções personalizadas de Tree-sitter

  • O Helix permite definir injeções personalizadas de Tree-sitter, possibilitando destacar uma linguagem dentro de outra
  • Casos de uso
    • Destaque de sintaxe para consultas SQL dentro de Python e Go
    • Destaque de YAML front matter e blocos de código em Markdown
    • Também pode ser usado para destacar snippets HTML
  • Os arquivos de configuração foram publicados no GitHub para compartilhar as injeções personalizadas e as configurações
  • O Helix se destaca como um editor de terminal de nova geração por suas vantagens em minimização de plugins, segurança e personalização intuitiva

Leituras relacionadas

2 comentários

 
xguru 2025-10-14

Um desenvolvedor que usou Vim por 20 anos compartilha sua experiência ao migrar do Vim para o Helix
 
GN⁺ 2025-10-14
Comentários no Hacker News

  • Recentemente estou reconstruindo minhas configurações de editor. Uso Emacs há 20 anos e Vim há 15, em paralelo, e não consigo escolher um dos dois. O objetivo é ver quão rápido consigo montar uma configuração pronta para uso imediato em trabalho com software Python de nível enterprise. Desta vez estou tentando especialmente reduzir ao máximo a dependência de extensões de terceiros e manter só o que for necessário. Minha configuração atual do Neovim é, na minha opinião, a melhor que já tive, mas acabei usando mais plugins do que esperava. No caso do Emacs, ainda estou no começo, mas é interessante ver o quanto ele evoluiu a ponto de, a partir da versão 30, a necessidade de plugins de terceiros cair bastante. Antes eu usava lsp-mode, mas hoje estou satisfeito com o Eglot. O completion preview mode também é bem decente, embora não substitua totalmente o corfu. Minha lista de plugins indispensáveis no Emacs é Magit, Expreg(teeesitter expand region), Multiple cursors e dape(depuração integrada ao Eglot). Provavelmente também vou adicionar Consult e orderless. Minha configuração do Neovim pode ser vista aqui

    • O novo nvim também está reduzindo cada vez mais a necessidade de plugins. Já traz gerenciador de plugins embutido, visualizador de diff e lsp

    • Você está gerenciando bastante plugin de nvim! Na semana passada reescrevi minha configuração do nvim com 4 plugins, incluindo mini.nvim. Senti que, quando você coloca plugin demais, a estabilidade e a confiabilidade do nvim caem bastante. Tenho inveja de você precisar de só 2 no Emacs, e com certeza isso deve funcionar de forma bem mais estável. Minha configuração pode ser vista aqui

    • Fico curioso se, depois de usar por alguns meses, você ainda acha que chega perto do nível da configuração padrão que vem com Pycharm+IdeaVIM. Claro, também existe a diversão de mexer na própria configuração, mas se o foco for só usar uma IDE com eficiência, não seria meio ineficiente investir tanto tempo configurando o Neovim?

    • Expreg(teeesitter expand region) me lembra o combobulate(ainda não usei, mas parece legal). Só que o Expreg passa uma sensação de ser muito mais simples e leve

    • Tenho muita curiosidade sobre relatos de usuários antigos de Emacs. Queria saber como ele se compara com Helix/Vim. Quando alguém diz que usou Helix/Vim pela primeira vez e gostou, parece que está falando sem conhecer o verdadeiro valor de usar Emacs por muitos anos. De fato, teclas ao estilo Vim e modos parecem estar melhor integrados nos editores de hoje, mas quando tentei usar, me faltou paciência para aguentar até meus dedos se acostumarem. Queria muito ouvir relatos de migração de usuários hardcore de Emacs

  • Eu migrei de Emacs → VS Code → Helix. Até agora tenho tentado aprender ao máximo os atalhos existentes e usar de forma eficaz quase sem mexer nas configurações. Como é difícil memorizar tudo o que o Helix consegue fazer, fiz um deskmat para deixar na mesa com as teclas impressas. Só vou saber o quanto isso ajuda de verdade depois de imprimir e usar. Meu deskmat pode ser visto aqui

    • Fiquei curioso sobre quanto tempo você usou Emacs

  • Uso Emacs como editor principal há 10 anos, e antes disso usava Sublime Text. Para edição simples de arquivos ou em servidores remotos, às vezes uso Vim, mas nunca senti necessidade de usar só Vim por completo. No Emacs eu criei meus próprios módulos e funções para ter um ambiente sob medida. No mês passado experimentei Helix e foi surpreendentemente simples começar. Também me adaptei rápido ao básico — navegação, busca, colagem, troca de buffers/janelas. Não sei muito sobre a história do Helix, mas o design é excelente. A busca global é especialmente boa, a integração com lsp funciona certinho e ele é realmente muito rápido. É muito agradável sentir que os padrões já vêm definidos de forma consistente e útil. Pretendo continuar usando para me familiarizar mais e, embora meu editor padrão ainda seja o Emacs, o Helix é tão rápido que pode acabar virando meu editor principal para codar

  • Estou começando a usar Helix e sinto fortemente duas desvantagens

    • A edição modal é central, mas no Vim dá para reaproveitar a muscle memory em qualquer lugar (modo Vim existe em quase todo lugar, há extensões como Vimium, e em ambiente ssh quase sempre tem Vim)
    • O Helix busca simplicidade, então não tem integração de terminal nem muita extensibilidade por plugins (até lint só é suportado via lsp), e essa combinação parece um limite porque significa que você precisa montar algo por cima do editor (como usar tmux etc.) Não estou criticando as desvantagens, só queria entender quais vantagens compensam isso

    • Não entendo bem por que LSP seria uma desvantagem. Parece mais que o LSP roda como processo separado, o que na verdade me parece bom para sandboxing de plugins. Na prática, talvez até funcione melhor do que plugins tradicionais de editores. Também não sinto falta de integração com tmux; uso mais Emacs, mas quase nunca uso terminal interno. Se eu só tiver que transferir a muscle memory, um editor rápido feito em rust já é convincente o suficiente

    • Existe esse argumento de que os movimentos do Vim viram muscle memory e podem ser usados em qualquer lugar, mas, na prática, quase nenhum desenvolvedor quer usar o Vim básico exatamente como vem, sem plugins nem configuração. A maioria quer um editor ajustado nos mínimos detalhes, com seu próprio setup e recursos. A exceção seriam pessoas que realmente acessam várias máquinas por ssh e precisam do ambiente de editor padrão. Sobre a simplicidade do Helix e a limitação de plugins: originalmente o Helix buscava ser um editor tudo-em-um, mas a comunidade não quis isso, então um sistema de plugins está em desenvolvimento. Ainda não entrou no release principal, mas já existem vários plugins sendo criados e usados em um branch separado. Acho que é a escolha certa adiar o release até o sistema de plugins estar estável o suficiente. A maior vantagem do Helix é que ele melhorou a UX inconveniente que ainda existe em vi/vim/neovim. Ou seja, ao mudar a ordem de trabalho, fica mais fácil ver o que mudou antes de confirmar a edição, reduzindo efeitos colaterais não intencionais

  • Com esse nível de configuração, acho que seria melhor simplesmente usar vim. Você está tentando reproduzir funcionalidades do vim dentro do Helix, e o Helix também tem muitas dependências internamente (só que, diferente do nvim, isso não aparece tanto na superfície). Minha configuração do vim8 continua simples há mais de 8 anos. Uso vim8 porque é a versão que vem nas distribuições LTS. Só tenho um plugin carregado automaticamente (vim-tmux-navigator, para navegar facilmente entre splits do vim e do tmux), revisei o código e não atualizo. Dois plugins “opcionais” eu ativo com :packadd! quando preciso, usando o gerenciador de pacotes embutido do vim. Uso apenas ale(lsp, diagnósticos, autoformatação ao salvar) e vim-fugitive(integração com git). O ale não tem dependências. O vim-fugitive, depois de instalado, é só usar. O motivo para não carregar plugins automaticamente é que, em geral, o vim serve para edição rápida; só em projetos longos eu ativo git/lsp. Não faz sentido usar plugin desnecessário

    • Eu também gosto do Neovim moderno, então estou resolvendo esse problema criando um pacote Python (especialmente para quem já está no ecossistema Python ou usa uv, pipx). Dá para instalar a versão mais recente do Neovim com uv tool install binwheels-neovim ou pipx install binwheels-neovim, e funciona direto em Windows, macOS e Linux. Esse pacote empacota os releases oficiais do Neovim e usa uv ou pipx para buscar o binário certo para o sistema operacional/arquitetura. No caso do Linux, como é preciso suportar uma versão de GLIBC mais antiga que a dos releases oficiais, eu faço um build separado e disponibilizo. Mais detalhes em PyPI, Github principal, logs de build

    • O Helix tem uma superfície de ataque de supply chain extremamente menor do que nvim+plugins. Tudo é mantido dentro do próprio Helix, então ele é muito mais seguro do que nvim, onde cada plugin pode ter seu próprio fornecedor. Os releases do Helix são lentos e cautelosos, então ele é mantido de forma que até uma vulnerabilidade não vire um grande problema

    • O modelo de edição do Helix é superior

  • Se você precisa de TUI usando Helix, fico pensando por que usar Helix em vez de neovim. Gosto dos padrões do Helix, mas parece que chega um ponto em que, quando você precisa mudar alguma coisa, tudo vai ficando cada vez mais trabalhoso. E se você quer uma “experiência completa de IDE” com Helix, também não vejo por que não usar Zed, VSC ou uma IDE da JetBrains. Eu, quando preciso de algo simples, uso nvim; quando preciso de mais recursos, abro o WebStorm ou uso junto com um colega para procurar alguma coisa

    • Ao trabalhar por ssh em máquinas fracas, o Helix abre quase instantaneamente. Montar os mesmos recursos no nvim deixa tudo mais lento, além de aumentar o custo de manutenção de configurações e atualizações de plugins. Também conheço rust, então posso contribuir corrigindo bugs. Não conheço linguagens da família C, então prefiro projetos open source feitos em linguagens que conheço. Sou um programador por hobby que usou só n/vim por 12 anos e, nos últimos 2, migrou para Helix. Na verdade ainda sinto falta de várias coisas do nvim e há partes que parecem mais naturais lá, mas o helix realmente “simplesmente abre”, e esse conforto supera todo o resto

    • Nos últimos anos usei por um tempo neovim, helix, emacs e nano, cada um por um período, e a experiência out-of-the-box do helix foi disparada a melhor. Os padrões são muito bem definidos, e a ajuda contextual e as dicas aparecem muito bem, então você pode esquecer comandos que usa bastante e ainda assim encontrar facilmente os que usa raramente. Além disso, na minha cabeça, a ordem de operação dos comandos do helix parece mais natural que a do vim. Editores modernos como nvim/spacemacs têm uma barreira muito alta de plugins/configuração. Graças ao ecossistema de plugins, eles podem fazer coisas que o helix ainda não consegue (por exemplo: o emacs permite usar praticamente qualquer linguagem Lisp como se fosse uma IDE, enquanto o helix não consegue carregar um REPL), mas em troca você precisa aprender não só o editor em si, como também inúmeros plugins, e mesmo pesquisando as respostas variam conforme versão e combinação, o que gera confusão. Ao montar algo novo, no fim você acaba confiando na recomendação de alguém ou gastando tempo extra testando e aprendendo. Como o helix é um projeto novo, ele não carrega o peso de decisões antigas e pode adotar escolhas e padrões alinhados ao desenvolvimento moderno. Não é perfeito, mas, para quem está começando em TUI agora e quer algo utilizável imediatamente e fácil de usar sem configuração, eu recomendaria helix

    • O hx é rápido para iniciar e executar, e ainda por cima é bonito. Os padrões já me satisfazem bastante, então fiz só pequenos ajustes, e diferente do emacs/neovim, onde eu vivia preso num loop sem fim de melhorias, no hx parece que existe um fim. A TUI também funciona bem em servidores remotos, então uso exatamente o mesmo ambiente em mac, linux e servidor (outros editores também conseguem, mas o hx faz isso bem). Todos os lsp de que preciso funcionam bem, e configurar languages.toml foi um pouco chato, mas isso também acontece em outros editores

    • Gosto da configuração simples e do modelo de edição selection-first. Sobre isso, há uma referência aqui. Conversando com pessoas que tiveram dificuldade para se adaptar ao Vim, percebi que eu já estava acostumado a um modelo de “selecionar primeiro”, como o do Helix. Tive dificuldade para me adaptar ao estilo do Vim, em que o texto-alvo não aparece visivelmente antes da ação (você só vê o alcance do efeito depois do comando)

    • Escolher editor não é uma decisão tão racional assim; fatores psicológicos como gosto pessoal, sensação de novidade e diversão pesam muito mais

  • Eu não conhecia o comando :reset-diff-change. Sempre usei checkout -p no git, mas fazer isso direto dentro do Helix parece muito mais prático

  • Usei Helix, me esforcei bastante para me adaptar e hoje consigo usá-lo com fluência. Mas acabei percebendo que esse “fluxo de trabalho invertido”, embora seja fácil de aprender e implementar, na prática deixa tudo mais lento. Então no fim voltei para Vim e depois para Zed(modo Vim)

  • Testei Helix hoje pela primeira vez e é um editor realmente muito bem projetado. Mesmo assim, senti falta de atalhos rápidos do Vim como y2$, dw

    • Na verdade não é que esses atalhos não existam; y2$ seria 2xy, e dw seria wd

  • Ainda não encontrei como deletar a linha atual no Helix incluindo linhas vazias. xd apaga uma linha quando ela não está vazia, mas se a linha estiver vazia, duas linhas são apagadas ao mesmo tempo

    • x seleciona a linha atual; se já houver seleção, ele expande para a próxima linha. X expande a seleção até os limites da linha (seleção line-wise). É isso que você deve usar

    • Em linha vazia, basta usar d

    • É sutilmente incômodo. Eu também uso um fork trivial em que mudei o comportamento do x em linhas vazias. Mais detalhes neste PR