Ki Editor - Trình soạn thảo hoạt động dựa trên AST

 (ki-editor.org)
2 điểm bởi GN⁺ 2026-03-08 | 1 bình luận | Chia sẻ qua WhatsApp
  • Trình soạn thảo cấu trúc dựa trên đa con trỏ cho phép thao tác trực tiếp với cấu trúc mã, hoạt động xoay quanh cây cú pháp (AST)
  • Hỗ trợ tương tác ở cấp nút cú pháp, giúp thu hẹp khoảng cách giữa ý định khi viết mã và thao tác chỉnh sửa thực tế
  • Với tính năng đa con trỏ, có thể chỉnh sửa hoặc refactor nhiều nút cú pháp cùng lúc, nâng cao hiệu quả chỉnh sửa hàng loạt
  • Định nghĩa lại cách chỉnh sửa theo chế độ, cho phép di chuyển nhất quán theo nhiều đơn vị như từ, dòng, nút cú pháp
  • Tăng cường độ chính xác và tính nhất quán trong chỉnh sửa mã, đề xuất một mô hình biên tập mới giúp nâng cao năng suất của lập trình viên

Tổng quan về Ki Editor

  • Ki Editor là một trình soạn thảo cấu trúc đa con trỏ (Multi-cursor structural editor), cung cấp môi trường chỉnh sửa cho phép thao tác trực tiếp với cấu trúc cú pháp của mã
  • Khác với kiểu chỉnh sửa văn bản truyền thống, công cụ này thao tác các thành phần mã dựa trên cây cú pháp (AST)
  • Có thể chỉnh sửa trực tiếp theo đơn vị nút cú pháp mà không cần dùng chuột hay tổ hợp phím phức tạp

Tương tác với nút cú pháp

  • Thông qua tính năng First-class syntax node interaction, người dùng có thể trực tiếp xử lý cấu trúc cú pháp của mã
    • Tập trung vào việc thu hẹp khoảng cách giữa ý định khi viết mã và thao tác chỉnh sửa thực tế
    • Thực hiện thao tác theo đơn vị cú pháp mà không cần di chuyển chuột hay nhập phím phức tạp

Tính năng đa con trỏ

  • Có thể dùng Multiple cursors để chỉnh sửa đồng thời nhiều nút cú pháp
    • Nâng cao hiệu quả chỉnh sửa hàng loạt và refactor nhờ thao tác song song trên các nút cú pháp
    • Xử lý nhanh các tác vụ sửa mã lặp đi lặp lại

Định nghĩa lại chỉnh sửa theo chế độ

  • Với tính năng Redefine modal editing, chế độ chọn được chuẩn hóa
    • Hỗ trợ nhất quán việc di chuyển theo nhiều đơn vị như từ, dòng, nút cú pháp
    • Tăng cường tính linh hoạt và nhất quán so với kiểu chỉnh sửa theo chế độ hiện có

Ý nghĩa

  • Ki Editor mang đến trải nghiệm chỉnh sửa lấy cấu trúc cú pháp làm trung tâm, giúp tăng độ chính xác khi viết và sửa mã
  • Kết hợp đa con trỏ với thao tác trên nút cú pháp để đề xuất một cách tiếp cận mới trong biên tập mã, góp phần nâng cao năng suất phát triển

Bài viết liên quan

1 bình luận

 
GN⁺ 2026-03-08
Ý kiến trên Hacker News

  • Khi thấy tính năng “First-class syntactic selection”, tôi lập tức nghĩ đến phím tắt Expand / Shrink Selection mà tôi hay dùng trong JetBrains IDE
    Với tổ hợp Ctrl + W, Ctrl + Shift + W, có thể mở rộng hoặc thu hẹp vùng chọn theo đơn vị cú pháp
    Nhờ tính năng này mà góc nhìn của tôi về cách tương tác với ‘văn bản’ trong tệp đã thay đổi hoàn toàn
    VS Code hay Zed cũng có tính năng tương tự, nhưng cảm giác mở rộng/thu hẹp quá thô
    Liên kết tài liệu JetBrains

    • Các phím tắt JetBrains tôi hay dùng là như sau
      Với Cmd+Shift+V có thể mở stack clipboard để tìm kiếm hoặc chọn lịch sử sao chép trước đó
      Cmd+Shift+E hiển thị danh sách vị trí gần đây, còn Cmd+Shift+A mở action palette để fuzzy search mọi lệnh
      Ngoài ra, tính năng Local History cho phép theo dõi lịch sử thay đổi tệp chi tiết hơn Git rất nhiều
      Những tính năng như vậy dẫn đến khái niệm “chỉnh sửa trực tiếp ngay trong buffer kết quả tìm kiếm”
    • Trong Neovim cũng có thể dùng tính năng tương tự bằng incremental selection dựa trên tree-sitter
    • Mathematica đã cung cấp tính năng mở rộng vùng chọn bằng Alt+. từ đầu những năm 90
      Double-click chọn từ, triple-click chọn toàn bộ đối số hàm, click lần thứ 4 chọn toàn bộ f(a,r,g,s), tức là đơn vị cú pháp tăng dần theo số lần nhấp
      Đến giờ tôi vẫn còn nhớ cơ bắp với cách này
    • Tôi đang nghiên cứu quản lý phiên bản dựa trên AST
      Tôi đang thử nghiệm ý tưởng để commit, diff, cherry-pick cũng hoạt động theo đơn vị cú pháp như Ctrl+W
      Nội dung liên quan được tổng hợp trong dự án librdx
    • Tôi cũng hay dùng tính năng này trong helix, nhưng cách triển khai của vscode thì không hay lắm
      Chỉnh sửa có nhận thức AST làm tôi nhớ đến sự tiện lợi của các ngôn ngữ họ Lisp
      Trong Lisp, những việc có thể làm bằng thao tác list đơn giản thì ở JS lại cần LSP hoặc parser riêng
      Sau cuối tuần dùng Clojure rồi quay lại TypeScript, tôi thực sự nhớ các lệnh paredit

  • Trước đây tôi từng tự làm một trình soạn thảo dựa trên cây cú pháp
    Vì chỉ thao tác với cây thay vì nhập văn bản, nên không thể tồn tại chương trình sai cú pháp
    Tuy vậy, biến nó thành một phương thức nhập liệu đủ thực dụng để dùng thực tế là thử thách lớn
    Giờ tôi không thể chạy lại vì không còn phần cứng hiển thị thời đó, nhưng vẫn để lại mô tả dự án

    • Vấn đề nằm ở ràng buộc “đường đi từ chương trình A sang B phải luôn là một chương trình hợp lệ”
      Kết quả là đôi khi phải đi qua những bước không trực quan, hoặc thậm chí phải viết lại từ đầu
      Thậm chí còn có những cấu trúc tuy hợp lệ nhưng không hề tồn tại đường tạo ra chúng
    • Trước đây ở công ty tôi từng dùng một ngôn ngữ và editor thử nghiệm dựa trên JetBrains MPS
      Về mặt lý thuyết thì thú vị, nhưng tôi cảm thấy đó là ngõ cụt kém thực dụng
      Rất khó để thắng được tính phổ quát và sự đơn giản của giao diện dựa trên văn bản
      Editor chuyên dụng, hệ thống quản lý phiên bản mới, hệ sinh thái bị chia cắt và nhiều ràng buộc thực tế khác là trở ngại quá lớn
      Con người không suy nghĩ theo đơn vị cây, nên việc chỉ được code trong trạng thái luôn đúng cú pháp là một trải nghiệm cực kỳ ngột ngạt
      Cuối cùng, các công cụ cho phép sự nghiêm ngặt linh hoạt (ví dụ như gradual typing của TypeScript) mới thực sự tồn tại được
    • Nếu muốn trải nghiệm lại hệ thống cũ, có thể dùng trình giả lập simh và mame để khôi phục môi trường VT11
      Tài liệu liên quan: simh, mame, mã VT11, tài liệu
    • Một dự án tên Pantograph đang thử lại ý tưởng này theo cách hiện đại hơn
      Dù chưa phải editor phổ thông, hướng mở rộng phạm vi chọn theo cây có vẻ đầy hứa hẹn
      Liên kết Pantograph
    • Hiện tôi đang phát triển một dự án kế nhiệm tên BABLR
      Nó được xây trên một hệ thống parser xử lý các cây chưa hoàn chỉnh nhưng vẫn hợp lệ
      Thông qua biểu diễn khoảng trống như <//>, có thể xử lý cú pháp chưa hoàn chỉnh một cách an toàn
      Ví dụ: 2 + · có thể được parse thành cây <BinaryExpression>
      Nếu quan tâm, hiện đang có thảo luận trong cộng đồng Discord

  • Tôi không quen với chỉnh sửa AST
    Tôi chỉ dùng các text object kiểu đối số hàm hay arglist
    Tính năng LSP thì cũng chỉ dùng mức nhảy đến định nghĩa và đổi tên
    Rốt cuộc tôi thấy mình cần nâng trình dùng editor hơn nữa

    • Trong trường hợp này, các công cụ như ast-grep rất hữu ích
      Có thể viết pattern bằng cú pháp gần như giống mã nguồn và nhìn thấy phép biến đổi ngay trước mắt
      Ví dụ có thể thực hiện chuyển đổi sang optional chaining bằng lệnh ast-grep -pattern '$A && $A.$B' --rewrite '$A?.$B' -lang ts
      Các metavariable như $X, $A buộc phải khớp cùng một node
      AI coding agent hiện vẫn chưa dùng tốt kiểu pattern này, nhưng bản thân công cụ thì rất vững vàng
    • Trên thực tế không cần hiểu quá sâu cấu trúc AST
      Phần lớn trường hợp chỉ cần chọn theo node cú pháp rồi xóa, sao chép, thay thế là đủ
    • Mỗi người có công việc khác nhau nên mức độ cần thiết của chỉnh sửa AST cũng khác
      Tôi không thường xuyên làm refactor quy mô lớn nên không thấy cần phải học
      Nhưng nếu là lập trình viên phát triển dịch vụ lớn, có thể sẽ có quan điểm hoàn toàn khác
    • Tôi cũng ở vị trí tương tự
      Khi học viết macro trong Elixir tôi đã có được nhiều hiểu biết, và Lisp cũng tương tự
      Mỗi ngôn ngữ có cách tiếp cận khác nhau, nhưng cuối cùng đều hướng đến cùng một đích

  • Cách tôi phân loại editor là như sau

    1. Chính thống (Orthodox) — tập trung vào UI và tính tích hợp
    2. Modal (cải tiến Vim) — giữ nguyên keybinding hiện có
    3. Modal (cách tiếp cận mới) — diễn giải lại triết lý Vim
      Ki thuộc nhóm thứ ba, và tôi luôn theo dõi sát các dự án kiểu này
    • Còn có phân loại thứ 4 — Emacs bao trùm tất cả
    • Tôi cũng nghĩ vậy. Có nhiều người thách thức, nhưng tôi vẫn cảm thấy nhà vô địch chỉ có một
    • Tôi cũng đang phát triển một editor code modal dựa trên AST
      Các node UI trông như văn bản bình thường, nhưng thực ra là cấu trúc cây
      Nếu muốn cho phản hồi ban đầu, hãy liên hệ qua email trong hồ sơ của tôi
    • Nói đến cải tiến Vim thì cuối cùng lại thành trò đùa kiểu “Ed Visual Mode Improved Improved”

  • Khó khăn của chỉnh sửa AST là khả năng khám phá (discoverability)
    Nó có hiện trên màn hình, nhưng nhiều khi ta không biết tên của node đó
    Vì vậy tôi đang nghĩ đến một plugin dùng màu sắc bao quanh khu vực gần con trỏ để trực quan hóa từng scope
    Thay vì nghĩ “đi tới hàm tiếp theo”, sẽ nghĩ theo kiểu “đi tới vùng màu xanh tiếp theo”

    • Trong Ki, dù không biết tên node, chỉ cần nhấn d m là sẽ hiện nhãn của mọi node cú pháp đang thấy trên màn hình để có thể nhảy tới ngay
    • Dù vậy, các chức năng chọn/thu hẹp ở mức AST phổ quát vẫn rất có giá trị
      Những thao tác như chọn phần bên trong hoặc bên ngoài node hiện tại rất hữu ích

  • Tôi đã tạo tích hợp Ki cho VSCode
    Sau đó không đóng góp được nhiều nữa nên hơi tiếc, nhưng tôi nghĩ những đổi mới ở tầng công cụ nền tảng như thế này là cực kỳ quan trọng
    Liên kết extension Ki cho VSCode

    • Đúng vậy, chính là extension đó
    • Việc thử một editor mới khá là áp lực, nên extension VSCode này giảm thấp rào cản tiếp cận

  • Trước khi xem ví dụ thì tôi chưa hiểu lắm,
    nhưng khi thấy trong “First-class syntactic modification” dấu phẩy được tự động thêm/xóa, tôi đã thật sự ấn tượng
    Có vẻ logic triển khai còn khá đơn giản nữa
    Giờ tôi cũng muốn thử tích hợp Ki hoặc rewrite dựa trên AST trong Zed

    • Tôi là người tạo extension VSCode của Ki, và vì nó dùng cấu trúc giao tiếp WebSocket, nên cũng có thể tích hợp với Zed khá dễ
      Chỉ cần tham khảo mã trong kho lưu trữ Ki

  • Tôi sẽ sớm thử dùng trực tiếp
    Tôi thích điểm độc lập với bố cục bàn phím
    Việc nó lấy cảm hứng từ triết lý “mọi thứ đều là buffer có thể chỉnh sửa” của Emacs cũng rất thú vị
    Tất nhiên mỗi editor đều có trade-off lớn, nên chắc phải dùng thử mới biết

    • Vì editor được thiết kế xoay quanh mô hình chỉnh sửa, nên tiếc là cứ phải xây lại mọi thứ từ đầu
      Neovim rất tuyệt, nhưng mô hình chỉnh sửa của nó có giới hạn
      Nếu cấu trúc của nó cho phép thay thế hoàn toàn, có lẽ đã không cần Helix hay Ki
    • Nhưng tính độc lập với layout lại là cơn ác mộng với tôi
      Tôi chạy nó trên bàn phím Dvorak thì mapping bị hỏng hoàn toàn
      Khi phần mềm tưởng rằng nó thông minh hơn người dùng, rốt cuộc lại khiến người dùng cảm thấy bất lực

  • Đúng là Emacs đã có thứ này từ lâu
    Gói combobulate là một ví dụ

    • Dùng combobulate thì có thể duyệt AST tự nhiên như khi chỉnh sửa Lisp
      Có thể xóa node bằng M-k hoặc tìm kiếm/chỉnh sửa trực tiếp bằng tree-sitter query
      Hiện đã có mức độ tích hợp rất tốt, nhưng nếu là editor chuyên cho AST thì vẫn còn nhiều dư địa để cải thiện UX

  • Đây là tính năng cực kỳ hợp với workflow của Helix
    Cảm giác như mảnh ghép cuối cùng đã khớp vào pattern di chuyển → hành động hiện có