Cách sử dụng trình soạn thảo Helix cho phát triển trên máy chủ từ xa

 (rushter.com)
7 điểm bởi GN⁺ 2025-10-14 | 2 bình luận | Chia sẻ qua WhatsApp
  • Lý do chọn Helix làm trình soạn thảo cho phát triển trên máy chủ từ xa là vì có thể sử dụng mà không cần cài hàng chục plugin như Vim/Neovim, từ đó giảm rủi ro tấn công chuỗi cung ứng
  • Thông qua cấu hình tích hợp tmux, bài viết bù đắp những thiếu hụt của Helix về trình khám phá tệp và Git TUI, đồng thời thiết lập để có thể chạy yazi, lazygit dưới dạng cửa sổ bật lên
  • Chuyển các keybinding kiểu Vim để những thao tác như chọn dòng, di chuyển con trỏ, xóa văn bản hoạt động tương tự Vim, và đổi ESC thành phím khởi tạo lại multi-cursor
  • Bổ sung thông tin như nhánh Git, mã hóa, vị trí vào thanh trạng thái (statusline) để tăng năng suất
  • Tận dụng Tree-sitter injection để tô sáng cú pháp cho truy vấn SQL bên trong Python/Go, các khối mã trong Markdown, giúp cải thiện khả năng đọc
  • Tận dụng các cấu hình nâng cao như LSP, tự động lưu, chế độ màu để tăng hiệu suất làm việc và tùy biến chi tiết

Bối cảnh chọn Helix

  • Do các cuộc tấn công chuỗi cung ứng gia tăng gần đây và vấn đề phụ thuộc plugin, tác giả đã chọn Helix thay cho Vim/Neovim làm trình soạn thảo cho phát triển trên máy chủ từ xa
  • Ưu điểm chính là có thể dùng chỉ với tính năng mặc định mà không cần hàng chục plugin như Neovim
  • Sau khi chuyển sang Helix, tác giả đã tiến hành tùy chỉnh cấu hình để tái hiện tối đa trải nghiệm Neovim quen thuộc
  • Mục tiêu của việc chia sẻ này là giúp người dùng khác tiết kiệm thời gian

Cấu hình Tmux

  • Tác giả dùng Tmux làm terminal multiplexer và thêm các keybinding tùy chỉnh để giải quyết việc thiếu trình quản lý tệp và Git TUI
  • Helix không hỗ trợ chỉnh sửa tệp ngay từ trình khám phá tệp, nên khá bất tiện khi cần di chuyển nhanh giữa nhiều tệp
  • Thêm các binding sau vào tệp cấu hình Tmux
    • prefix - y: chạy trình quản lý tệp Yazi trong cửa sổ popup (95% kích thước màn hình)
    • prefix - g: chạy Lazygit trong cửa sổ popup
    • prefix - e: mở lịch sử đầu ra của Tmux bằng Helix để tìm kiếm và sao chép
  • Prefix mặc định là Ctrl + b, nhưng tác giả đổi sang Ctrl + \\ để sử dụng
  • Rất hữu ích cho các tác vụ xử lý đầu ra terminal, đặc biệt khi sao chép đầu ra ClickHouse client (CSV/JSON) sang Slack
    • Có thể sao chép trực tiếp thay vì xuất ra tệp, từ đó giảm bớt các bước thao tác
    • Dù có thể dùng chuột, việc cuộn buffer của Tmux khá bất tiện nên xử lý bằng trình soạn thảo hiệu quả hơn
  • Yazi và Lazygit thường được hiển thị dạng lớp phủ phía trên trình soạn thảo Helix

Chuyển keybinding Vim

  • Dù đã quen với keybinding của Helix, tác giả vẫn chuyển một số binding của Vim để tiếp tục sử dụng
  • Binding ở chế độ Select
    • 0: di chuyển đến đầu dòng
    • $: di chuyển đến cuối dòng
    • ^: di chuyển đến ký tự đầu tiên không phải khoảng trắng
    • G: di chuyển đến cuối tệp
    • D: chọn đến cuối dòng rồi xóa, sau đó chuyển sang chế độ normal
    • k/j: chọn toàn bộ dòng trên/dưới (hành vi mặc định của Helix là chọn một phần nên khá bất tiện)
  • Binding ở chế độ Normal
    • D: xóa toàn bộ văn bản bên phải con trỏ (Helix cần quá nhiều phím nên đã được chuyển sang kiểu Vim)
    • V: chuyển sang chế độ Select rồi chọn toàn bộ dòng
    • ESC: đặt lại multi-cursor (mặc định của Helix là dấu phẩy, khá bất tiện)
  • Vì không thích cách chọn dòng của visual mode trong Helix nên tác giả đổi sang kiểu Vim
    • Thiết lập để khi di chuyển lên/xuống, toàn bộ dòng được chọn

Thanh trạng thái được cải thiện

  • Thanh trạng thái mặc định thiếu một số thông tin quan trọng như nhánh Git hiện tại
  • Cấu hình thanh trạng thái
    • Bên trái: mode, spinner, quản lý phiên bản, tên tệp, chỉ báo chỉ đọc, chỉ báo đã sửa
    • Giữa: để trống
    • Bên phải: chẩn đoán, chẩn đoán của workspace, vị trí, tổng số dòng, phần trăm vị trí, mã hóa tệp, định dạng kết thúc dòng, loại tệp, thanh ghi, số lượng vùng chọn
    • Ký tự phân tách: dùng ký tự │
  • Có thể nắm bắt trạng thái công việc chỉ trong nháy mắt

Các keybinding hữu ích

  • Các keybinding tùy chỉnh đã cải thiện mạnh hiệu suất làm việc, nhưng mất khá nhiều thời gian để phát hiện ra
  • Các tính năng hữu ích nhất: reload tệp, bật/tắt soft wrap, Git undo, Git blame, Git diff
  • Danh sách đầy đủ các binding tùy chỉnh
    • space - e - w: lưu buffer hiện tại vào tệp
    • space - e - c: đóng buffer hiện tại
    • space - e - x: đóng tất cả buffer khác (rất hữu ích khi mở hàng chục buffer)
    • space - e - l: bật/tắt inlay type hint (hữu ích nhưng nếu luôn hiển thị thì khá nhiễu)
    • + - f: định dạng tệp hiện tại
    • + - w: render ký tự khoảng trắng (để kiểm tra ký tự vô hình trong tài liệu)
    • + - W: tắt render ký tự khoảng trắng
    • space - f - .: hiện/ẩn các tệp bị Git ignore trong file picker
    • space - f - r: reload tất cả tệp (rất hữu ích vì Helix không hỗ trợ tự reload; dùng cho thay đổi bên ngoài hoặc cập nhật gutter sau khi commit)
    • space - f - x: undo thay đổi Git tại vị trí con trỏ hiện tại
    • space - f - w: hiển thị Git blame của dòng hiện tại
    • space - f - d: hiển thị Git diff

Cấu hình trình soạn thảo

  • Sau 6 tháng sử dụng, tác giả mới phát hiện có tính năng tự động lưu khi chuyển tab terminal
  • Một số tính năng mới của Helix bị tắt theo mặc định, để tránh việc người dùng hiện tại gặp thay đổi ngoài dự kiến
  • Muốn khám phá tính năng mới thì phải tự kiểm tra từng tùy chọn
  • Các tùy chọn cấu hình chính
    • line-number = "relative": hiển thị số dòng tương đối
    • rulers = [120]: thiết lập thước dọc trực quan (hữu ích khi giới hạn độ dài dòng tối đa mà không dùng auto-format)
    • true-color = true: ép hỗ trợ true color
    • completion-replace = true: tự động hoàn thành sẽ thay thế toàn bộ từ
    • trim-trailing-whitespace = true: xóa khoảng trắng cuối dòng
    • color-modes = true: phân biệt chế độ bằng màu sắc
    • rainbow-brackets = true: dùng màu khác nhau cho ngoặc lồng nhau (tính năng mới, chưa phát hành chính thức)
    • editor.file-picker.hidden = false: hiển thị tệp ẩn (dot files) trong file picker
    • editor.indent-guides.render = true: thêm đường dẫn hướng thụt lề trực quan
    • editor.inline-diagnostics.cursor-line = "warning": cải thiện hiển thị chẩn đoán (xem ảnh chụp màn hình)
    • editor.auto-save.focus-lost = true: tự động lưu khi mất focus (cần terminal hỗ trợ)
    • editor.auto-save.after-delay.enable = true: tự động lưu sau một khoảng trễ được chỉ định (đặt là 300 giây)

Điều chỉnh LSP

  • Thêm harper-ls LSP cho mọi ngôn ngữ để tô sáng lỗi ngữ pháp trong phần chú thích

Tree-sitter injection tùy chỉnh

  • Helix cho phép chỉ định Tree-sitter injection tùy chỉnh, nhờ đó có thể tô sáng một ngôn ngữ bên trong ngôn ngữ khác
  • Các trường hợp sử dụng
    • Tô sáng cú pháp cho truy vấn SQL bên trong Python và Go
    • Tô sáng YAML front matter và code block trong Markdown
    • Cũng có thể dùng để tô sáng HTML snippet
  • Tác giả đã tải tệp cấu hình lên GitHub để chia sẻ cấu hình và custom injection
  • Helix là trình soạn thảo terminal thế hệ mới nổi bật với các ưu điểm giảm tối đa plugin, bảo mật cao và tùy biến trực quan

Bài viết liên quan

2 bình luận

 
xguru 2025-10-14

Nhà phát triển đã dùng Vim suốt 20 năm chia sẻ trải nghiệm sau khi chuyển từ Vim sang Helix
 
GN⁺ 2025-10-14
Ý kiến Hacker News

  • Gần đây tôi đang dựng lại cấu hình editor. Tôi đã dùng song song Emacs suốt 20 năm và Vim suốt 15 năm, nên không thể chọn hẳn một cái. Mục tiêu là xem có thể tạo ra một bộ cấu hình hoàn thiện nhanh đến mức nào để dùng ngay cho công việc phần mềm Python cấp doanh nghiệp. Lần này tôi đặc biệt thử giảm tối đa sự phụ thuộc vào tiện ích mở rộng bên thứ ba và chỉ giữ lại những tính năng cần thiết. Hiện tại tôi nghĩ cấu hình Neovim của mình là tốt nhất trong số những gì tôi từng dùng, nhưng rốt cuộc vẫn phải dùng nhiều plugin hơn dự kiến. Với Emacs thì vẫn còn ở giai đoạn đầu, nhưng điều thú vị là từ bản 30 trở lên nó đã tiến bộ rất nhiều, đến mức nhu cầu dùng plugin bên thứ ba giảm mạnh. Trước đây tôi dùng lsp-mode, còn giờ thì hài lòng với Eglot. completion preview mode chưa thay thế hoàn toàn corfu, nhưng cũng khá ổn. Danh sách plugin thiết yếu của tôi trong Emacs là Magit, Expreg(teeesitter expand region), Multiple cursors, dape(gỡ lỗi tích hợp với Eglot). Có lẽ tôi cũng sẽ thêm Consult và orderless. Cấu hình Neovim của tôi có thể xem tại đây

    • nvim mới cũng đang dần giảm nhu cầu plugin. Nó đã có sẵn plugin manager, trình xem diff và lsp

    • Bạn đang quản lý khá nhiều plugin nvim đấy! Tuần trước tôi đã viết lại cấu hình nvim của mình chỉ với 4 plugin, có cả mini.nvim. Tôi cảm nhận rất rõ rằng khi gắn quá nhiều plugin thì độ ổn định và độ tin cậy của nvim giảm hẳn. Nghe mà ghen tị vì Emacs chỉ cần 2 cái, chắc chắn như vậy sẽ chạy ổn định hơn nhiều. Cấu hình của tôi có thể xem tại đây

    • Tôi tò mò không biết sau khi dùng vài tháng, bạn có thấy nó đạt đến mức tương đương với cấu hình mặc định của Pycharm+IdeaVIM không. Tất nhiên việc tự tay chỉnh cấu hình cũng vui, nhưng nếu chỉ tập trung vào mục tiêu dùng IDE hiệu quả thì dành quá nhiều thời gian cho cấu hình Neovim có vẻ hơi kém hiệu quả

    • Expreg(teeesitter expand region) làm tôi nhớ đến combobulate(chưa dùng thử nhưng trông rất hay). Tuy vậy Expreg có vẻ đơn giản và nhẹ hơn nhiều

    • Tôi thật sự rất tò mò về trải nghiệm của những người đã dùng Emacs lâu năm. Tôi muốn biết nó thế nào khi so với Helix/Vim. Những người mới dùng Helix/Vim lần đầu thường khen lắm, nhưng có vẻ họ nói vậy vì chưa biết hết giá trị của Emacs dùng lâu năm. Đúng là các phím kiểu Vim hay chế độ modal có vẻ được tích hợp tốt hơn trong editor hiện nay, nhưng khi thật sự dùng thì tôi lại thiếu kiên nhẫn để chịu đựng cho đến lúc ngón tay quen hẳn. Tôi rất muốn nghe trải nghiệm chuyển đổi của một người dùng Emacs thật hardcore

  • Tôi là người đã chuyển từ Emacs → VS Code → Helix. Từ trước đến nay tôi luôn cố gắng học các keybinding sẵn có và dùng thật hiệu quả mà gần như không đụng vào cấu hình. Vì quá khó để nhớ mọi thứ Helix có thể làm, tôi đã tự làm một deskmat in các phím tắt để đặt trên bàn. Chắc phải in ra dùng thật mới biết có giúp ích bao nhiêu. Deskmat của tôi có thể xem tại đây

    • Tôi tò mò không biết bạn đã dùng Emacs bao lâu rồi

  • Tôi đã dùng Emacs làm editor chính suốt 10 năm qua, trước đó thì dùng Sublime Text. Thỉnh thoảng tôi vẫn dùng Vim để sửa file đơn giản hoặc làm việc trên server từ xa, nhưng chưa bao giờ thấy cần phải dùng riêng Vim hoàn toàn. Tôi đã tạo các module và hàm riêng trong Emacs để có môi trường đúng ý mình. Tháng trước tôi thử Helix và thấy việc bắt đầu đơn giản đến bất ngờ. Tôi cũng nhanh chóng quen với những thao tác cơ bản—di chuyển, tìm kiếm, dán, chuyển buffer/window. Tôi không biết nhiều về lịch sử của Helix, nhưng thiết kế của nó rất xuất sắc. Tìm kiếm toàn cục đặc biệt tốt, tích hợp lsp hoạt động vừa khít, và tốc độ thì cực nhanh. Cảm giác các giá trị mặc định được chọn rất nhất quán và hữu ích thật sự rất dễ chịu. Tôi định tiếp tục dùng đều để quen hơn; editor mặc định của tôi vẫn là Emacs, nhưng Helix nhanh đến mức có thể trở thành editor chính để viết code

  • Tôi đang dùng Helix lần đầu và thấy có hai nhược điểm khá lớn

    • Chỉnh sửa modal là điểm cốt lõi, nhưng với Vim thì bạn có thể mang nguyên muscle memory đã có đi dùng ở bất cứ đâu (Vim mode có gần như khắp nơi, nhiều extension như Vimium cũng vậy, và trong môi trường ssh thì gần như chắc chắn có Vim)
    • Helix hướng đến sự đơn giản nên không có tích hợp terminal, khả năng mở rộng bằng plugin cũng chưa cao (ngay cả lint cũng chỉ hỗ trợ theo nền lsp), mà tổ hợp như vậy có nghĩa là bạn phải tự dựng thêm một lớp setup bên trên editor, nên có vẻ sẽ có giới hạn(cần dùng tmux chẳng hạn) Tôi không có ý chê các nhược điểm đó, chỉ là muốn biết điểm mạnh nào đủ để bù lại

    • Tôi không hiểu vì sao LSP lại là nhược điểm. Nó giống như LSP chạy thành tiến trình riêng, mà như vậy tôi còn nghĩ là tốt cho việc sandbox plugin. Trên thực tế có khi nó còn hoạt động tốt hơn plugin của các editor truyền thống. Việc không có tích hợp tmux cũng không ảnh hưởng với tôi, dù tôi chủ yếu dùng Emacs, vì tôi hầu như không bao giờ dùng terminal bên trong. Chỉ cần chuyển được muscle memory thì một editor nhanh viết bằng rust đã đủ thuyết phục rồi

    • Có người nói Vim motions có thể học thành muscle memory rồi dùng ở khắp nơi, nhưng thực tế gần như chẳng có developer nào muốn dùng nguyên môi trường Vim mặc định mà không có plugin hay cấu hình. Hầu hết đều muốn một editor với setup và tính năng được tinh chỉnh theo ý riêng. Ngoại lệ có lẽ chỉ là những người thật sự ssh vào nhiều máy khác nhau và cần đúng môi trường editor mặc định. Bạn có nhắc đến sự đơn giản của Helix và việc nó bị hạn chế plugin; ban đầu Helix hướng tới một editor all-in-one, nhưng cộng đồng không muốn thế nên hiện nay hệ thống plugin đang được phát triển. Nó chưa có trong bản phát hành chính, nhưng ở nhánh riêng đã có nhiều plugin được tạo ra và sử dụng. Tôi nghĩ trì hoãn phát hành cho đến khi hệ thống plugin đủ ổn định là lựa chọn đúng. Điểm mạnh lớn nhất của Helix là nó cải thiện UX bất tiện còn sót lại trong vi/vim/neovim. Cụ thể là nó đảo thứ tự thao tác, giúp bạn dễ xem phần sẽ thay đổi trước khi commit, từ đó giảm tác dụng phụ ngoài ý muốn

  • Với mức cấu hình này thì có lẽ dùng luôn vim sẽ tốt hơn. Bạn đang cố tái tạo tính năng vim bên trong Helix, trong khi Helix cũng có nhiều phụ thuộc nội bộ(không lộ ra bề mặt như nvim thôi). Cấu hình vim8 của tôi đã được giữ đơn giản hơn 8 năm rồi. Tôi dùng vim8 vì đó là phiên bản có trong các bản phân phối LTS. Chỉ có một plugin được tự động tải(vim-tmux-navigator để di chuyển dễ dàng giữa cửa sổ chia của vim và tmux), tôi đã xem mã và không cập nhật nữa. Hai plugin “tùy chọn” thì dùng package manager tích hợp của vim và chỉ bật bằng :packadd! khi cần. Tôi chỉ dùng ale(lsp, chẩn đoán, tự động format khi lưu) và vim-fugitive(tích hợp git). ale không có phụ thuộc. vim-fugitive thì chỉ cần cài một lần rồi dùng thôi. Lý do tôi không tự động tải plugin là vì vim thường được dùng để chỉnh sửa nhanh, và chỉ trong các dự án dài hạn tôi mới bật git/lsp. Plugin không cần thiết thì không nhất thiết phải dùng

    • Tôi cũng thích Neovim hiện đại nên đang giải quyết vấn đề này bằng cách tạo một gói python(đặc biệt phù hợp với những ai đã ở trong hệ sinh thái python hoặc dùng uv, pipx). Bạn có thể cài Neovim mới nhất bằng uv tool install binwheels-neovim hoặc pipx install binwheels-neovim, và nó chạy ngay trên Windows, mac, Linux. Gói này bọc quanh bản phát hành chính thức của Neovim rồi dùng uv hoặc pipx để lấy binary phù hợp với hệ điều hành/kiến trúc. Với Linux thì cần hỗ trợ GLIBC cũ hơn bản phát hành chính thức nên tôi build riêng để cung cấp. Xem thêm ở PyPI, Github chính, log build

    • So với nvim+plugin, Helix có bề mặt tấn công chuỗi cung ứng nhỏ đến mức cực kỳ thấp. Mọi thứ được quản lý như một khối thống nhất trong chính Helix, nên an toàn hơn nhiều so với nvim nơi mỗi plugin lại có một nhà cung cấp riêng. Helix cũng phát hành chậm và cẩn trọng, nên nếu có lỗ hổng thì khả năng trở thành vấn đề lớn cũng thấp hơn

    • Mô hình chỉnh sửa của Helix tốt hơn

  • Nếu cần TUI khi dùng Helix, tôi tò mò vì sao lại chọn Helix thay vì neovim. Tôi thích các giá trị mặc định của Helix, nhưng đến một lúc nào đó khi phát sinh những chỗ cần thay đổi thì cảm giác ngày càng phiền phức. Và nếu muốn có “trải nghiệm IDE đầy đủ” với Helix thì tôi cũng không rõ vì sao không dùng Zed, VSC hay IDE của JetBrains. Khi cần thứ đơn giản tôi dùng nvim, còn khi cần nhiều tính năng hơn thì mở WebStorm, hoặc nếu đồng nghiệp cần tìm gì thì tôi dùng cùng cái đó với họ

    • Khi làm việc qua ssh trên máy cấu hình yếu, helix khởi động gần như tức thì. Nếu dựng cùng mức tính năng đó bằng nvim thì sẽ chậm hơn và chi phí quản lý cập nhật cấu hình/plugin cũng cao hơn. Ngoài ra tôi biết rust nên cũng có thể đóng góp sửa lỗi. Tôi không biết ngôn ngữ họ C nên thích các dự án mã nguồn mở được viết bằng ngôn ngữ mình biết. Tôi là lập trình viên hobby đã chỉ dùng n/vim suốt 12 năm rồi chuyển sang helix trong 2 năm gần đây. Thật ra vẫn có nhiều thứ ở nvim mà tôi nhớ hoặc thấy tự nhiên hơn, nhưng helix đúng là “chạy phát ăn ngay”, và cảm giác dễ chịu đó lấn át tất cả

    • Trong vài năm qua tôi đã dùng neovim, helix, emacs và nano mỗi thứ trong một thời gian, và trải nghiệm out-of-the-box của helix vượt trội nhất. Giá trị mặc định của nó thật sự rất tốt, phần trợ giúp và gợi ý theo ngữ cảnh cũng cực kỳ ổn nên bạn có thể quên các lệnh dùng thường xuyên, còn lệnh ít dùng thì cũng dễ tìm lại. Thêm nữa, trong đầu tôi thứ tự thao tác lệnh của helix tự nhiên hơn vim. Các editor hiện đại như nvim/spacemacs có rào cản plugin/cấu hình quá cao. Nhờ hệ sinh thái plugin thì có thể làm được những việc helix hiện chưa làm được(ví dụ: emacs có thể dùng bất kỳ ngôn ngữ lisp nào như một IDE còn helix thì không thể nạp repl), nhưng đổi lại bạn không chỉ phải học editor mà còn phải học vô số plugin, và kể cả khi tìm kiếm thì câu trả lời cũng khác nhau theo từng phiên bản/tổ hợp nên rất rối. Khi làm mới, cuối cùng bạn hoặc phải tin lời khuyên của người khác, hoặc phải tự dùng thử rồi mất thêm thời gian học. Helix là dự án mới nên không bị gánh nặng từ các quyết định ngày xưa, và có thể chọn các quyết định cùng giá trị mặc định phù hợp với kiểu phát triển hiện đại. Nó không hoàn hảo, nhưng nếu một người mới với TUI muốn có thứ dùng được ngay bây giờ và dễ bắt đầu mà không cần cấu hình, tôi sẽ giới thiệu helix

    • hx khởi động nhanh, chạy cũng nhanh mà còn đẹp nữa. Giá trị mặc định của nó cũng khá thỏa mãn nên tôi chỉ chỉnh rất nhẹ; khác với emacs/neovim nơi tôi cứ mãi mắc kẹt trong vòng lặp cải tiến vô tận, hx cho cảm giác là có điểm dừng. TUI cũng hoạt động tốt trên server từ xa, nên tôi dùng cùng một môi trường ở mac, linux, server ở mọi nơi(dù editor khác cũng có thể làm vậy, nhưng hx cũng hỗ trợ rất tốt). Nó hỗ trợ đầy đủ mọi lsp tôi cần, và việc cấu hình languages.toml có hơi phiền một chút, nhưng cấu hình ở editor khác cũng vậy thôi

    • Tôi thích cấu hình đơn giản và selection-first editing model. Tài liệu tham khảo liên quan ở đây. Nói chuyện với những người gặp khó khăn khi làm quen với Vim, tôi nhận ra có lẽ ngay từ đầu tôi đã quen với mô hình “chọn trước” kiểu Helix. Tôi thấy khó thích nghi với những thao tác kiểu Vim, nơi văn bản đích không hiện ra ngay(nghĩa là sau khi ra lệnh mới thấy phạm vi bị tác động)

    • Việc chọn editor không hẳn là một quyết định cực kỳ hợp lý; các yếu tố tâm lý như sở thích cá nhân, cảm giác mới mẻ hay niềm vui thường lớn hơn nhiều

  • Hôm nay tôi mới biết lệnh :reset-diff-change. Trước giờ tôi chỉ dùng checkout -p trong git, nhưng làm trực tiếp trong Helix tiện hơn nhiều

  • Tôi đã thử dùng Helix, nghiêm túc luyện tập và giờ có thể dùng khá thành thạo. Nhưng rồi tôi nhận ra chính “luồng công việc đảo ngược” này, dù dễ học và dễ triển khai, lại làm tôi chậm đi khi sử dụng thực tế. Thế là cuối cùng tôi quay lại Vim, rồi sang Zed(Vim mode)

  • Hôm nay tôi mới dùng Helix lần đầu, và đúng là một editor được thiết kế rất tốt. Tuy vậy tôi vẫn tiếc vì thiếu những phím tắt thao tác nhanh của Vim như y2$, dw

    • Thực ra không phải là không có phím tắt; y2$ có thể viết là 2xy, còn dw thì dùng wd

  • Tôi vẫn chưa tìm ra cách xóa dòng hiện tại trong Helix mà có cả dòng trống. xd sẽ xóa một dòng khi đó là dòng không rỗng, nhưng nếu là dòng trống thì lại xóa cùng lúc hai dòng

    • x là chọn dòng hiện tại, còn nếu đã chọn rồi thì mở rộng sang dòng tiếp theo. X sẽ mở rộng vùng chọn theo ranh giới dòng(line-wise selection). Hãy dùng X

    • Với dòng trống thì chỉ cần dùng d

    • Khá khó chịu một cách âm thầm đấy. Tôi cũng đang chạy một fork rất nhỏ chỉ để đổi hành vi của x khi gặp dòng trống. Xem chi tiết ở PR này