- Helix là một trình soạn thảo văn bản kiểu modal chạy trong terminal, là dự án mã nguồn mở tích hợp các tính năng hiện đại
- Tích hợp Tree-sitter để cung cấp các tính năng chỉnh sửa nhận biết cú pháp như tô sáng cú pháp, tính toán thụt lề và điều hướng mã
- Hỗ trợ Language Server Protocol để mang đến các tính năng cấp độ IDE như tự động hoàn thành, đi tới định nghĩa, xem tài liệu và chẩn đoán
- Được viết bằng Rust, hoạt động không cần Electron hay JavaScript, và có thể sử dụng hiệu quả trong môi trường SSH·tmux·terminal
- Hệ thống plugin và frontend GUI được lên kế hoạch phát triển trong tương lai, với đặc trưng là codebase gọn nhẹ và cấu hình mặc định hiện đại
Các tính năng chính
- Helix lấy cảm hứng từ Kakoune và sử dụng hệ thống đa lựa chọn và con trỏ làm đơn vị chỉnh sửa cốt lõi
- Các lệnh có thể thao tác trên nhiều vùng chọn cùng lúc, cho phép chỉnh sửa mã song song
- Sử dụng Tree-sitter để tạo cây cú pháp có khả năng chịu lỗi
- Nhờ đó hỗ trợ tô sáng cú pháp chính xác, tự động thụt lề và điều hướng mã
Tính năng thao tác và điều hướng mã
- Cung cấp khả năng chọn và di chuyển theo đơn vị node trong cây cú pháp như hàm, lớp, chú thích
- Cho phép chỉnh sửa dựa trên cấu trúc cú pháp chứ không chỉ là văn bản thuần túy
- Thông qua Language Server Protocol (LSP), cung cấp các tính năng theo từng ngôn ngữ như tự động hoàn thành, đi tới định nghĩa, xem tài liệu, chẩn đoán
- Có thể tận dụng các tính năng cấp độ IDE ngay trong terminal mà không cần cấu hình bổ sung
Nền tảng kỹ thuật
- Được viết bằng Rust để đảm bảo độ ổn định và hiệu năng
- Không sử dụng Electron, VimScript hay JavaScript
- Có thể chạy trong SSH, tmux, terminal thông thường
- Cấu trúc nhẹ giúp cải thiện hiệu quả pin
Các tính năng hiện đại tích hợp sẵn
- Hỗ trợ fuzzy finder để tìm file và symbol, cùng với tìm kiếm trên toàn dự án
- Tích hợp nhiều tiện ích như tự động đóng ngoặc, surround tích hợp, tùy biến theme
- Cấu trúc tích hợp phong phú các tính năng cơ bản ngay cả khi không có plugin riêng
Câu hỏi thường gặp
- Cách diễn đạt “hậu hiện đại” mang ý đùa rằng nếu Neovim là ‘Vim hiện đại’ thì Helix là thế hệ sau đó
- Frontend GUI dự kiến sẽ được phát triển dưới dạng prototype dựa trên WebGPU trong tương lai
- Hiện tại hệ thống plugin vẫn chưa được triển khai, nhưng đã có kế hoạch đưa vào sau này
- Khác biệt với Kakoune là Helix tích hợp sẵn nhiều tính năng hơn và sử dụng phân tích mã dựa trên Tree-sitter
- Khác với Vim, Helix được thiết kế lại hoàn toàn từ đầu với codebase nhỏ gọn, đồng thời cung cấp giá trị mặc định hiện đại với nhu cầu chỉnh sửa file cấu hình ở mức tối thiểu
Cộng đồng và tham gia
- Có thể đóng góp mã nguồn trên GitHub
- Dự án thảo luận trên kênh Matrix
- Có thể tài trợ phát triển qua OpenCollective
1 bình luận
Ý kiến trên Hacker News
Tôi thấy thú vị khi thấy trò đùa “Post-modern?!”
Nhiều kỹ sư hiểu “postmodern” đơn giản là giai đoạn tiếp theo của modern, nhưng điều đó khác với nghĩa gốc của nó trong nghệ thuật và nhân văn
Tất nhiên cách dùng này không phải vấn đề lớn, nhưng vì tôi đã kỳ vọng một kiểu sáng tạo thật sự “hậu hiện đại”, nên nó vẫn khiến tôi chú ý
Nhưng vì “postmodernism” vốn là một khái niệm xuất hiện như phản ứng sau modernism, nên cách hiểu đơn giản là “sau modern” cũng không hẳn hoàn toàn sai
Chỉ là theo thời gian ý nghĩa của nó đã trở nên phức tạp hơn rất nhiều, và giờ nó lại buồn cười vì nghe giống kiểu “dated af”
“Helix, trình soạn thảo đầu tiên không tin vào đại tự sự. Helix, trình soạn thảo tương đối luận. Helix, tích hợp bản cập nhật mới nhất của Foucault và Derrida”
Tôi đã dùng Helix làm trình soạn thảo chính nhiều năm rồi (Sublime → Atom → Vim → Helix)
Phần lớn các LSP hoạt động gần như không cần cấu hình, và file cấu hình cũng gọn hơn nhiều so với .vimrc ngày xưa
Tôi chỉ mất vài ngày để đổi lại trí nhớ cơ bắp của Vim, nhưng vẫn có cảm xúc khá lẫn lộn về trình soạn thảo modal
Tôi vẫn đang chờ tính năng gập mã
Trong Emacs, tôi dùng multiple cursors và plugin dựa trên treesitter nên ngay cả cách làm không modal cũng vẫn chỉnh sửa rất mạnh
Không biết có phải vì lý do tương tự mà bạn thấy cách modal của Helix bất tiện không
Trên bàn phím Unix ngày xưa nó ở gần home row, còn bây giờ thì quá xa
Hầu hết hướng dẫn đều không nhắc đến phím thay thế, nên tôi vẫn không hiểu vì sao hơn một nửa người dùng vẫn cứ dùng Escape nguyên bản
Tôi thử dùng lại Helix vài ngày trước, và việc chỉ có thể dùng AI thông qua LSP thì cũng ổn
nhưng việc không tự động làm mới khi file bị thay đổi từ bên ngoài lại quá bất tiện
Nó khiến tôi cứ phải lo file mà AI sửa có đang là bản mới nhất hay không
Cách này ổn định và hấp dẫn hơn nhiều
Trong khi đó một số công cụ AI lại nói kiểu “không cần IDE”, thiên về CLI, và tôi thấy đó hoàn toàn là nhảm nhí
:reloadvà:reload-allTôi bind reload-all vào
Ctrl-rMột lựa chọn khác là mux, cho phép bình luận các thay đổi do LLM đề xuất theo từng dòng hoặc từng khối (vẫn còn ở giai đoạn đầu)
Khi làm việc với Claude Code, tôi thích việc file không tự động thay đổi
Vim là C, Helix là C++, còn Ki Editor giống Rust
Helix thừa hưởng nhiều ý tưởng từ Vim nhưng lại thiếu tính nhất quán trong keybinding, và khả năng kết hợp khái niệm cũng yếu hơn
Ví dụ trong buffer thì di chuyển bằng
k, nhưng trong trình duyệt file lại phải dùngctrl+nkđược dùng như ký tự nhập nên phải dùng phím khácCó lẽ Helix cũng vì lý do đó
Nếu SSH vào máy có bố cục bàn phím khác thì sao?
Tôi thật sự muốn thích Helix
Thiết lập mặc định rất tốt, và tôi còn cố tình bỏ bớt thói quen Vim để học nó
nhưng cuối cùng đi đến kết luận rằng keybinding là sự thỏa hiệp để đơn giản hóa triển khai
Giờ tôi quay lại dùng Neovim cho chỉnh sửa nhỏ, còn việc lớn thì dùng Zed (chế độ vim)
Ví dụ, mở lại file thì con trỏ không quay về vị trí cũ
Tôi có thể sửa bằng LLM, nhưng cuối cùng lại không muốn duy trì một bản fork của Helix
Vứt bỏ trí nhớ cơ bắp tích lũy qua nhiều năm thật sự rất khó
Tôi thấy bộ đôi hx + Zed khá tuyệt
Vì Helix không hỗ trợ cập nhật file trực tiếp, nên dùng cùng các code agent khá bất tiện
Hãy xem câu hỏi thứ hai trong FAQ của Helix
Python LSP hoạt động ngay mà không cần cấu hình nên rất ấn tượng
Nhưng vì 25 năm trí nhớ cơ bắp với Vim, những khác biệt tinh tế của Helix khiến tôi quá bối rối
Cuối cùng vấn đề không phải ở Helix mà là ở trí nhớ cơ bắp của tôi
nhưng cuối cùng tôi lại quen được cả hai bên
Tôi nghĩ Vim và Helix cũng có thể như vậy
M-ESC ESCthành một lệnh vô hại thì có thể tránh chuyện cửa sổ bị đóngVí dụ:
(global-set-key (kbd "M-ESC ESC") 'keyboard-quit)Chỉ cần quen với khác biệt như
dd,Glà dần dần sẽ thấy thích hơnTôi đã dùng Helix làm trình soạn thảo mặc định trong vài năm qua
Tôi đặc biệt thích sự đơn giản, tốc độ, điều hướng bằng bàn phím, và tích hợp Elixir LSP
Tôi đã dùng Helix làm chính và triển khai rất nhiều mã
File cấu hình của tôi chưa tới 50 dòng, chỉ thêm một vài phím kiểu Vim
Qua lại giữa Vim và Helix cũng không có vấn đề gì lớn
Cấu hình của tôi ở đây
Tôi từng tự làm một extension chế độ modal ngay trong VS Code, và thấy cách tiếp cận của Kakoune và Helix khá thú vị
Cấu trúc “cho xem trước phần sẽ bị thay đổi” và thiết kế xoay quanh multi-cursor nghe rất hợp lý
Nhưng sau vài tuần tôi cuối cùng vẫn quay lại phong cách Vim cổ điển
Cách dùng multi-cursor chỉ hữu ích khi có thể nhìn thấy toàn bộ thay đổi trên màn hình
Dạo gần đây nhờ AI mà tôi viết câu chữ nhiều hơn viết mã, nên cảm giác giá trị của kiểu chỉnh sửa này đã giảm đi
mc-hide-unmatched-lines, cho phép chỉ hiển thị các dòng có con trỏMulti-cursor tốt cho các chỉnh sửa ngắn và đơn giản, nhưng với sửa đổi phức tạp thì công cụ chỉnh sửa hàng loạt hiệu quả hơn
được tạo ra để giải quyết vấn đề con trỏ nằm ngoài màn hình