Ki Editor - um editor baseado em AST

 (ki-editor.org)
2 pontos por GN⁺ 2026-03-08 | 1 comentários | Compartilhar no WhatsApp
  • Um editor estrutural baseado em múltiplos cursores que permite manipular diretamente a estrutura do código, funcionando em torno da árvore sintática (AST)
  • Oferece interação no nível de nós de sintaxe, reduzindo a distância entre a intenção ao escrever código e a ação real de edição
  • Com o recurso de múltiplos cursores, é possível modificar ou refatorar vários nós de sintaxe ao mesmo tempo, aumentando a eficiência em edições em massa
  • Redefine a edição modal, permitindo mover-se de forma consistente entre diferentes unidades, como palavras, linhas e nós de sintaxe
  • Reforça a precisão e a consistência na edição de código, propondo um novo paradigma de edição que aumenta a produtividade do desenvolvedor

Visão geral do Ki Editor

  • O Ki Editor é um editor estrutural com múltiplos cursores (Multi-cursor structural editor) que oferece um ambiente de edição voltado a lidar diretamente com a estrutura sintática do código
  • Diferentemente da edição tradicional baseada em texto, ele manipula elementos do código com base na árvore sintática (AST)
  • Permite edição direta no nível de nós de sintaxe sem depender de mouse ou combinações de teclado

Interação com nós de sintaxe

  • Por meio do recurso First-class syntax node interaction, lida diretamente com a estrutura sintática do código
    • O foco está em reduzir a distância entre a intenção ao escrever código e a ação real de edição
    • Executa manipulação em nível sintático sem movimento de mouse ou entradas complexas de teclado

Recurso de múltiplos cursores

  • Com Multiple cursors, é possível editar vários nós de sintaxe simultaneamente
    • A manipulação paralela de nós de sintaxe melhora a eficiência em edições em massa e refatoração
    • Permite processar rapidamente tarefas repetitivas de modificação de código

Redefinição da edição modal

  • Com o recurso Redefine modal editing, o modo de seleção é padronizado
    • Dá suporte, de forma consistente, ao deslocamento entre diferentes unidades, como palavras, linhas e nós de sintaxe
    • Reforça a flexibilidade e a consistência em relação à edição modal tradicional

Significado

  • O Ki Editor oferece uma experiência de edição centrada na estrutura sintática, aumentando a precisão ao escrever e modificar código
  • Ao combinar múltiplos cursores com manipulação de nós de sintaxe, apresenta uma nova abordagem de edição de código que contribui para o aumento da produtividade do desenvolvedor

Leituras relacionadas

1 comentários

 
GN⁺ 2026-03-08
Comentários do Hacker News

  • Ao ver o recurso de "seleção sintática de primeira classe", lembrei do atalho Expand / Shrink Selection que uso com frequência nas IDEs da JetBrains
    Com Ctrl + W e Ctrl + Shift + W, dá para expandir ou reduzir a seleção por unidades sintáticas
    Esse recurso mudou completamente minha forma de pensar sobre como interagir com o "texto" de um arquivo
    O VS Code e o Zed também têm algo parecido, mas a sensação é de que a expansão/redução é bruta demais
    Link para a documentação da JetBrains

    • Os atalhos da JetBrains que eu mais uso são os seguintes
      Com Cmd+Shift+V, abro a pilha da área de transferência para pesquisar ou escolher algo copiado anteriormente
      Cmd+Shift+E mostra a lista de locais recentes, e Cmd+Shift+A abre a paleta de ações para fazer busca difusa em todos os comandos
      Além disso, o recurso Local History permite rastrear o histórico de alterações de arquivos com muito mais granularidade do que o Git
      Esses recursos levam naturalmente à ideia de poder editar direto no buffer de resultados de busca
    • No Neovim, também dá para usar esse mesmo recurso com incremental selection baseado em tree-sitter
    • O Mathematica já oferecia expansão de seleção com Alt+. desde o começo dos anos 90
      Clique duplo selecionava uma palavra, clique triplo selecionava todos os argumentos da função, e quatro cliques selecionavam f(a,r,g,s) inteiro — uma estrutura em que a unidade sintática cresce conforme o número de cliques
      Até hoje essa memória muscular ficou comigo
    • Estou pesquisando controle de versão baseado em AST
      Estou experimentando a ideia de fazer commit, diff e cherry-pick também funcionarem em unidades sintáticas, como o Ctrl+W
      Há mais detalhes no projeto librdx
    • Também uso muito esse recurso no helix, mas a implementação do vscode não é boa
      Edição com reconhecimento de AST lembra a praticidade das linguagens da família Lisp
      Em Lisp, coisas que são possíveis com simples manipulação de listas exigem LSP ou um parser separado em JS
      Quando passo o fim de semana usando Clojure e volto para TypeScript, sinto muita falta dos comandos do paredit

  • Já cheguei a criar um editor baseado em árvore sintática
    Como ele manipulava apenas a árvore em vez de texto, não podia existir um programa sintaticamente incorreto
    Mas o grande desafio era transformar isso em uma forma de entrada realmente utilizável
    Hoje não consigo mais executá-lo por falta do hardware de display da época, mas deixei a descrição do projeto

    • O problema é a restrição de que “o caminho do programa A até B precisa sempre passar por programas válidos”
      Como resultado, às vezes é preciso seguir caminhos nada intuitivos, ou até reescrever tudo do zero
      É até possível haver estruturas válidas para as quais simplesmente não existe caminho de construção
    • Anos atrás, usei na empresa uma linguagem experimental e um editor baseados em JetBrains MPS
      Em teoria é interessante, mas me pareceu um beco sem saída pouco prático
      É difícil vencer a universalidade e simplicidade de uma interface baseada em texto
      Editor dedicado, novo sistema de versionamento, ruptura de ecossistema e outras limitações reais pesam demais
      Como as pessoas não pensam em termos de árvores, programar apenas em estados sempre sintaticamente corretos era uma experiência extremamente frustrante
      No fim, são as ferramentas que permitem uma rigidez flexível (por exemplo, a tipagem gradual do TypeScript) que acabam sobrevivendo
    • Se você quiser experimentar esses sistemas antigos de novo, dá para restaurar o ambiente VT11 com os emuladores simh e mame
      Veja simh, mame, código do VT11 e a documentação
    • Um projeto chamado Pantograph está tentando revisitar essa ideia de forma moderna
      Ainda não é um editor de uso geral, mas a direção de expandir o escopo de seleção da árvore parece promissora
      Link do Pantograph
    • Atualmente estou desenvolvendo um projeto sucessor chamado BABLR
      Ele é construído sobre um sistema de parser que lida com árvores válidas, porém incompletas
      Com uma representação de lacuna como <//>, é possível tratar sintaxe incompleta com segurança
      Ex.: 2 + · pode ser analisado como uma árvore <BinaryExpression>
      Se tiver interesse, estamos discutindo isso na comunidade do Discord

  • Não estou acostumado com edição de AST
    Uso no máximo objetos de texto para lidar com argumentos de função ou arglists
    Das funções de LSP, uso só ir para definição e renomear
    No fim, isso me dá vontade de melhorar mais minhas habilidades no editor

    • Nesse caso, ferramentas como ast-grep são úteis
      Você escreve padrões com uma sintaxe quase igual à do código e consegue ver a transformação na sua frente
      Por exemplo, ast-grep -pattern '$A && $A.$B' --rewrite '$A?.$B' -lang ts permite fazer uma transformação para optional chaining
      Metavariáveis como $X, $A etc. forçam a correspondência do mesmo nó
      Agentes de programação com IA ainda não usam bem esse tipo de padrão, mas a ferramenta em si é muito sólida
    • Na prática, nem é preciso entender profundamente a estrutura do AST
      Na maioria dos casos, basta selecionar por unidade sintática e então apagar, copiar ou substituir
    • Como o trabalho de cada pessoa é diferente, a necessidade de edição de AST também varia
      Eu não faço grandes refatorações com frequência, então não sinto tanta necessidade de aprender isso
      Mas para quem desenvolve serviços grandes, a opinião pode ser completamente diferente
    • Estou numa linha parecida
      Aprender a escrever macros em Elixir me trouxe muitos insights, e com Lisp é a mesma lógica
      As abordagens variam de linguagem para linguagem, mas no fim todas apontam para o mesmo destino

  • A classificação de editores que eu faço é a seguinte

    1. Ortodoxo (Orthodox) — foco em UI e integração
    2. Modal (melhoria do Vim) — mantém os keybindings existentes
    3. Modal (nova abordagem) — reinterpreta a filosofia do Vim
      O Ki entra na terceira categoria, e eu acompanho esse tipo de projeto de perto
    • Existe uma quarta categoria também — o Emacs que engloba tudo
    • Penso o mesmo. Houve muitos desafiantes, mas ainda sinto que o campeão continua sendo um só
    • Eu também estou desenvolvendo um editor modal de código baseado em AST
      Os nós da UI parecem texto comum, mas na prática são uma estrutura em árvore
      Se quiser dar feedback inicial, entre em contato pelo e-mail que está no meu perfil
    • Se a ideia é melhorar o Vim, acaba surgindo a piada de "Ed Visual Mode Improved Improved"

  • A dificuldade da edição de AST é a descoberta (discoverability)
    Está tudo visível na tela, mas muitas vezes você não sabe o nome daquele nó
    Por isso estou pensando em um plugin que pinte com cores os escopos ao redor do cursor para visualizá-los
    A ideia é pensar em termos de “ir para o próximo azul” em vez de “ir para a próxima função”

    • No Ki, mesmo sem saber o nome do nó, você pode apertar d m para mostrar os rótulos de todos os nós sintáticos visíveis e ir direto até eles
    • Ainda assim, seleção/contração em nível geral de AST continua valendo muito a pena
      Operações como selecionar a parte interna ou externa do nó atual são úteis

  • Eu criei uma integração do Ki para VSCode
    Depois não consegui contribuir tanto quanto queria, mas acho esse tipo de inovação em ferramentas fundamentais muito importante
    Link da extensão Ki para VSCode

    • Isso mesmo, é exatamente essa extensão
    • Testar um editor novo dá trabalho, e a extensão para VSCode reduz a barreira de entrada

  • Antes de ver os exemplos, eu não tinha entendido tão bem,
    mas em "modificação sintática de primeira classe" fiquei impressionado ao ver vírgulas sendo adicionadas e removidas automaticamente
    A lógica de implementação até parece ser simples
    Agora quero tentar fazer integração do Ki ou até rewrites baseados em AST no Zed

    • Eu criei a extensão do Ki para VSCode, e como ela usa uma estrutura de comunicação por WebSocket, deve ser fácil integrar também no Zed
      É só consultar o código no repositório do Ki

  • Pretendo testar em breve
    Gosto da ideia de ser independente de layout de teclado
    Também acho interessante a inspiração na filosofia do Emacs de que “tudo é um buffer editável”
    Claro que cada editor tem seus próprios trade-offs, então só testando para saber

    • Como o editor é estruturado em torno do modelo de edição, é uma pena que sempre seja preciso recriar tudo do zero
      O Neovim é excelente, mas o modelo de edição tem limites
      Se a estrutura fosse totalmente substituível, talvez Helix ou Ki nem fossem necessários
    • Mas para mim a independência de layout foi um pesadelo
      Quando executei com um teclado Dvorak, os mapeamentos quebraram completamente
      Quando o software acha que é mais inteligente que o usuário, o resultado é que o usuário se sente impotente

  • Claro, no Emacs isso já existe
    O pacote combobulate é um exemplo

    • Com o combobulate, dá para fazer navegação por AST tão natural quanto editar Lisp
      Você pode apagar nós com M-k ou pesquisar/editar diretamente com consultas tree-sitter
      A integração já é excelente, mas um editor dedicado a AST ainda teria espaço para evoluir bastante na UX

  • É um recurso que combina muito bem com o fluxo de trabalho do Helix
    Dá a sensação de que a peça final do padrão clássico de movimento → ação finalmente se encaixou