- Helix é um editor de texto modal baseado em terminal, um projeto open source que integra recursos modernos
- Com integração ao Tree-sitter, oferece recursos de edição com reconhecimento de sintaxe como destaque de sintaxe, cálculo de indentação e navegação de código
- Suporta Language Server Protocol, implementando recursos em nível de IDE como autocompletar, ir para definição, visualização de documentação e diagnósticos
- Escrito em Rust, funciona sem Electron ou JavaScript e pode ser usado com eficiência em ambientes SSH, tmux e terminal
- O sistema de plugins e o frontend GUI estão planejados para desenvolvimento futuro, com destaque para uma base de código leve e configurações padrão modernas
Principais recursos
- O Helix usa como unidade central de edição um sistema de múltiplas seleções e cursores inspirado no Kakoune
- Os comandos manipulam várias áreas selecionadas ao mesmo tempo, permitindo edição paralela de código
- Usa Tree-sitter para gerar árvores sintáticas tolerantes a erros
- Com isso, oferece destaque de sintaxe preciso, indentação automática e navegação de código
Recursos de manipulação e navegação de código
- Oferece seleção e movimentação por nós da árvore sintática, como funções, classes e comentários
- Isso permite edição baseada na estrutura sintática do código, e não apenas em texto simples
- Por meio do Language Server Protocol (LSP), fornece autocompletar, ir para definição, visualização de documentação e diagnósticos específicos por linguagem
- Recursos em nível de IDE podem ser usados no terminal sem configuração adicional
Base técnica
- Escrito em Rust, garante estabilidade e desempenho
- Não usa Electron, VimScript nem JavaScript
- Pode ser executado em ambientes SSH, tmux e terminal comum
- Sua estrutura leve melhora a eficiência de bateria
Recursos modernos integrados
- Inclui fuzzy finder para navegar por arquivos e símbolos, além de busca em todo o projeto
- Traz embutidos vários recursos de conveniência, como fechamento automático de parênteses, integração com surround e personalização de temas
- Estrutura com muitos recursos básicos integrados mesmo sem plugins adicionais
Perguntas frequentes
- A expressão “pós-moderno” é uma brincadeira: se o Neovim é o “Vim moderno”, o Helix seria a geração seguinte
- O frontend GUI está planejado para o futuro como um protótipo baseado em WebGPU
- No momento, o sistema de plugins ainda não foi implementado, mas há planos para adicioná-lo no futuro
- Em relação ao Kakoune, o diferencial do Helix é ter mais recursos integrados e usar análise de código baseada em Tree-sitter
- Diferentemente do Vim, o Helix foi projetado do zero, tem uma base de código pequena e oferece padrões modernos com ajuste mínimo de arquivos de configuração
Comunidade e participação
- É possível contribuir com código no GitHub
- As discussões do projeto acontecem no canal Matrix
- É possível apoiar o desenvolvimento via OpenCollective
1 comentários
Comentários do Hacker News
Fiquei interessado ao ver a piada com “Post-modern?!”
Muitos engenheiros entendem “postmodern” simplesmente como a etapa seguinte de modern, mas isso é diferente do significado original nas artes e humanidades.
Claro, esse uso não é um grande problema, mas ainda assim chamou atenção porque eu esperava uma criatividade realmente “pós-moderna”.
Mas, como “postmodernism” originalmente é um conceito que surgiu como reação ao modernismo, acho que interpretar como apenas “depois do modern” também não está totalmente errado.
Só que, com o tempo, o significado ficou muito mais complexo, e hoje é até engraçado como isso soa tipo “dated af”.
“Helix, o primeiro editor que não acredita em grandes narrativas. Helix, o editor relativista. Helix, agora com as atualizações mais recentes de Foucault e Derrida.”
Uso o Helix como editor principal há alguns anos (Sublime → Atom → Vim → Helix).
A maioria dos LSPs funciona quase sem configuração, e o arquivo de configuração também é muito mais enxuto que o antigo .vimrc.
Levei só alguns dias para mudar a memória muscular do Vim, mas ainda tenho sentimentos mistos em relação a editores modais.
Ainda estou esperando por suporte a code folding.
No Emacs, dá para usar multiple cursors e plugins baseados em treesitter para ter uma edição poderosa mesmo sem modo modal.
Será que o incômodo com o modo modal do Helix vem de algo parecido?
Nos teclados Unix antigos ela ficava perto da home row, mas hoje está longe demais.
A maioria dos tutoriais nem menciona teclas alternativas, então ainda não entendo como mais da metade dos usuários continua usando Escape do jeito padrão.
Testei o Helix de novo há alguns dias, e tudo bem usar IA só via LSP,
mas o fato de não recarregar automaticamente quando arquivos mudam externamente foi muito incômodo.
Fiquei o tempo todo preocupado se o arquivo modificado pela IA estava realmente atualizado.
Esse modelo é muito mais estável e atraente.
Já algumas ferramentas de IA insistem que “não precisa de IDE” e focam em CLI, e eu acho isso uma bobagem completa.
:reloade:reload-all.Eu deixo o reload-all mapeado em
Ctrl-r.Outra opção é o mux, que permite comentar alterações sugeridas por LLM em nível de linha e bloco (ainda está no começo).
Quando trabalho com Claude Code, gosto que os arquivos não mudem sozinhos.
Vim é C, Helix é C++, e Ki Editor parece Rust.
O Helix herdou muitas ideias do Vim, mas falta consistência nos atalhos de teclado e também força nas composições conceituais.
Por exemplo, nos buffers você navega com
k, mas no explorador de arquivos precisa usarctrl+n.kprecisa ser tratado como caractere digitado, então é necessário usar outra tecla.Imagino que no Helix seja pelo mesmo motivo.
Fico pensando no que acontece ao acessar por SSH com layouts de teclado diferentes.
Eu realmente queria gostar do Helix.
A configuração padrão é boa, e abandonei hábitos do Vim de propósito para aprender,
mas no fim cheguei à conclusão de que os atalhos são compromissos feitos para simplificar a implementação.
Agora voltei para Neovim em mudanças pequenas e Zed (modo vim) em trabalhos maiores.
Por exemplo, ao reabrir um arquivo ele não volta para a posição anterior do cursor.
Até deu para ajustar isso com LLM, mas no fim eu não queria manter um fork do Helix.
É muito difícil abandonar a memória muscular acumulada por anos.
Para mim, a combinação hx + Zed funciona muito bem.
Como o Helix não suporta atualização de arquivo em tempo real, ele é desconfortável para usar junto com agentes de código.
Recomendo olhar a segunda pergunta do FAQ do Helix.
Fiquei impressionado porque o LSP de Python funciona de imediato, sem configuração.
Mas, por causa de 25 anos de memória muscular no Vim, as diferenças sutis do Helix me confundem demais.
No fim, o problema não é o Helix, e sim minha memória muscular.
Acho que com Vim e Helix pode acontecer o mesmo.
M-ESC ESCpara um comando inofensivo, dá para evitar o problema de a janela fechar.Exemplo:
(global-set-key (kbd "M-ESC ESC") 'keyboard-quit)Depois que você se acostuma com diferenças como
ddeG, ele vai ficando cada vez melhor.Tenho usado o Helix como editor padrão nos últimos anos.
Gosto especialmente da simplicidade, velocidade, navegação centrada no teclado e integração com o LSP de Elixir.
Uso o Helix como principal e já deployei muito código com ele.
Meu arquivo de configuração tem menos de 50 linhas, e só acrescentei algumas teclas do Vim.
Alternar entre Vim e Helix não me causa grandes problemas.
Minha configuração está aqui.
Eu mesmo criei uma extensão de modo modal direto no VS Code, e achei interessante a abordagem do Kakoune e do Helix.
A estrutura de “mostrar antes o que vai ser alterado” e o design centrado em múltiplos cursores me pareceram sensatos.
Mas, depois de algumas semanas, no fim voltei ao estilo clássico do Vim.
O esquema de múltiplos cursores só era útil quando dava para ver todas as mudanças na tela.
Hoje em dia, com IA, escrevo mais texto corrido do que código, então sinto que o valor desse estilo de edição diminuiu.
mc-hide-unmatched-lines, que permite mostrar só as linhas com cursor.Múltiplos cursores são bons para edições curtas e simples, mas para mudanças complexas ferramentas de edição em lote são mais eficientes.