Impressões após migrar do Vim para o Helix

• Um desenvolvedor que usou Vim por 20 anos compartilha sua experiência após migrar para o editor Helix e usá-lo por 3 meses
• O Helix é atraente por oferecer suporte nativo a Language Server Protocol (LSP) sem necessidade de configuração complexa
• Em especial, em comparação com Vim/Neovim, a busca e o suporte a múltiplos cursores são melhores, facilitando entender o contexto em vários arquivos e fazer edições em lote
• Ao pressionar teclas, um popup de referência rápida (quick reference) ajuda a lembrar atalhos e usá-los sem esquecer
• Há alguns incômodos, como falta de geração automática de listas em Markdown, ausência de undo persistente e travamentos cerca de uma vez por semana, mas no geral a experiência foi satisfatória
• Reaprender a memória muscular acumulada em 20 anos de Vim foi mais fácil do que o esperado, e em vez de tentar forçar o modo do Vim, foi muito mais eficaz aprender o “jeito Helix”

---

Por que migrar para o Helix

• O motivo para começar a usar o Helix foi poder aproveitar com facilidade os recursos integrados de language server
  • No Vim/Neovim, configurar language servers era complicado, enquanto no Helix é possível usar imediatamente recursos como ir para definição e renomear símbolos sem configuração adicional
  • Antes era preciso manter inúmeros plugins e arquivos de configuração, mas com o suporte nativo do Helix essa carga diminui

Principais vantagens do Helix

• Qualidade do sistema de busca
  • Ao buscar uma string em todo o repositório, os resultados aparecem em uma janela de preview, permitindo rolar pelos arquivos correspondentes e ver também o código ao redor
  • Diferente do plugin ripgrep no Vim, os resultados trazem muito mais contexto, o que permite decidir mais rápido
• Referência rápida de atalhos
  • Ao pressionar a tecla g, uma janela de ajuda mostra a lista de comandos de navegação disponíveis, de forma intuitiva
  • Mesmo atalhos menos usados podem ser consultados facilmente, o que torna a curva de aprendizado mais suave

Diferenças entre Vim e Helix

• Em vez do recurso de marks com ma e 'a, o histórico de movimento do cursor é acompanhado com Ctrl+O e Ctrl+I
• Em vez de macros, o uso principal é de edição com múltiplos cursores
  • Em mudanças em lote dentro de um documento, usa-se % para selecionar tudo → s para selecionar por regex → executar a edição múltipla necessária
  • Múltiplos cursores são muito mais práticos do que escrever macros o tempo todo
• Em vez de abas, usa-se space + b para abrir o alternador de buffers e trocar rapidamente

Pontos incômodos do Helix

• O recurso de reflow de texto é menos eficaz do que o gq do Vim
  • A compatibilidade com listas deixa a desejar
• Não há suporte à geração automática de listas em Markdown
  • Mesmo pressionando "Enter" no fim de um item de lista, a lista não continua
  • Há uma solução parcial para listas com marcadores, mas não para listas numeradas
• O recurso de undo persistente ainda não foi implementado
  • No Vim, com undofile, era possível desfazer mudanças mesmo após fechar o editor, mas o Helix ainda não oferece isso
• Não há suporte a reload automático de arquivos
  • Depois que um arquivo é alterado no disco, é preciso executar manualmente :reload-all (:ra<tab>)
• Travamentos ocasionais
  • Cerca de uma vez por semana, possivelmente relacionados a muita edição de Markdown
  • Como basta reabrir, isso não chega a ser um grande problema
• Ainda assim, o autor continua usando o Helix

Processo de migração e aprendizado

• Havia a preocupação de que reaprender a memória muscular acumulada em 20 anos de Vim seria muito difícil
• Durante as férias, o autor começou a usar o Helix em um projeto paralelo e, depois de 1 a 2 semanas, já não parecia mais confuso
• No começo, tentou forçar keybindings parecidos com os do Vim, mas isso não funcionou, e aprender o “jeito Helix” foi muito mais fácil
• Ainda existem pontos confusos
  • O w do Vim e o w do Helix têm definições diferentes de "palavra" (no Helix inclui o espaço após a palavra; no Vim, não)

Ambiente de edição baseado em terminal

• Como por muitos anos o uso principal foi da versão GUI do vim/neovim, usar o editor no terminal exigiu alguma adaptação
• Fluxo de trabalho adotado no fim
  • Uma janela de terminal separada para cada projeto, com todas as abas daquela janela compartilhando o mesmo diretório de trabalho
  • A aba do Helix fica como a primeira aba da janela do terminal
• Isso torna mais conveniente lidar com vários projetos em paralelo e pode até ser melhor do que o fluxo de trabalho anterior

Configuração

• Em comparação com a configuração do Neovim, que tinha centenas de linhas, foi mantida uma configuração muito simples
  • Basicamente, apenas 4 atalhos de teclado foram configurados
• Principais itens da configuração
  • Tema: solarized_light
  • O registrador padrão de yank foi definido como + para sincronizar com a área de transferência do sistema
  • # foi configurado como atalho para alternar comentário (o padrão Ctrl+C não agradava)
  • ^ e $ foram remapeados para ir ao início/fim da linha (não havia vontade de aprender outro jeito)
  • <space>l foi definido como :reflow (como o autor escreve muito texto, precisa fazer reflow com frequência e sentia falta do atalho gq do Vim)
• Um arquivo de configuração separado, languages.toml, define preferências por linguagem
  • No caso de Python: formatter black, language server pyright e formatação automática desativada

Conclusão: impressões após 3 meses

• Três meses não é tanto tempo, e ainda existe a possibilidade de voltar para o Vim algum dia
  • No passado, já houve uma migração para nix e um retorno ao Homebrew 8 meses depois (embora um servidor ainda seja administrado com NixOS, com satisfação)
• O Helix ainda não está completo, mas a direção de um “editor sem configuração” é clara
• Graças à simplicidade e aos recursos embutidos, há potencial para substituir o Vim no longo prazo
• Ainda assim, a continuidade desse uso vai depender de melhorias de estabilidade e expansão de funcionalidades no futuro

[GN⁺]

Comentários no Hacker News

• O editor às vezes dá crash por segfault cerca de uma vez por semana, mas a pessoa não liga muito, numa abordagem curiosa de perda de dados do tipo “é só abrir de novo”; como o Helix não tem persistent undo, ao reabrir ele não volta ao estado anterior
  Usei Vim/Neovim por muito tempo, já fiz configurações próprias e também usei configurações prontas, e apesar de realmente gostar muito de Vim, acho muito atraente o fato de o Helix funcionar bem imediatamente sem precisar de nenhum trabalho de configuração
  Porém, a configuração do próprio Helix parece bastante primitiva, então fico pensando que, depois de alguns primeiros anos usando Vim, eu provavelmente já conseguiria reproduzir no Vim o ambiente que obtenho no Helix, e queria dizer que assim também não haveria mais inferno de configuração
  Gosto muito de como os pop-ups de ajuda indicam o caminho ou as combinações de teclas que devo usar; normalmente não uso com frequência recursos como “ir para definição” ou “ir para referências”, então é fácil esquecer os atalhos; seria ótimo ver esse tipo de pop-up contextual sendo adotado mais amplamente, e seria realmente útil se aparecesse de forma inteligente só quando eu hesitasse ao digitar
  • Seria extremamente prático ter pop-ups de ajuda contextual em todos os apps quando se usam atalhos complexos, especialmente se eles aparecessem de forma inteligente apenas quando a digitação parar
    Usei Vim/Neovim por 20 anos, mas só uns 6 meses atrás instalei o plugin which-key e tenho achado muito útil
    which-key.nvim GitHub
  • Acho que o contexto do problema de configuração no Vim foi perdido
    Continuei tentando montar corretamente a configuração principal do language server, por exemplo para conseguir “ir para definição”, mas sempre senti que era difícil demais criar um ambiente confortável no Vim ou no Neovim
  • Concordo sobre reproduzir a configuração do Vim, mas é muito conveniente poder instalar o Helix direto num servidor e já sair usando
    Não tem o incômodo de levar junto a configuração do Vim e as dependências relacionadas; o ambiente de desenvolvimento parece bem mais portátil (embora mais básico do que uma configuração complexa de Vim)
  • Concordo 100% com o recurso de pop-up de ajuda; seria muito útil se esse tipo de função fosse aplicado em vários lugares
    Especialmente depois de ver a explicação relacionada e as capturas de tela naquele artigo, passei a desejar esse recurso com muita força
    Se o pop-up aparecer de forma inteligente com condições como timeout, ele não atrapalha quando não é necessário e ainda orienta automaticamente só nos momentos de hesitação, o que é excelente
  • Usei Helix quase todos os dias por 3 anos, e travar por segfault foi uma experiência raríssima, dá para contar nos dedos
• Fiquei completamente fã do Helix e uso em todo o meu desenvolvimento
  Antes eu usava principalmente neovim e VS Code, e o Helix preenche uma vantagem bem específica
  • design bonito (muito cuidado com os detalhes)
  • desempenho rápido (nunca tive a impressão de que fosse lento)
  • keybindings padrão ergonomicamente muito bem pensados
  • pronto para usar logo após a instalação, sem configuração
    Eu estava cansado de configurar o neovim ou de continuar usando vim, então precisava de algo no meio do caminho entre VS Code e nvim, e o Helix encaixa exatamente nisso
    Se eu fosse um mestre de vimscript, talvez pensasse diferente, mas como não sou, ele é perfeito para mim
    Espero que o Helix continue como está, sem precisar ser mais modular ou mais “UNIX-like”
    Já existe todo um ecossistema variado de ferramentas, e também dá para usar em conjunto com Claude Code (aplicando novas edições com refresh do buffer)
    É um dos melhores editores, então até comecei a apoiar o projeto mensalmente
    Se eu pudesse pedir uma evolução, o que mais faz falta é renderização de imagens ou fórmulas no editor; espero que isso possa ser implementado com plugins como o protocolo do terminal Kitty ou sixel
    Quero muito usar isso ao trabalhar com notas/blogs em arquivos Markdown
    Desejo tudo de bom ao Helix
  • Um app como o Helix, que funciona logo após a instalação, traz muita tranquilidade porque reduz a preocupação com supply chain attack
    VSCode e (neo)vim sempre me deixavam inseguro porque era preciso baixar plugins de vários lugares
  • Se a ideia é precisar de um meio-termo entre nvim e vscode, fica a dúvida se não bastaria usar o plugin de vim dentro do próprio vscode
  • Eu também gosto de helix, mas não vou abandonar nvim
    Não sou desenvolvedor Lua, mas os LLMs ajudam muito a configurar ou modificar a configuração do nvim
    O maior motivo para eu ter vindo para o helix foi o quanto a configuração de LSP/lint já vem muito bem resolvida
  • Em vez de “mestre de vimscript”, há a observação de que, na prática, para usar neovim hoje em dia você acaba tendo de usar Lua
• Tentei migrar do neovim para o helix por algumas semanas, mas registrei que ainda faltam recursos essenciais
  • ações automáticas de código ao salvar (por exemplo, adicionar imports no Go): PR #6486
  • busca difusa integrada ao seletor de arquivos, como telescope+rg: PR #11285
  • atualização automática do buffer quando o arquivo em disco é alterado: issue #1125
  • função de navegador em árvore de arquivos: introdução rejeitada como parte do sistema de plugins, ainda não implementada PR #5768 Fora isso, havia outras coisinhas suportáveis; pretendo tentar de novo daqui a 1 ou 2 anos
  • Uso Helix compilando com frequência a partir do HEAD via homebrew, então fiquei surpreso com a afirmação de que Julia trava com frequência
    Compartilho algumas coisas sobre recursos já mergeados no HEAD —

    ações de código ao salvar: dá para resolver com hooks no salvamento (funciona para Go), embora possa ser difícil aplicar a outras linguagens
    busca difusa: já existe embutida há bastante tempo e melhorou muito com uma reformulação recente
    atualização automática do buffer: é um recurso essencial para quem deixa o editor em segundo plano com frequência
    árvore de arquivos: no HEAD é possível navegar hierarquicamente com Space+e/E, algo adicionado relativamente há pouco tempo

  • O explorador de arquivos do link foi interrompido, mas um explorador no estilo vim-telescope foi incorporado ao Helix no começo deste ano
    Como já existe um seletor de arquivos embutido baseado em busca difusa, um explorador de arquivos tradicional não acrescenta tanta utilidade assim
  • Eu também tentei migrar do neovim para o helix, mas por causa da memória muscular de décadas com os comandos do vim, pequenos erros foram se acumulando e desisti rapidamente
    Também usei um plugin de keybindings do vim para Helix, mas como ele só combinava parcialmente, a frustração foi ainda maior
  • É uma pena que, quando programas externos (templ, sqlc etc.) modificam arquivos, o Helix não detecte e recarregue automaticamente
    Tenho curiosidade de saber como usuários experientes do Helix lidam com isso
• O motivo de eu ter ido para o Helix veio principalmente do processo de configurar language servers (LSP)
  Ajustar um ambiente confortável de language server no Vim/Neovim acabou virando trabalho demais, então acabei migrando para o Helix
  Porém, nos últimos 5 anos surgiram distribuições do Neovim no estilo “batteries included”, o que tornou a configuração bem fácil
  Concordo que muitos desenvolvedores não querem gastar tempo depurando editor, e acho que é por isso que a JetBrains é popular
  Ainda assim, é meio difícil acreditar que alguém com 20 anos de Neovim nunca tenha conseguido montar um ambiente LSP direito; isso faz parecer duvidoso se a experiência do autor é realmente sincera
  • Existe o caso de alguém que usou Vim por mais de 10 anos sem jamais configurar LSP
    No fim, até nisso usar uma IDE completa pareceu mais confortável, então sempre houve hesitação com instalação e configuração
  • Também uso vim → neovim há mais de 20 anos, mas quando o LSP quebra e os atalhos param de funcionar junto, surge uma barreira psicológica enorme para querer investigar a causa
    Acho o caso do autor bastante compreensível
  • Surpreendente; nem no vim original nem no neovim tive tanta dificuldade com configuração de LSP
    Eu também tendo a usar uma configuração mínima, mais barebones, e não achei difícil; Lua parece muito mais ergonômica do que vimscript
    Esse é um dos motivos para eu continuar usando ferramentas como ALE
    Espero que quem usa Helix também esteja feliz
  • Parece completamente estranho; a pergunta é se o LSP do neovim não está embutido há mais de dois anos
  • É perceptível como empresas de médio porte estão se padronizando no tooling do vscode
    Ainda dá para usar outros editores, mas quase toda depuração e configuração gira em torno do vscode, então há um clima de recomendação de uso
    A configuração de Neovim+treesitter+LSP já está bem fluida hoje em dia; mesmo que fosse difícil no passado, agora não é um grande problema
    Se a motivação para ir para o Helix foi LSP, isso parece estranho; talvez o problema real do autor nem seja exatamente o LSP
• O modelo noun-verb (objeto-ação) do Helix pareceu novo no começo, mas no uso percebi que verb-noun (ação-objeto) funciona muito melhor
  Uma desvantagem do modelo noun-verb é que ele impossibilita o comando de repetição (.)
  No Vim dá para repetir ações como dd.., dap.. etc., mas no modelo noun-verb isso é difícil
  Mais fundamentalmente, há um problema de falta de teclas disponíveis
  Muitas operações básicas acabam exigindo a tecla Alt, e não há modos normal/visual/insert como no vim, apenas visual/insert
  Nem mesmo a distinção entre motion/objeto é muito clara, o que aumenta a dificuldade de mapeamento de teclas e gera escassez de teclas
  • O modelo verb-noun muda até a forma de pensar
    Na prática, dá a sensação de combinar melhor com o raciocínio necessário ao escrever código
• A melhor mudança recente no nvim é o mini.nvim
  É uma coleção de plugins feita por echasnovski, cobrindo várias necessidades com consistência e boa documentação
  A partir do nvim 0.12 (nightly), basta instalar mini.nvim e lspconfig com o gerenciador de plugins embutido (vim.pack)
  • Para quem tiver curiosidade sobre o mini.nvim
    site oficial do mini.nvim
    repositório GitHub do mini.nvim
• Não consigo parar de admirar o quanto é libertador abandonar por completo ferramentas “avançadas” de editor como LSP
  Uso neovim sem plugins, sem autocompletar e até sem destaque de sintaxe
  Tenho a sensação de que a autodisciplina desse jeito me faz escrever código melhor
  Talvez não sirva para todo mundo, mas recomendo experimentar pelo menos uma vez
  • Há a opinião de que viver sem plugins ou autocompletar tudo bem, mas desligar até o destaque de sintaxe já parece sofrimento desnecessário
  • Eu também ainda não migrei completamente, mas no Emacs meu autocompletar está quebrado há um ano e nem sinto tanta falta
    Também não uso code actions nem goto definition, e embora às vezes faça falta ver erros em tempo real, como o compilador é muito rápido isso não faz tanta diferença
    Dá vontade de simplesmente desligar o LSP; acho que, comparado a 20 anos atrás, o LSP não elevou de forma tão dramática a minha habilidade de programar
    Quanto ao destaque de sintaxe, penso que temas coloridos demais mais atrapalham o foco do que ajudam, e que não têm muito significado
    Prefiro temas monocromáticos ou de duas cores, e sinto que nem preciso diferenciar por cor nomes de variáveis e funções
  • Ouvi dizer que Mitchell Hashimoto trabalha bem desse jeito, e isso me deu confiança de que dá para ser produtivo mesmo sem tooling moderno
    Ainda assim, fico na dúvida se não é cansativo ter de lembrar de tudo sozinho, ou se esse método realmente leva a código melhor
  • Eu também programo sem nenhuma ferramenta de apoio, mas sempre deixo o destaque de sintaxe ligado
    As cores são uma camada extra de informação que ajuda a notar melhor erros ou enganos no código e também a navegar mais rápido
  • Nos meus projetos pessoais adoto uma configuração minimalista desse tipo
    Sem ir a extremos demais, mantenho apenas o destaque de sintaxe e o feedback de erro de sintaxe via LSP
    Não uso autocompletar nem linkagem automática de documentação
• Se você quiser aprender Helix, recomendo a versão renovada da documentação criada por nic-revs
  helix-editor.vercel.app
  É bem mais fácil de ler do que a documentação oficial e tem muitas dicas e truques, então ajuda a amenizar desvantagens do Helix, como a ausência de terminal embutido, além de ensinar edição eficiente e keybindings
  • Sempre achei a legibilidade da documentação oficial frustrante, então essa informação é realmente valiosa
• Os recursos extras excessivos das distribuições de Neovim realmente incomodam
  Para usuários antigos de vim, recomendo o kickstart (especialmente o fork modular kickstart-modular.nvim)
  kickstart.nvim
  É excelente como ponto de partida bem minimalista
  • A vantagem do kickstart é que toda a configuração fica em um único arquivo
    Só que ele é grande, então eu o gerencio de forma mais fácil dobrando seções com fold markers

[qdr7h]

Às vezes me interesso pelo helix por causa da praticidade do LSP, das configurações de plugins etc., mas minhas mãos já estão acostumadas demais ao vi/vim, então não é fácil.