Ki Editor - AST tabanlı çalışan editör

 (ki-editor.org)
2 puan yazan GN⁺ 2026-03-08 | 1 yorum | WhatsApp'ta paylaş
  • Kod yapısını doğrudan manipüle edebilen, çoklu imleç tabanlı bir yapısal editör olup sözdizimi ağacı (AST) merkezli çalışır
  • Sözdizimi düğümü düzeyinde etkileşimi destekleyerek, kod yazma niyeti ile gerçek düzenleme davranışı arasındaki farkı azaltır
  • Çoklu imleç özelliği sayesinde birden fazla sözdizimi düğümünü aynı anda değiştirip refactor edebilir; böylece toplu düzenleme verimliliğini artırır
  • Mod tabanlı düzenleme yaklaşımını yeniden tanımlayarak, kelime, satır, sözdizimi düğümü gibi farklı birimler arasında tutarlı biçimde hareket etmeyi mümkün kılar
  • Kod düzenlemede doğruluk ve tutarlılığı güçlendirerek geliştirici üretkenliğini artıran yeni bir düzenleme paradigması sunar

Ki Editor genel bakış

  • Ki Editor, kodun sözdizimsel yapısını doğrudan ele alan bir düzenleme ortamı sunan çoklu imleçli yapısal editördür (Multi-cursor structural editor)
  • Geleneksel metin tabanlı düzenlemeden farklı olarak, kod öğelerini sözdizimi ağacı (AST) temelinde manipüle eder
  • Fare veya klavye kombinasyonları olmadan sözdizimi düğümü düzeyinde doğrudan düzenleme yapılabilir

Sözdizimi düğümü etkileşimi

  • First-class syntax node interaction özelliği sayesinde kodun sözdizimsel yapısı doğrudan ele alınır
    • Odak noktası, kod yazma niyeti ile gerçek düzenleme davranışı arasındaki farkı azaltmaktır
    • Fare hareketleri veya karmaşık tuş girişleri olmadan sözdizimi düzeyinde manipülasyon yapılır

Çoklu imleç özelliği

  • Multiple cursors kullanılarak birden fazla sözdizimi düğümü aynı anda düzenlenebilir
    • Paralel sözdizimi düğümü manipülasyonu ile toplu düzenleme ve refactor verimliliği artırılır
    • Tekrarlayan kod değişiklikleri hızlıca işlenir

Mod tabanlı düzenlemeyi yeniden tanımlama

  • Redefine modal editing özelliği ile seçim modu standartlaştırılır
    • Kelime, satır, sözdizimi düğümü gibi farklı birimler arasında tutarlı bir şekilde hareket etmeyi destekler
    • Mevcut mod tabanlı düzenlemeye kıyasla esneklik ve tutarlılık güçlendirilir

Önemi

  • Ki Editor, sözdizimsel yapı merkezli bir düzenleme deneyimi sunarak kod yazma ve düzenleme doğruluğunu artırır
  • Çoklu imleç ile sözdizimi düğümü manipülasyonunu birleştirerek geliştirici üretkenliğini artırmaya katkı sağlayan yeni bir kod düzenleme yaklaşımı ortaya koyar

İlgili okumalar

1 yorum

 
GN⁺ 2026-03-08
Hacker News görüşleri

  • “Birinci sınıf sözdizimsel seçim” özelliğini görünce JetBrains IDE’lerde sık kullandığım Expand / Shrink Selection kısayolu aklıma geldi
    Ctrl + W, Ctrl + Shift + W kombinasyonuyla seçim alanını sözdizim birimleri bazında genişletip daraltabiliyorsunuz
    Bu özellik sayesinde bir dosyanın ‘metni’ ile etkileşim kurma biçimime bakışım tamamen değişti
    VS Code ve Zed’de de benzer bir özellik var ama fazla kaba biçimde genişleyip/daralıyor gibi geliyor
    JetBrains doküman bağlantısı

    • Benim sık kullandığım JetBrains kısayolları şunlar
      Cmd+Shift+V ile yığın panosunu açıp geçmiş kopyalama kayıtlarını arayabiliyor ya da seçebiliyorsunuz
      Cmd+Shift+E son konumlar listesini gösteriyor, Cmd+Shift+A ise action palette’i açıp tüm komutlarda bulanık arama yapmanızı sağlıyor
      Ayrıca Local History özelliğiyle dosya değişiklik geçmişini Git’ten çok daha ayrıntılı şekilde takip edebiliyorsunuz
      Bu tür özellikler “arama sonucu tamponundan doğrudan düzenleme” fikrine uzanıyor
    • Neovim’de de tree-sitter tabanlı incremental selection ile aynı özelliği kullanabiliyorsunuz
    • Mathematica, 90’ların başından beri Alt+. ile seçim genişletme özelliği sunuyordu
      Çift tıklama bir kelimeyi, üç tıklama bir fonksiyonun tüm argümanlarını, 4 tıklama ise f(a,r,g,s) ifadesinin tamamını seçiyordu; yani tıklama sayısına göre sözdizimsel birim büyüyordu
      Hâlâ o kas hafızası duruyor
    • Ben AST tabanlı sürüm kontrolü araştırıyorum
      commit, diff ve cherry-pick işlemlerinde de Ctrl+W gibi sözdizim birimleriyle çalışan bir fikri deniyorum
      İlgili içerik librdx projesinde derlenmiş
    • helix’te de bu özelliği sık kullanıyorum ama vscode’daki uygulama pek iyi değil
      AST farkındalığı olan düzenleme, Lisp ailesi dillerin rahatlığını hatırlatıyor
      Lisp’te basit liste işlemleriyle yapılabilen şeyler için JS tarafında LSP ya da ayrı bir parser gerekiyor
      Hafta sonu Clojure kullanıp sonra TypeScript’e dönünce paredit komutlarını gerçekten özlüyorum

  • Eskiden sözdizim ağacı tabanlı bir düzenleyiciyi kendim yapmıştım
    Metin girmek yerine yalnızca ağaçla uğraştığınız için sözdizimsel olarak yanlış bir programın var olması mümkün değildi
    Ama bunu pratikte kullanılabilir bir giriş yöntemi hâline getirmek büyük bir zorluktu
    Şimdi o dönemki görüntüleme donanımım olmadığı için çalıştıramıyorum ama proje açıklamasını bıraktım

    • Sorun, “program A’dan B’ye giden yolun her zaman geçerli bir program olmak zorunda olması” kısıtı
      Bunun sonucunda sezgisel olmayan yollar izlemek ya da baştan yeniden yazmak gerekebiliyor
      Hatta geçerli olup da üretim yolu bulunmayan yapılar bile mümkün
    • Eskiden şirkette JetBrains MPS tabanlı deneysel bir dil ve düzenleyici kullanmıştık
      Teoride ilginç ama pratikte düşük kullanışlılığa sahip bir çıkmaz sokak gibi gelmişti
      Metin tabanlı arayüzlerin evrenselliğini ve sadeliğini aşmak zor
      Özel editör, yeni sürüm kontrolü, ekosistem kopukluğu gibi gerçek dünyadaki kısıtlar fazla büyük
      İnsanlar ağaç düzeyinde düşünmediği için sadece sözdizimsel olarak doğru durumlarda kod yazmak aşırı derecede bunaltıcı bir deneyimdi
      Sonunda esnek katılığa izin veren araçlar (ör. TypeScript’in kademeli tiplemesi) gerçekten hayatta kalıyor
    • Eski sistemi yeniden deneyimlemek isterseniz simh ve mame emülatörleriyle VT11 ortamını yeniden kurabilirsiniz
      İlgili kaynaklar için simh, mame, VT11 kodu, dokümantasyon
    • Pantograph adlı proje bu fikri modern biçimde yeniden deniyor
      Henüz genel amaçlı bir editör değil ama ağaç seçim aralığını genişletme yönü umut verici görünüyor
      Pantograph bağlantısı
    • Şu anda BABLR adlı bir devam projesi geliştiriyorum
      Eksik ama geçerli ağaçları ele alabilen bir parser sistemi üzerine kurulu
      <//> gibi boşluk temsilleri sayesinde eksik sözdizimini güvenli biçimde işleyebiliyor
      Örneğin 2 + ·, bir <BinaryExpression> ağacı olarak parse edilebiliyor
      İlgilenirseniz Discord topluluğunda bunu tartışıyoruz

  • AST düzenlemeye alışık değilim
    Sadece fonksiyon argümanları ya da arglist gibi text object’leri kullanıyorum
    LSP özelliklerinden de yalnızca tanıma gitme ve yeniden adlandırmayı kullanıyorum
    Sonuçta editör becerilerimi daha da geliştirmem gerektiği hissini verdi

    • Böyle durumlarda ast-grep gibi araçlar faydalı oluyor
      Kodla neredeyse aynı sözdizimiyle desen yazıp dönüşümü gözünüzün önünde görebiliyorsunuz
      Örneğin ast-grep -pattern '$A && $A.$B' --rewrite '$A?.$B' -lang ts gibi bir kullanım ile optional chaining dönüşümü yapılabiliyor
      $X, $A gibi metavariables aynı düğümün eşleşmesini zorunlu kılıyor
      Yapay zeka kodlama ajanları henüz bu tür desenleri iyi kullanamıyor ama aracın kendisi çok sağlam
    • Aslında AST yapısını derinlemesine anlamak zorunda değilsiniz
      Çoğu zaman sözdizim düğümü bazında seçip silmek, kopyalamak ya da değiştirmek yeterli oluyor
    • Herkesin işi farklı olduğu için AST düzenlemeye duyulan ihtiyaç da farklı
      Ben sık sık büyük ölçekli refactor yapmadığım için bunu öğrenme ihtiyacı hissetmiyorum
      Ama büyük servisler geliştiren biri tamamen farklı düşünebilir
    • Ben de benzer bir noktadayım
      Elixir’de macro yazmayı öğrenirken çok şey fark ettim, Lisp de aynı bağlamda geliyor
      Dillerin yaklaşımı farklı olsa da sonunda aynı hedefe gidiyorlar

  • Benim gördüğüm editör sınıflandırması şöyle

    1. Ortodoks — UI ve entegrasyon odaklı
    2. Modal (Vim iyileştirmesi) — mevcut keybinding’leri koruyan
    3. Modal (yeni yaklaşım) — Vim felsefesini yeniden yorumlayan
      Ki üçüncü kategoriye giriyor ve ben bu tür projeleri düzenli olarak takip ediyorum
      1. bir kategori daha var — her şeyi kapsayan Emacs
    • Ben de aynı fikirdeyim. Meydan okuyan çok oldu ama hâlâ şampiyon tek kişi gibi geliyor
    • Ben de AST tabanlı modal bir kod editörü geliştiriyorum
      UI düğümleri normal metin gibi görünüyor ama aslında ağaç yapısındalar
      Erken geri bildirim vermek isterseniz profildeki e-posta üzerinden ulaşabilirsiniz
    • Vim iyileştirmesi diyorsak, sonunda “Ed Visual Mode Improved Improved” esprisine kadar gidiyoruz

  • AST düzenlemenin zorluğu keşfedilebilirlik (discoverability)
    Ekranda görünse bile çoğu zaman o düğümün adını bilmiyorsunuz
    Bu yüzden imlecin etrafını renklerle çerçeveleyip her scope’u görselleştiren bir eklenti fikrim var
    “Sonraki fonksiyona git” yerine “sonraki maviye git” diye düşünmek gibi

    • Ki’de düğüm adını bilmeseniz de d m tuşlarına basınca o anda görünen tüm sözdizim düğümlerinin etiketleri gösteriliyor ve doğrudan geçiş yapabiliyorsunuz
    • Yine de genel AST düzeyinde seçim/genişletme/daraltma özelliği hâlâ çok değerli
      Geçerli düğümün içini ya da dışını seçmek gibi işlemler faydalı oluyor

  • Ben VSCode için Ki entegrasyonu yaptım
    Sonrasında çok fazla katkı verememiş olmama üzülüyorum ama bu tür temel araç yeniliklerinin çok önemli olduğunu düşünüyorum
    Ki VSCode eklenti bağlantısı

    • Evet, tam olarak o eklenti
    • Yeni bir editörü denemek göz korkutucu olabiliyor ama VSCode eklentisi giriş eşiğini düşürüyor

  • Örnekleri görmeden önce pek anlamamıştım ama
    “Birinci sınıf sözdizimsel değişiklik” bölümünde virgüllerin otomatik eklenip silinmesini görünce etkilendim
    Uygulama mantığı da hatta daha basit olabilir gibi duruyor
    Artık Zed’de de Ki entegrasyonu ya da AST tabanlı rewrite denemek istiyorum

    • Ki’nin VSCode eklentisini ben yaptım; WebSocket iletişim yapısı kullandığı için Zed’e de kolayca bağlanabilir
      Ki deposundaki koda bakabilirsiniz

  • Yakında bizzat deneyeceğim
    Klavye düzeninden bağımsız olması hoşuma gitti
    Emacs’in “her şey düzenlenebilir bir buffer’dır” felsefesinden ilham alması da ilginç
    Tabii editörlerin her birinde büyük trade-off’lar var, o yüzden kullanmadan anlamak zor gibi

    • Editörün düzenleme modeli merkezli tasarlanmış olması yüzünden her seferinde her şeyi yeniden yapmak gerekmesi üzücü
      Neovim harika ama düzenleme modelinin sınırları var
      Eğer bütünüyle değiştirilebilir bir yapısı olsaydı belki Helix ya da Ki’ye gerek kalmazdı
    • Ama düzen bağımsızlığı benim için bir kâbustu
      Dvorak klavyeyle çalıştırınca eşlemeler tamamen bozuldu
      Yazılım kendini kullanıcıdan daha akıllı sandığında, kullanıcıyı çaresiz hissettirebiliyor

  • Tabii ki Emacs’te zaten var
    combobulate paketi buna örnek

    • combobulate ile Lisp düzenlemesi kadar doğal AST gezinmesi mümkün
      M-k ile düğüm silebilir ya da tree-sitter sorgularıyla doğrudan arama ve düzenleme yapabilirsiniz
      Zaten çok iyi bir entegrasyon var ama AST’ye özel bir editör olursa UX’i daha da ilerletme alanı bulunuyor

  • Helix iş akışına gerçekten çok yakışan bir özellik
    Mevcut hareket → eylem düzenine son parçanın oturması gibi hissettiriyor