Ki Editor - เอดิเตอร์ที่ทำงานบนพื้นฐาน AST

 (ki-editor.org)
2 คะแนน โดย GN⁺ 2026-03-08 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เป็น ตัวแก้ไขเชิงโครงสร้าง แบบ หลายเคอร์เซอร์ ที่สามารถ จัดการโครงสร้างโค้ดได้โดยตรง และทำงานโดยมี syntax tree (AST) เป็นศูนย์กลาง
  • รองรับ การโต้ตอบในระดับ syntax node เพื่อลดช่องว่างระหว่างเจตนาในการเขียนโค้ดกับการแก้ไขที่เกิดขึ้นจริง
  • ด้วย ความสามารถแบบหลายเคอร์เซอร์ จึงสามารถแก้ไขหรือรีแฟกเตอร์ syntax node หลายจุดพร้อมกันได้ เพิ่มประสิทธิภาพในการแก้ไขจำนวนมาก
  • นิยามการแก้ไขแบบอิงโหมดใหม่ ทำให้สามารถเคลื่อนที่ในหน่วยต่าง ๆ เช่น คำ บรรทัด และ syntax node ได้อย่าง สม่ำเสมอ
  • เสริม ความแม่นยำและความสอดคล้อง ของการแก้ไขโค้ด และนำเสนอพาราไดม์ใหม่ที่ช่วยเพิ่มผลิตภาพของนักพัฒนา

ภาพรวมของ Ki Editor

  • Ki Editor เป็น ตัวแก้ไขเชิงโครงสร้างแบบหลายเคอร์เซอร์ (Multi-cursor structural editor) ที่มอบสภาพแวดล้อมการแก้ไขซึ่งจัดการโครงสร้างทางไวยากรณ์ของโค้ดได้โดยตรง
  • ต่างจากการแก้ไขแบบอิงข้อความดั้งเดิม โดยใช้ syntax tree (AST) เป็นพื้นฐานในการจัดการองค์ประกอบของโค้ด
  • สามารถ แก้ไขโดยตรงในระดับ syntax node ได้โดยไม่ต้องใช้เมาส์หรือคีย์ผสม

การโต้ตอบกับ syntax node

  • ผ่านความสามารถ First-class syntax node interaction ที่ทำให้จัดการโครงสร้างไวยากรณ์ของโค้ดได้โดยตรง
    • มุ่งลดช่องว่างระหว่างเจตนาในการเขียนโค้ดกับการแก้ไขที่เกิดขึ้นจริง
    • ดำเนินการ จัดการในระดับไวยากรณ์ ได้โดยไม่ต้องเลื่อนเมาส์หรือใช้คีย์ลัดที่ซับซ้อน

ความสามารถแบบหลายเคอร์เซอร์

  • ใช้ Multiple cursors เพื่อแก้ไข syntax node หลายจุดพร้อมกันได้
    • การจัดการ syntax node แบบขนานช่วยเพิ่ม ประสิทธิภาพในการแก้ไขจำนวนมากและการรีแฟกเตอร์
    • จัดการงานแก้ไขโค้ดที่ซ้ำ ๆ ได้อย่างรวดเร็ว

การนิยามการแก้ไขแบบอิงโหมดใหม่

  • ฟีเจอร์ Redefine modal editing ช่วยทำให้โหมดการเลือกเป็นมาตรฐาน
    • รองรับการเคลื่อนที่ในหน่วยต่าง ๆ เช่น คำ บรรทัด และ syntax node ได้อย่าง สม่ำเสมอ
    • เพิ่ม ความยืดหยุ่นและความสอดคล้อง มากกว่าการแก้ไขแบบอิงโหมดเดิม

ความสำคัญ

  • Ki Editor มอบ ประสบการณ์การแก้ไขที่ยึดโครงสร้างไวยากรณ์เป็นศูนย์กลาง ช่วยเพิ่มความแม่นยำในการเขียนและแก้ไขโค้ด
  • การผสานหลายเคอร์เซอร์เข้ากับการจัดการ syntax node นำเสนอแนวทางใหม่ของการแก้ไขโค้ดที่ช่วย เพิ่มผลิตภาพของนักพัฒนา

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-03-08
ความเห็นจาก Hacker News

  • พอเห็นฟีเจอร์ “First-class syntactic selection” ก็ทำให้นึกถึงคีย์ลัด Expand / Shrink Selection ที่ใช้บ่อยใน JetBrains IDE
    ด้วยปุ่ม Ctrl + W, Ctrl + Shift + W สามารถขยายหรือย่อพื้นที่ที่เลือกตามหน่วยของไวยากรณ์ได้
    ฟีเจอร์นี้ทำให้มุมมองของผมต่อวิธีที่เราโต้ตอบกับ ‘ข้อความ’ ในไฟล์เปลี่ยนไปอย่างสิ้นเชิง
    ใน VS Code กับ Zed ก็มีฟีเจอร์คล้ายกัน แต่รู้สึกว่าการขยาย/ย่อมัน หยาบเกินไป
    ลิงก์เอกสาร JetBrains

    • คีย์ลัด JetBrains ที่ผมใช้บ่อยมีดังนี้
      ใช้ Cmd+Shift+V เพื่อเปิด stack clipboard แล้วค้นหาหรือเลือกประวัติที่เคยคัดลอกไว้ได้
      Cmd+Shift+E จะแสดงรายการตำแหน่งล่าสุด และ Cmd+Shift+A จะเปิด action palette เพื่อ fuzzy search คำสั่งทั้งหมดได้
      อีกทั้งฟีเจอร์ Local History ยังติดตามประวัติการเปลี่ยนไฟล์ได้ละเอียดกว่า Git มาก
      ฟีเจอร์เหล่านี้ต่อยอดไปสู่แนวคิดแบบ “แก้ไขได้ทันทีจากบัฟเฟอร์ผลการค้นหา”
    • ใน Neovim ก็ใช้ฟีเจอร์เดียวกันได้ผ่าน incremental selection ที่อิงกับ tree-sitter
    • Mathematica มีฟังก์ชันขยายการเลือกด้วย Alt+. มาตั้งแต่ต้นยุค 90
      ดับเบิลคลิกคือเลือกคำ, ทริปเปิลคลิกคือเลือกอาร์กิวเมนต์ของฟังก์ชันทั้งหมด, คลิก 4 ครั้งคือเลือกทั้ง f(a,r,g,s) เป็นโครงสร้างที่ หน่วยไวยากรณ์ใหญ่ขึ้นตามจำนวนครั้งที่คลิก
      จนถึงตอนนี้ผมก็ยังจำด้วยกล้ามเนื้อได้อยู่
    • ผมกำลังวิจัย version control แบบอิง AST อยู่
      กำลังทดลองแนวคิดที่ให้ commit, diff, cherry-pick ทำงานตามหน่วยไวยากรณ์แบบ Ctrl+W
      มีสรุปไว้ใน โปรเจ็กต์ librdx
    • ผมใช้ฟีเจอร์นี้บ่อยใน helix เหมือนกัน แต่ implementation ของ vscode ไม่ค่อยดี
      การแก้ไขแบบรับรู้ AST ทำให้นึกถึง ความสะดวกของภาษาในตระกูล Lisp
      สิ่งที่ Lisp ทำได้ด้วยการจัดการลิสต์ง่าย ๆ ใน JS กลับต้องพึ่ง LSP หรือ parser แยก
      พอกลับจากเขียน Clojure ช่วงสุดสัปดาห์มาใช้ TypeScript ก็คิดถึงคำสั่ง paredit มาก

  • เมื่อก่อนผมเคยทำ ตัวแก้ไขที่อิง syntax tree ขึ้นมาเอง
    เพราะจัดการแต่ tree โดยไม่พิมพ์ข้อความตรง ๆ จึง ไม่มีทางมีโปรแกรมที่ผิดไวยากรณ์ได้
    แต่ความท้าทายใหญ่คือการทำให้วิธีป้อนข้อมูลใช้งานจริงได้
    ตอนนี้รันไม่ได้แล้วเพราะไม่มีฮาร์ดแวร์แสดงผลในตอนนั้น แต่ยังทิ้ง คำอธิบายโปรเจ็กต์ ไว้

    • ปัญหาคือข้อจำกัดที่ว่า “เส้นทางจากโปรแกรม A ไป B ต้องเป็นโปรแกรมที่ถูกต้องเสมอ”
      ผลคือบางครั้งต้องผ่าน เส้นทางที่ไม่เป็นธรรมชาติ หรือไม่ก็ต้องเขียนใหม่ตั้งแต่ต้น
      ถึงขั้นมีโครงสร้างที่แม้จะถูกต้อง แต่กลับไม่มีเส้นทางสร้างมันขึ้นมาได้
    • เมื่อก่อนเคยใช้ภาษาและเอดิเตอร์เชิงทดลองที่สร้างบน JetBrains MPS ในบริษัท
      ในเชิงทฤษฎีน่าสนใจ แต่รู้สึกว่าเป็น ทางตันที่ใช้งานจริงได้ไม่ดี
      มันยากที่จะชนะ ความเป็นสากลและความเรียบง่าย ของอินเทอร์เฟซแบบข้อความ
      ทั้งเอดิเตอร์เฉพาะทาง, version control แบบใหม่, ระบบนิเวศที่ไม่เชื่อมต่อกัน ล้วนเป็นข้อจำกัดในโลกจริงที่ใหญ่เกินไป
      คนเราไม่ได้คิดเป็นหน่วย tree ดังนั้นการโค้ดโดยอยู่ในสถานะที่ถูกต้องตามไวยากรณ์ตลอดเวลาจึงเป็น ประสบการณ์ที่อึดอัดอย่างยิ่ง
      สุดท้ายเครื่องมือที่ยอมให้มี ความเข้มงวดแบบยืดหยุ่น ได้เท่านั้นที่อยู่รอดจริง (เช่น gradual typing ของ TypeScript)
    • ถ้าอยากลองระบบเก่าอีกครั้ง สามารถกู้สภาพแวดล้อม VT11 ด้วยอีมูเลเตอร์ simh และ mame ได้
      ดูข้อมูลได้ที่ simh, mame, โค้ด VT11, เอกสาร
    • มีโปรเจ็กต์ชื่อ Pantograph ที่กำลังลองแนวคิดนี้ใหม่ในแบบสมัยใหม่
      ยังไม่ใช่เอดิเตอร์ทั่วไป แต่ทิศทางเรื่องการขยายช่วงเลือกของ tree ดูมีอนาคต
      ลิงก์ Pantograph
    • ตอนนี้ผมกำลังพัฒนาโปรเจ็กต์ภาคต่อชื่อ BABLR
      มันสร้างอยู่บนระบบ parser ที่จัดการ tree ที่ยังไม่สมบูรณ์แต่ยัง valid ได้
      ผ่าน การแทนช่องว่าง อย่าง <//> จึงจัดการ syntax ที่ยังไม่สมบูรณ์ได้อย่างปลอดภัย
      เช่น 2 + · ก็ parse เป็น tree แบบ <BinaryExpression> ได้
      ถ้าสนใจ ตอนนี้คุยกันอยู่ใน Discord community

  • ผมยังไม่คุ้นกับการแก้ไขแบบ AST
    ใช้แค่ text object สำหรับจัดการ function argument หรือ arglist เท่านั้น
    ฟีเจอร์ LSP ก็ใช้แค่ไปที่นิยามกับ rename
    สุดท้ายเลยรู้สึกว่า ต้องฝึกฝีมือการใช้เอดิเตอร์ให้มากกว่านี้

    • ในกรณีแบบนี้ เครื่องมืออย่าง ast-grep มีประโยชน์มาก
      เขียนแพตเทิร์นด้วยไวยากรณ์ที่แทบเหมือนโค้ดจริง แล้วเห็นการแปลงตรงหน้าได้เลย
      เช่น ast-grep -pattern '$A && $A.$B' --rewrite '$A?.$B' -lang ts เพื่อทำ การแปลงเป็น optional chaining
      เมตาแปรอย่าง $X, $A ฯลฯ ใช้บังคับให้จับคู่ node เดียวกัน
      ตอนนี้ AI coding agent ยังใช้แพตเทิร์นแบบนี้ไม่เก่ง แต่ตัวเครื่องมือนั้นแข็งแรงมาก
    • ในทางปฏิบัติไม่จำเป็นต้องเข้าใจโครงสร้าง AST ลึกมากก็ได้
      ส่วนใหญ่แค่ เลือกตามหน่วย syntax แล้วลบ คัดลอก หรือแทนที่ ก็เพียงพอแล้ว
    • งานของแต่ละคนไม่เหมือนกัน ความจำเป็นในการแก้ไขแบบ AST ก็เลยต่างกัน
      ผมไม่ค่อยทำรีแฟกเตอร์ครั้งใหญ่บ่อย ๆ จึงไม่รู้สึกว่าต้องเรียนรู้มัน
      แต่ถ้าเป็นนักพัฒนาที่ดูแลบริการขนาดใหญ่ อาจมีมุมมองต่างออกไปโดยสิ้นเชิง
    • ผมก็อยู่ฝั่งคล้ายกัน
      การเรียนรู้ การเขียน macro ใน Elixir ทำให้ได้มุมมองใหม่เยอะมาก และ Lisp ก็อยู่ในบริบทเดียวกัน
      แม้แต่ละภาษาจะใช้วิธีต่างกัน แต่สุดท้ายก็มุ่งไปสู่จุดหมายเดียวกัน

  • การจัดหมวดหมู่เอดิเตอร์ในมุมมองของผมมีดังนี้

    1. สายดั้งเดิม (Orthodox) — เน้น UI และการบูรณาการ
    2. สายโมดัล (ปรับปรุง Vim) — คง keybinding เดิมไว้
    3. สายโมดัล (แนวทางใหม่) — ตีความปรัชญา Vim ใหม่
      Ki อยู่ในกลุ่มที่สาม และผมก็คอยจับตาโปรเจ็กต์แบบนี้อยู่เสมอ
    • ยังมีหมวดที่ 4 ด้วย — Emacs ที่ครอบจักรวาลทุกอย่าง
    • ผมก็คิดเหมือนกัน มีผู้ท้าชิงมากมายแต่ก็ยังรู้สึกว่า แชมป์ยังมีอยู่แค่หนึ่งเดียว
    • ผมก็กำลังพัฒนา modal code editor แบบอิง AST อยู่เหมือนกัน
      UI node ดูเหมือนข้อความธรรมดา แต่จริง ๆ แล้วเป็นโครงสร้าง tree
      ถ้าอยากให้ฟีดแบ็กช่วงแรก ติดต่อมาที่อีเมลในโปรไฟล์ได้เลย
    • ถ้าเรียกว่าเป็นการปรับปรุง Vim สุดท้ายก็มีมุกว่า “Ed Visual Mode Improved Improved” หลุดออกมาอยู่ดี

  • ความยากของการแก้ไขแบบ AST คือเรื่อง discoverability
    มันเห็นอยู่บนหน้าจอ แต่บ่อยครั้งเราไม่รู้ชื่อของ node นั้น
    เพราะแบบนี้ผมเลยกำลังคิดปลั๊กอินที่ล้อมรอบเคอร์เซอร์ด้วยสีเพื่อ ทำให้แต่ละ scope มองเห็นได้ชัด
    แนวคิดคือเปลี่ยนจาก “ย้ายไปฟังก์ชันถัดไป” เป็น “ย้ายไปยังสีฟ้าถัดไป”

    • ใน Ki ต่อให้ไม่รู้ชื่อ node ก็แค่กด d m แล้วมันจะแสดง ป้ายชื่อของ syntax node ทั้งหมดที่มองเห็นอยู่ตอนนั้น เพื่อให้ย้ายไปได้ทันที
    • ถึงอย่างนั้น ฟีเจอร์เลือก/ย่อระดับ AST แบบทั่วไป ก็ยังมีคุณค่าอยู่มาก
      การเลือกด้านในหรือด้านนอกของ node ปัจจุบันเป็นการทำงานที่มีประโยชน์

  • ผมเคยทำ Ki integration สำหรับ VSCode
    เสียดายที่หลังจากนั้นไม่ได้มีส่วนร่วมต่อมากนัก แต่ผมคิดว่านี่คือ นวัตกรรมเครื่องมือพื้นฐาน ที่สำคัญมาก
    ลิงก์ส่วนขยาย Ki สำหรับ VSCode

    • ใช่แล้ว นั่นแหละส่วนขยายนั้น
    • การลองเอดิเตอร์ใหม่เป็นเรื่องที่น่าหนักใจ แต่ส่วนขยาย VSCode ช่วย ลดกำแพงในการเริ่มต้น ได้

  • ก่อนเห็นตัวอย่างผมยังไม่ค่อยเข้าใจนัก
    แต่พอเห็นว่าใน “First-class syntactic modification” มีการเพิ่ม/ลบ comma ให้อัตโนมัติ ก็ทึ่งมาก
    ตรรกะการทำงานก็ดูเหมือนจะเรียบง่ายกว่าที่คิดด้วย
    ตอนนี้เลยอยากลองทำ Ki integration หรือ AST-based rewrite ใน Zed ดูบ้าง

    • ผมเป็นคนทำส่วนขยาย VSCode ของ Ki เอง และเพราะมันเป็น โครงสร้างการสื่อสารผ่าน WebSocket จึงน่าจะเชื่อมกับ Zed ได้ง่าย
      ลองอ้างอิงโค้ดใน repository ของ Ki ได้เลย

  • เดี๋ยวผมจะลองใช้เองเร็ว ๆ นี้
    ผมชอบที่มัน ไม่ขึ้นกับ keyboard layout
    และยังน่าสนใจที่มันได้แรงบันดาลใจจากปรัชญา “ทุกอย่างคือบัฟเฟอร์ที่แก้ไขได้” ของ Emacs
    แน่นอนว่าเอดิเตอร์แต่ละตัวมี trade-off สูงมาก คงต้องลองเองถึงจะรู้

    • ตัวเอดิเตอร์เป็น โครงสร้างที่ออกแบบโดยยึด edit model เป็นศูนย์กลาง เลยรู้สึกเสียดายที่ต้องสร้างทุกอย่างขึ้นมาใหม่เสมอ
      Neovim นั้นยอดเยี่ยม แต่ edit model มีข้อจำกัด
      ถ้ามันมีโครงสร้างที่สลับแทนกันได้ทั้งหมด อาจไม่จำเป็นต้องมี Helix หรือ Ki ก็ได้
    • แต่สำหรับผม ความไม่ขึ้นกับ layout กลับเป็นฝันร้าย
      พอรันบนคีย์บอร์ด Dvorak แล้วแมปปิงพังหมด
      เวลาซอฟต์แวร์คิดว่าตัวเองฉลาดกว่าผู้ใช้ สุดท้ายผู้ใช้กลับ รู้สึกไร้อำนาจ

  • ตามคาด Emacs มีอยู่แล้ว
    แพ็กเกจ combobulate ก็คือตัวอย่างนั้น

    • ถ้าใช้ combobulate ก็จะได้ การท่องไปใน AST ที่เป็นธรรมชาติแบบการแก้ไข Lisp
      ลบ node ด้วย M-k หรือค้นหา/แก้ไขตรง ๆ ด้วย tree-sitter query ก็ได้
      ตอนนี้การบูรณาการก็ดีมากอยู่แล้ว แต่ถ้าเป็น เอดิเตอร์ที่ทุ่มให้ AST โดยเฉพาะ ก็ยังมีพื้นที่ให้พัฒนา UX ได้อีกมาก

  • มันเป็นฟีเจอร์ที่เข้ากับ workflow ของ Helix มาก
    ให้ความรู้สึกเหมือนชิ้นส่วนสุดท้ายถูกใส่เข้าไปในแพตเทิร์นแบบ move → action ที่มีอยู่เดิม