Helix Editor 25.07

 (helix-editor.com)
1 pontos por GN⁺ 2025-07-17 | 1 comentários | Compartilhar no WhatsApp
  • O Helix 25.07 inclui a substituição de componentes centrais e a adição de vários novos recursos
  • A usabilidade e o fluxo de trabalho melhoraram bastante com explorador de arquivos, exibição de cores de documentos via LSP e melhorias no modo de comando
  • Um novo crate, Tree-house, foi introduzido para destaque de sintaxe e otimização de queries
  • O Tree-house reforça significativamente os recursos de injeção e processamento local, além de desempenho e manutenibilidade
  • A base para futuras melhorias em uma experiência multilíngue mais ampla e mais rápida foi estabelecida

Principais atualizações do Helix 25.07

A versão Helix 25.07 traz uma substituição de funcionalidade central aguardada há muito tempo e a adição de diversos novos recursos. Nesta versão, 195 contribuidores participaram. O Helix é um editor de texto modal com múltiplas seleções, LSP, Tree-sitter e suporte experimental a DAP.

Novos recursos principais

Explorador de arquivos

  • Na 25.07, foi adicionado o recurso de explorador de arquivos, acessível com <space>e
  • Esse explorador oferece uma interface semelhante ao telescope
  • Ele facilita a navegação por estruturas hierárquicas dentro de diretórios e permite um controle mais preciso ao explorar projetos grandes

Exibição de cores de documento via LSP

  • Agora o Helix solicita ao servidor LSP informações de cor do documento para mostrar intervalos RGB inline
  • Por exemplo, ele recebe cores de servidores como tailwindcss-language-server e vscode-css-language-server, permitindo verificar visualmente caixas de cor diretamente no código

Melhorias no modo de comando (:)

  • Uma reescrita completa do código de parsing de comandos e autocompletar corrigiu bugs e aumentou a usabilidade
  • Foi adicionado suporte a flags para comandos da família :write, como a flag --no-format
  • Foram introduzidos expansão de variáveis/valores em comandos (%{variable_name}, %sh{명령어} etc.) e autocompletar
  • A estrutura foi alterada para um parser extensível, facilitando futuras expansões de comandos ao lidar com valores de entrada complexos

Tree-house: nova arquitetura para integração com Tree-sitter

O que é Tree-sitter

  • Tree-sitter é um framework para gerar e usar parsers rápidos e resistentes a erros
  • Regras de parser são escritas em uma DSL de gramática, e a árvore sintática é gerada e usada dentro de editores e ferramentas
  • Por exemplo, ele é usado na navegação e no destaque de código do GitHub, em verificação ortográfica em servidores de código, em ferramentas de diff e mais
  • Queries do Tree-sitter são usadas para correspondência de padrões em subárvores e captura de nós sintáticos

Integração anterior do Helix com Tree-sitter e seus problemas

  • No início, o Helix usava o binding oficial em Rust (o crate tree-sitter) e o highlighter tree-sitter-highlight
  • O tree-sitter-highlight é não incremental, então precisava sempre refazer o parse do documento inteiro, causando queda de desempenho e desperdício de recursos
  • O Helix chegou a fazer um fork próprio do highlighter para melhorar isso, mas ele foi ficando cada vez mais complexo e difícil de manter

Adoção do Tree-house e seus benefícios

  • O Tree-house prioriza uma estrutura separada de parsing e queries, código limpo, fim de bugs antigos e uma arquitetura voltada para o futuro, como parsing em paralelo
  • Seu principal ponto forte é o tratamento robusto de injeção (Injection)

Injeção (Injection): suporte a múltiplas linguagens e camadas

  • Injeção é, por exemplo, quando aparece um bloco de código Rust dentro de Markdown e apenas aquele trecho é parseado separadamente como Rust
  • Casos complexos, como Markdown dentro de comentários em Rust e Rust novamente dentro de blocos de código desse Markdown, também são suportados com precisão ao gerenciar camadas em uma estrutura em árvore

Injeção incremental

  • Apenas as camadas onde realmente houve mudança são rapidamente reparseadas e têm suas queries executadas, usando apenas a menor unidade de trabalho necessária
  • Isso maximiza a eficiência em documentos Markdown com listas muito grandes ou estruturas aninhadas

Destaque de variáveis locais (locals)

  • Variáveis locais, como parâmetros dentro de funções, são destacadas corretamente nos escopos de declaração e referência
  • O Tree-house resolve um problema antigo em que o destaque desaparecia quando a definição estava fora da área visível

Suporte a injeção globalizado

  • No tipo Syntax, passou a ser possível buscar e consultar camadas de injeção em tempo logarítmico
  • APIs como TreeCursor e QueryIter agora podem aplicar-se a todas as camadas de injeção
  • Isso estabelece a base para um comportamento consistente entre fronteiras de linguagem, como código dentro de <script> em HTML ou blocos de código em Markdown

Encerramento

  • O Helix 25.07 se destaca como um forte candidato a editor de texto da próxima geração, combinando uma revolução de usabilidade com explorador de arquivos, inlay de cores e melhorias no modo de comando/parser, além da nova arquitetura baseada em Tree-house
  • Os detalhes completos da atualização podem ser consultados no changelog
  • A participação na comunidade e em contribuições pode ser feita por meio do Matrix e do repositório no GitHub

Leituras relacionadas

1 comentários

 
GN⁺ 2025-07-17
Comentários no Hacker News

  • Helix é realmente excelente: seletor de arquivos, realce de sintaxe, linting e muitos outros recursos já vêm prontos, sem precisar instalar plugins nem fazer configurações complicadas, enquanto no vim ou no neovim normalmente é preciso configurar bastante coisa desde o início. Eu queria usar, mas a principal desvantagem para mim é que os atalhos de teclado funcionam de forma diferente do vim. Estou acostumado com coisas como x apagar o caractere sob o cursor ou d esperar uma ação em seguida; quando esses comportamentos familiares do vim, que uso há tanto tempo, não estão ali do mesmo jeito, fico confuso e irritado. Acho que muitos usuários de vim sentem algo parecido nesse ponto, e mudar hábitos é muito difícil, especialmente porque o vim está disponível por padrão em praticamente todo lugar, então é difícil escapar desse ambiente. Felizmente existe um soft fork do Helix chamado evil-helix, que adiciona atalhos do Vim, e eu gostaria de recomendá-lo para quem passa pelo mesmo incômodo que eu. Além disso, tanto o Helix quanto o evil-helix funcionam bem no Windows (cmd) só baixando o .exe, sem precisar instalar Rust.

    • Para mim, não é que eu não queira aprender algo novo; o problema é que não dá para usar esses atalhos em outros lugares. Quase todo editor online e workstation oferece atalhos do vim, e quando você entra por ssh em uma máquina Linux, é importante saber que sempre vai ter vim lá. É como teclado QWERTY: mesmo que existam layouts melhores, é difícil abrir mão da flexibilidade de se adaptar imediatamente a quase qualquer ambiente.

    • Não tenho problema nenhum em aprender ferramentas novas. Usei Helix o suficiente, mas o modelo substantivo-verbo me pareceu pior, e o feedback visual também acabou sendo mais uma distração na hora de ler código. No vim, coisas simples como repetir o último comando (. e afins) são práticas, mas no Helix isso acaba se perdendo. O gerenciamento de estado também exige mais atenção do que no vim: no vim basta cuidar da posição atual no arquivo, mas no Helix também preciso considerar onde eu estava antes. Eu quero um editor com configuração padrão, edição modal e que não me force mais sincronização visual do que o necessário. Quando há sincronização demais, ele perde as vantagens como linguagem de edição. Quero me concentrar em programar, que é mais interessante do que o ato de editar em si. Um editor que exige mais atenção acaba sendo, na prática, um editor pior.

    • Depois de usar vim (neovim) por quase 20 anos, migrar para o Helix não foi nada difícil, e hoje eu prefiro muito mais. Ajustei alguns comportamentos modais, mas continuo usando dentro da lógica do Helix. Recursos como seleção múltipla e LSP já vêm embutidos, e a ajuda poderosa que mostra dicas das ações possíveis durante entradas em múltiplas etapas é uma grande vantagem. Mesmo quando às vezes preciso usar vim puro, ainda lembro dos comandos básicos, então consigo me readaptar rápido, mesmo com alguns mapeamentos mentais já diferentes.

    • O Helix está adicionando Scheme para configuração programável neste momento. Quando esses recursos programáveis entrarem, deve ficar possível fazer vários ajustes finos que hoje existem no emacs, como repeat/transient map, rastreamento por estado e assim por diante. Num mundo em que, graças à revolução dos LLMs, ficou fácil até mexer na 8ª ou 9ª linguagem, acho que ferramentas com configuração detalhada vão ganhar mais espaço no mercado.

    • Os atalhos do vim eram o único motivo para eu não usar Helix. Se é possível ter suporte a vim por meio de um fork externo, então a equipe oficial do Helix também poderia oferecer isso se quisesse; às vezes penso se eles evitam isso de propósito.

  • Gosto muito do Helix. Recomendo fortemente para quem nunca se deu bem com vim ou para quem gosta do conceito do vim, mas teve dificuldade para se adaptar. Foi muito mais fácil de aprender e usar do que editores da família vim, e a configuração padrão já é muito prática.

    • Gosto muito do Helix. Sinceramente, se ele tivesse um pouco mais de conveniência de GUI, como um explorador de arquivos baseado em mouse, acho que teria força de sobra para competir com o VS Code.

  • É bom ver que um editor com capacidades tão impressionantes ainda continua minimalista e não está focado em recursos inúteis de IA.

  • Parabéns, espero que o Helix se dê bem, mas sinto que ele não é para mim. Eu uso Neovim e consigo fazer quase tudo o que quero, embora também não esteja completamente satisfeito. O editor que eu quero teria as seguintes características:

    • codebase moderna, totalmente reescrita
    • atalhos do Vim; essa memória muscular é muito forte, então insisto no estilo Vim, não me importo se dizem que há algo melhor, quero que funcione exatamente como o Vim
    • bons padrões; o Neovim exige configuração demais e os padrões nem sempre me agradam
    • baseado em Treesitter; seria ainda melhor se rodasse sobre WASM (como Zed e o Neovim mais recente)
    • sistema de extensões em Lua; não gosto muito de JS nem Scheme, e o ideal seria expor apenas funções essenciais por meio de módulos WASM; gostaria de uma linguagem de configuração não Turing-completa para configurar plugins
    • TUI e GUI opcional
    • LSP, DAP, snippets, autocompletar e UI de teste/debug embutidos
    • visualização de sistema de arquivos embutida, como o Oil.nvim
    • busca embutida no estilo Telescope/FZF-lua
    • integração com git, e uma UI de git como magit/neogit também seria bem-vinda
    • manipulação de AST baseada em Treesitter e saltos por rótulo no estilo Flash.nvim embutidos
    • macros e multicursor
    • integração opcional de IA baseada em cursor (UI de chat)

    • Eu também reconheço a memória muscular do Vim, mas acho que muita gente fica obcecada demais com isso. Já troquei de OS, editor e IDE várias vezes, e nos primeiros dias de mudança sempre bate uma frustração enorme, dá raiva e dá até vontade de largar tudo, mas depois desse período sempre nasce uma nova memória muscular. Acho uma pena abrir mão de tantas outras vantagens de um software por causa de alguns dias de desconforto.

    • Não está claro para mim em que exatamente o Helix não atende aos requisitos citados. Aos meus olhos, parece que o Helix cumpre quase tudo.

    • Olhando para essa lista, no fim das contas parece que você quer apenas um Neovim em que Lua seja trocada por outra linguagem.

  • Adoro o Helix, parabéns. O tema padrão é bonito, a configuração padrão é excelente, você instala e já sai usando sem precisar ajustar praticamente nada. Ainda não substituiu completamente minha IDE, mas coloquei um alias de vi e também defini $EDITOR como Helix. Quando preciso fazer uma edição rápida ou depurar algo pela CLI, acabo sempre usando Helix.

  • Eu realmente gostava muito do Helix e tinha bastante simpatia por ele, mas o comportamento de undo me pareceu pouco lógico e antinatural, como desfazer coisas demais de uma vez. Isso inclusive já me fez perder trabalho de verdade.

    • Houve duas coisas no undo que me incomodaram:

      • ao desfazer, se a edição não está visível na tela, ele pula corretamente para aquela área, mas já executa o undo no mesmo pressionamento de tecla, o que confunde. Em outros editores, quando o conteúdo não está visível, ele apenas navega até lá e não desfaz ainda. No Helix, você precisa sempre conferir se algo mudou de fato depois de apertar uma vez.
      • o undo acontece em blocos grandes demais. Mesmo que eu passe 30 minutos digitando no modo de inserção, tudo é desfeito de uma vez só quando saio do modo. É preciso registrar save points manualmente, e eu tentei mapear isso na barra de espaço para ter um undo mais granular, mas isso trouxe efeitos colaterais, como perder a seleção. Não encontrei uma solução limpa. Continuo satisfeito com o Helix em si, mas é realmente frustrante que a profundidade do undo exija intervenção manual.

    • O undo e a "repetição do último comando" são um pouco estranhos mesmo, mas o restante dos recursos é tão bom que continuo usando Helix como editor principal. Mas sobre a parte de perder trabalho: não dava para refazer depois com redo?

  • Espero que exista um "modo Kakoune" no Helix. Como uso Windows no trabalho, Kakoune não é a melhor opção, então Helix parecia perfeito, mas é difícil superar a questão dos atalhos. A filosofia de atalhos do Helix me incomoda por ser mais verbosa do que a concisão do Kakoune. Além disso, a configuração de atalhos do Helix não é poderosa o suficiente para reproduzir Kakoune de verdade, o que é uma pena. Fiquei decepcionado com as inconsistências e o comportamento pouco lógico do vim, então migrei para Kakoune, e sinto que o Helix representa um passo para trás nesse aspecto.

  • Esse termo "editor pós-moderno" é engraçado. Acho que é a segunda melhor piada desde o slogan do shell Fish, "the shell for the 90s". Pelo vídeo, achei marcante ele ser baseado em TUI, e ainda passa um pouco de sensação de Emacs TUI.

  • Realmente precisamos de um editor estilo vim com o nível de completude all-in-one do Helix. As distribuições de Neovim têm componentes unidos de forma frouxa demais, então sempre fica algum incômodo sutil aqui e ali. Também acho que a interface do Vim como um todo precisa ser redesenhada, mas gostaria que o modo modal baseado em ação-objeto fosse mantido.

    • O Evil-Helix parece corresponder a esse tipo de necessidade. Ainda parece meio bruto em vários pontos, mas vale dar uma olhada: https://github.com/usagi-flow/evil-helix

    • Fiquei curioso sobre o que seria exatamente esse modo modal de ação-objeto.

  • Fiquei impressionado com a explicação detalhada sobre realce de sintaxe e os recursos de compreensão de código do Helix e de editores semelhantes. A estrutura e os recursos baseados em tree-sitter parecem combinar perfeitamente com uma linguagem de consulta, e me deu a sensação de que seria possível ir além de busca de símbolos ou encontrar referências, chegando a uma DSL de consulta de propósito geral. Fiquei curioso se algo assim já existe.