Khám phá tác động của Bram Moolenaar qua Vim: chỉnh sửa theo mode, workflow có thể lặp lại và thói quen cộng đồng đã định hình năng suất lập trình suốt nhiều thập kỷ.
Bram Moolenaar tạo ra Vim như một phiên bản cải tiến của trình soạn thảo vi cổ điển, nhưng lý do Vim tồn tại được hàng thập kỷ không chỉ là vì kỹ thuật. Vim trở thành một cách làm chung — một phương pháp viết và sửa văn bản lan ra qua các nhóm, hướng dẫn và dự án mã nguồn mở. Sau khi Bram qua đời, nhiều bài tưởng niệm nhấn mạnh điểm này: Vim không chỉ là phần mềm mọi người dùng; nó là thứ mọi người học và mang vào nghề mỗi ngày.
Khi các lập trình viên nói về “văn hóa trình soạn thảo”, họ mô tả nhiều thứ hơn là sở thích cá nhân. Đó là tập hợp thói quen và chuẩn mực xung quanh một công cụ:
Văn hóa này quan trọng vì nó hình thành hành vi. Hai người mở cùng một file trong cùng trình soạn thảo có thể di chuyển với tốc độ hoàn toàn khác nhau — không phải vì năng khiếu, mà vì thói quen luyện tập.
Đây không phải một bách khoa lệnh. Thay vào đó, bạn sẽ học các mẫu workflow mà Vim phổ biến: cách người ta xây thói quen chỉnh sửa có thể lặp lại, giảm ma sát khi thực hiện các thay đổi nhỏ, và giữ định hướng khi làm việc trong file lớn.
Bạn không cần phải là “người dùng Vim” hay có nền tảng kỹ thuật để theo dõi. Chúng tôi sẽ giữ thuật ngữ ở mức nhẹ, giải thích ý tưởng bằng ngôn ngữ đơn giản và tập trung vào lý do các thói quen này có ý nghĩa — ngay cả khi bạn dùng một trình soạn thảo khác hôm nay.
Bram Moolenaar (1961–2023) gắn chặt với bản sắc của Vim — không phải vì Vim là dự án của một người, mà vì ông giữ vai trò điều phối ổn định giúp một công cụ do tình nguyện viên phát triển vẫn có tính nhất quán qua nhiều thập kỷ.
Gốc rễ của Vim bắt nguồn từ truyền thống trình soạn thảo vi. Bram bắt đầu dự án vào cuối những năm 1980 khi làm việc trên Commodore Amiga, ban đầu như một phiên bản cải tiến của một trình soạn thảo giống vi. Từ đó, Vim nhanh chóng lớn hơn nguồn gốc: các bản phát hành đầu những năm 1990 mở rộng tính năng và khả năng di động, và khi Unix, Windows, rồi macOS và Linux trở thành môi trường phổ biến, Vim xuất hiện hầu như khắp nơi.
Phạm vi đa nền tảng đó quan trọng. Một công cụ hoạt động tương tự trên máy ở nhà, phòng thí nghiệm đại học và server nơi làm việc tạo được niềm tin — và niềm tin đó đã giúp Vim trở thành mặc định tồn tại lâu dài cho cả chuyên gia và người dùng nghiệp dư.
Các dự án mã nguồn mở thường kết thúc lặng lẽ khi điều phối khó hơn viết code. Đóng góp then chốt của Bram là xem việc bảo trì như một nghề: xem xét patch, hướng dẫn phát hành, giữ tài liệu và hành vi nhất quán, và định hình các chuẩn mực hợp tác. Nhiều đóng góp cải thiện Vim, nhưng trình soạn thảo vẫn giữ được “cảm giác” nhận diện vì có người giữ toàn bộ hệ thống đi cùng nhau.
Vim cũng nổi tiếng là “charityware”. Ý tưởng đơn giản: nếu bạn thấy Vim hữu ích, hãy cân nhắc quyên góp cho các tổ chức từ thiện Bram ủng hộ. Đó không phải rào cản trả tiền và không bắt buộc để dùng trình soạn thảo; nó là một khuyến khích nhẹ nhàng để cho đi — một tín hiệu sớm rằng văn hóa phần mềm có thể bao gồm sự hào phóng, không chỉ tối ưu.
Hành trình dài của Vim cuối cùng là câu chuyện về tính liên tục: một trình soạn thảo vẫn có liên quan không phải bằng cách đuổi theo xu hướng, mà bằng cách tiến hóa cẩn trọng trong khi giữ cộng đồng — và các giá trị — nguyên vẹn.
Điểm đặc trưng nhất của Vim là các mode: cùng một phím làm các việc khác nhau tuỳ vào bạn đang làm gì. Nghe có vẻ lạ cho đến khi bạn nhận ra nó phản chiếu cách bạn làm việc — đôi khi bạn suy nghĩ về thay đổi, và đôi khi bạn gõ văn bản mới.
Normal mode để thực hiện hành động chỉnh sửa: di chuyển, xoá, thay đổi, tìm kiếm. Bạn không “gõ”; bạn chỉ đạo.
Insert mode để gõ ký tự vào tài liệu — điều mà hầu hết trình soạn thảo coi là mặc định.
Visual mode để chọn văn bản rồi thao tác (thụt lề, xoá, đổi, copy).
Ví dụ đơn giản:
dd để xóa một dòng.i để vào Insert mode và gõ nội dung mới.Esc để về Normal mode.v để bắt đầu Visual mode, di chuyển chọn, rồi nhấn d để xóa vùng chọn.Khi mọi thứ luôn sẵn sàng để gõ, bạn dễ trộn hai nhiệm vụ khác nhau: soạn nội dung và ra lệnh sửa. Chỉnh sửa theo mode tách chúng ra.
Ở Normal mode, tay bạn không liên tục “bị bật” để chèn ký tự vô tình. Thay vào đó, bạn giữ sự có chủ ý: Tôi muốn thay đổi gì? Xoá cái này, đổi cái kia, đi đến đó, lặp lại. Insert mode trở thành khoảnh khắc tập trung: Bây giờ tôi đang thêm văn bản.
Theo thời gian, điều này có thể khiến trải nghiệm ít như đấu tranh với trình soạn thảo và hơn như đưa ra các chỉ dẫn nhỏ, rõ ràng.
Những khó khăn ban đầu phổ biến có thể dự đoán được:
x hoặc dd.)i.)Diễn đạt lại mode như trạng thái của ý định. Normal mode không phải là “không hoạt động” — nó là mode bạn chỉnh sửa có chủ ý. Đó là thói quen mà chỉnh sửa theo mode dạy bạn: trước hết sửa đổi có chủ ý, sau đó mới gõ.
“Siêu năng lực” của Vim không phải là một menu khổng lồ tính năng — mà là cách các lệnh nhỏ ghép lại với nhau. Thay vì ghi nhớ một phím tắt riêng cho mỗi tình huống, bạn học vài khối xây dựng và kết hợp chúng.
Hãy nghĩ chỉnh sửa như một động từ áp lên một đoạn văn bản.
Trong ngôn ngữ Vim, động từ là operator (như d cho delete, c cho change), và đối tượng là motion/text object (như w cho word, ) cho câu, i" cho bên trong dấu nháy).
Một vài kết hợp cho thấy lý do tại sao điều này quan trọng:
cw — “change” + “word”. Bạn không cần chọn trước; bạn nói rõ ý định.di" — “delete” + “inside quotes”. Giữ nguyên dấu nháy và chỉ xoá nội dung bên trong.v rồi một thứ như i{ — vào chọn visual + “inside braces” để lấy phần trong một khối { ... }.Mục tiêu không phải gom mẹo. Mà là xây một mô hình tư duy nơi các lệnh dự đoán được.
Tính tổ hợp thưởng cho độ chính xác và nhất quán. Khi cùng một động từ dùng được với nhiều đối tượng, bạn đoán ít hơn, undo ít hơn, và cảm thấy bình tĩnh hơn khi làm việc trong file lạ. Tốc độ thường sẽ theo sau — không phải vì bạn cố gắng nhanh, mà vì bạn lặp đi lặp lại một cách nghĩ về văn bản đáng tin cậy.
Một trong những ý tưởng thực dụng nhất của Vim là chỉnh sửa không nên là màn trình diễn một lần. Nếu bạn mô tả một sửa đổi một lần, bạn nên có thể lặp lại nó — một cách đáng tin cậy — trên dòng tiếp theo, đoạn tiếp theo, hoặc file khác. Đây là nơi “tốc độ” trở nên ít liên quan đến gõ nhanh và nhiều hơn là giảm mệt mỏi ra quyết định.
Lệnh chấm (.) phát lại thay đổi bạn vừa làm. Nghe nhỏ, nhưng nó khuyến khích bạn làm các sửa theo từng mẩu gọn và có thể lặp lại.
Ví dụ: bạn thay foo thành foo() trên một dòng bằng cách chèn dấu ngoặc. Ở lần xuất hiện tiếp theo, bạn thường có thể di chuyển con trỏ đến chỗ thích hợp và nhấn . thay vì làm lại toàn bộ chèn. Thói quen: làm một chỉnh sửa cẩn thận, rồi lặp lại.
Macro cho phép bạn ghi lại một chuỗi phím và phát lại. Về mặt khái niệm, giống như nói: “Khi gặp mẫu này, áp dụng các bước này.” Một cách dùng đơn giản an toàn là format một danh sách:
- vào đầu nhiều dòngTránh tự động hoá quá mức khi văn bản không nhất quán. Nếu mỗi dòng cần một quyết định khác nhau (“đôi khi thêm, đôi khi xoá”), macro có thể tạo ra lỗi nhanh hơn bạn phát hiện.
Tìm kiếm vốn là một công cụ điều hướng; thay thế là tìm kiếm cộng hành động. Nghĩ theo cách đơn giản: “Tìm chuỗi này, thay bằng chuỗi kia”, như đổi temp thành draft trong một file. Nếu thay đổi có thể ảnh hưởng tới văn bản không liên quan, hãy xác nhận từng lần thay vì áp dụng ồ ạt.
Bài học lớn hơn: xây các công thức lặp cho những chỉnh sửa thường xuyên. Theo thời gian, workflow của bạn trở thành thư viện các bước nhỏ, đáng tin cậy hơn là một chuỗi sửa lỗi ngẫu hứng.
Phong cách ưu tiên bàn phím của Vim không phải bài kiểm tra độ tinh khiết, và không làm ai đó trở thành “lập trình viên giỏi hơn”. Điểm mấu chốt đơn giản: mỗi lần bạn với chuột hoặc trackpad, bạn phá vỡ một vòng chú ý nhỏ — tay rời hàng phím, mắt tìm con trỏ, và não chuyển ngữ cảnh từ “làm gì” sang “ở đâu”. Giảm các gián đoạn đó giúp bạn dễ giữ dòng suy nghĩ về vấn đề đang giải quyết.
Vim thúc đẩy bạn điều hướng văn bản theo cách bạn suy nghĩ về nó:
w, b, e, )), khi bạn đang chỉnh sửa văn bản hoặc identifier.0, ^, $, gg, G), khi cấu trúc quan trọng./, ?, n, N), khi bạn săn tìm ý định.:e, :b, tags/LSP jumps), khi thay đổi lan khắp codebase.Theo thời gian, “di chuyển đến cái cần làm” trở thành phản xạ thay vì một quyết định nhỏ mỗi lần.
Lợi ích thực sự không phải cắt vài mili-giây; mà là loại bỏ do dự. Những động tác nhỏ, lặp lại — như thay “bên trong dấu nháy” hay xoá “đến dấu phẩy tiếp theo” — trở thành phím tắt thể xác cho các chỉnh sửa phổ biến. Khi những mẫu đó vào cơ bắp, bạn dùng ít năng lượng tinh thần để điều khiển trình soạn thảo và nhiều năng lượng hơn để chọn thay đổi đúng.
Luồng làm việc bằng bàn phím có thể giảm di chuyển cổ tay với một số người, nhưng cũng có thể tăng tải cho ngón tay với người khác. Lợi ích công thái học thay đổi theo người, layout bàn phím và lựa chọn lệnh. Văn hóa tùy chỉnh của Vim hữu ích ở đây: map lại phím khó chịu, chia đều việc dùng, và ưu tiên thoải mái hơn là lý tưởng. Mục tiêu là tập trung bền vững, không phải chịu đựng lâu dài.
Vim luôn khuyến khích sở hữu. Thay vì coi trình soạn thảo như sản phẩm đóng, nó coi như bộ dụng cụ — điều bạn tinh chỉnh cho đến khi phù hợp với cách bạn tư duy.
Một vimrc là file cấu hình của Vim. Nơi bạn đặt mặc định: tab hoạt động thế nào, có quấn dòng không, dòng trạng thái hiển thị gì, v.v. Theo thời gian, nhiều lập trình viên giữ các thiết lập này trong version control như một phần của “dotfiles”, để trình soạn thảo quen thuộc trên mọi máy.
Điều này không chỉ là cá nhân hóa cho vui. Nó trở thành quy ước văn hoá vì các mặc định nhỏ cộng dồn lại: ít ma sát hơn, ít ngạc nhiên hơn, và ít câu hỏi “tại sao Vim đang làm vậy?”
Cách dễ nhất để có một setup lộn xộn là cài mười plugin trước khi hiểu bạn đang giải quyết vấn đề gì. Cách tốt hơn:
Đối xử với vimrc như nhật ký xưởng, không phải tủ đồ linh tinh.
Một mapping là phím tắt: bạn nhấn một tổ hợp và Vim thực hiện chuỗi lệnh dài. Mapping tốt giảm lặp; mapping tệ làm Vim mất nhất quán.
Một plugin thêm tính năng: trình tìm file, trợ giúp Git, hỗ trợ ngôn ngữ tốt hơn. Plugin có thể tuyệt, nhưng cũng thêm chi tiết chuyển động, thời gian khởi động và hành vi mới để học.
Trước khi thêm tiện ích, làm quen với vài mặc định:
Khi baseline đó tự nhiên, plugin là nâng cấp có chủ đích — không phải để thay thế việc học Vim cơ bản.
Văn hóa Vim không bắt đầu bằng plugin hay phím tắt — nó bắt đầu bằng việc học. Bram Moolenaar coi tài liệu như một phần sản phẩm, và thái độ đó định hình cách người ta dạy Vim: không phải như bí kíp, mà như kỹ năng bạn có thể từng bước phát triển.
:help của Vim không phải thứ phụ; nó là bản đồ. Nó thưởng cho sự tò mò bằng cấu trúc — chủ đề, tham chiếu chéo và ví dụ giả định bạn sẽ khám phá.
Một vài thói quen nhỏ biến “Tôi bị kẹt” thành “Tôi biết tìm chỗ cần xem”:
:help {topic} (hoặc :h) để nhảy đến khái niệm như :h motion hoặc :h visual-modeCTRL-] để theo liên kết trong help, và CTRL-T để quay lại:helpgrep {word} để tìm trong toàn bộ docs khi bạn không biết thuật ngữ chính xácMô hình này mở rộng: một khi bạn biết cách hỏi trình soạn thảo, bạn bớt phụ thuộc vào việc ghi nhớ từng mục.
Mentorship trong Vim thường là những can thiệp nhỏ, tôn trọng: một mapping, một motion, một chỉnh workflow. Quy tắc bất thành văn là “đi gặp người ta ở nơi họ đang đứng”. Thường thấy mẹo kèm câu “Nếu editor bạn đang dùng đã ổn, cứ giữ tiếp.”
Các chuẩn mực khác cũng thực tế:
Kiến thức Vim truyền qua các artefact nhẹ: cheat sheet, lightning talk, template dotfile và repo “starter” nhỏ. Cái hay là những tài liệu giải thích tại sao thói quen hữu ích, không chỉ gõ gì.
Có người chỉ cần Vim để sửa nhanh qua SSH; người khác dựng môi trường làm việc hàng ngày quanh nó. Văn hóa Vim hoạt động khi nó coi cả hai mục tiêu là hợp lệ — và giữ lối đi giữa chúng sáng sủa.
Danh tiếng “sức mạnh” của Vim thường được nói đến, nhưng giá trị thực sự thể hiện ở những khoảnh khắc bình thường: một commit message cần rõ ràng hơn, một file cấu hình production cần sửa an toàn, hoặc phiên pair nơi bạn muốn edit chính xác và dễ giải thích.
Chỉnh sửa commit: Nhiều dev cấu hình Git để mở Vim cho commit message và interactive rebase. Modal editing hợp vì bạn dành phần lớn thời gian đọc và sắp xếp văn bản, không phải chèn. Normal mode trở thành chế độ rà soát: nhảy giữa câu, sắp xếp dòng và sửa nhỏ mà không với chuột.
Sửa server nhanh: Khi SSH vào máy và cần vá config, Vim thường đã có sẵn. Mục tiêu không phải cá nhân hoá — mà là tự tin: tìm khối đúng, sửa đúng phần cần thay, lưu và thoát sạch sẽ.
Pairing: Vim có thể bất ngờ thân thiện khi pair vì hành động rõ ràng. Nói “xoá đoạn này” hay “thay bên trong dấu nháy” tương ứng với lệnh rõ ràng, và người đối tác học qua quan sát.
Vim nổi bật khi bạn coi nó là một công cụ trong chuỗi. Bạn có thể tìm với ripgrep/grep, mở kết quả, và sửa cụ thể — mà không biến editor thành IDE đầy đủ.
Ví dụ vòng lặp phổ biến: chạy tìm kiếm trong terminal, mở file tại vị trí khớp, sửa, rồi chạy test lại. Đó là nguyên tắc “mỗi thứ làm tốt một việc” áp dụng vào công việc hàng ngày: terminal tìm; Vim sửa; test runner kiểm chứng.
git config --global core.editor "vim"Đó là cách Vim mở rộng: không bằng cách thêm phức tạp, mà bằng cách làm các chỉnh sửa phổ biến nhanh, có thể đảo lại và nhất quán trên nhiều môi trường.
Vim có lợi thế thật — nhưng nó cũng thu thập những huyền thoại. Một số ý kiến ồn ào nhất đến từ người thử trong cuối tuần, hoặc từ fan coi nó như huy hiệu. Cách diễn đạt hữu ích hơn: Vim là một tập hợp ý tưởng thao tác (đặc biệt là chỉnh sửa theo mode) có thể phù hợp nhiều workflow, nhưng không tự động là lựa chọn tốt nhất cho mọi người hoặc mọi đội.
“Đường học quá dốc.”
Thật vậy lúc đầu vì các thứ cơ bản khác: mode, operator + motion, và nhấn mạnh các động từ chỉnh sửa hơn là nút công cụ. Độ dốc mượt dần nếu bạn học một lõi nhỏ và dùng hàng ngày, nhưng nếu chỉ mở Vim thỉnh thoảng, cơ bắp sẽ không hình thành.
“Không dễ khám phá.”
Phần nào đúng. Vim thưởng cho việc đọc :help, nhưng giao diện không quảng cáo tính năng liên tục. Khả năng khám phá tồn tại — nhưng ở nơi khác: chủ đề help, tutorial tích hợp, và văn hóa chia sẻ các mẫu nhỏ.
“Mỗi Vim khác nhau.”
Cũng đúng. Cấu hình khác nhau, plugin thay đổi hành vi, và ngay cả mặc định có thể khác giữa môi trường. Điều này gây khó chịu khi pair hoặc đổi máy. Các đội thường giải quyết bằng mặc định tối giản chung (hoặc thống nhất kỳ vọng “vanilla Vim”) thay vì cố tiêu chuẩn hoá mọi thứ.
Vim có thể không phù hợp khi đội yêu cầu workflow IDE cụ thể, khi thời gian onboarding hạn hẹp, hoặc khi nhu cầu tiếp cận khiến tương tác nhiều phím không thuận. Sở thích cá nhân cũng quan trọng: có người tư duy tốt hơn trong UI trực quan với refactoring phong phú, và họ sẽ làm việc tốt ở đó.
Cách thực tế là chọn công cụ hỗ trợ công việc bạn thực sự làm: sửa nhanh qua SSH, edit file config, viết code cả ngày, hay cộng tác trong môi trường chuẩn hoá.
Hai bẫy thường bắt người học hăng hái:
Thứ nhất, xoay chỉnh vô tận — dành nhiều thời gian tinh chỉnh plugin hơn là dùng editor. Thứ hai, sưu tập phím tắt — gom lệnh mà không xây thói quen lặp. Nếu bạn muốn Vim giúp bạn nhanh hơn, hãy tập trung vào các workflow bạn lặp hàng tuần, và tự động hoá chỉ khi bạn có thể đặt tên rõ ràng cho việc đó.
Một quy tắc lành mạnh: nếu một thay đổi không tiết kiệm thời gian hoặc giảm lỗi trong tuần tới, hoãn nó.
Vim có giá trị nhất khi giúp bạn giữ nhịp, chỉnh với ý định, và xây các mẫu lặp được. Nếu editor khác làm việc đó tốt hơn cho bạn — hoặc cho đội — hãy chọn nó mà không cảm thấy tội lỗi. Mục tiêu không phải “dùng Vim”, mà là sản xuất công việc tốt với ít ma sát hơn.
Học Vim bền khi bạn coi đó là xây vài thói quen đáng tin cậy — không phải gom lệnh lạ. Mục tiêu là cảm thấy bình tĩnh và tự tin khi chỉnh sửa, ngay cả trước khi bạn cảm thấy “nhanh”.
Dành 10–15 phút mỗi ngày, và dùng Vim cho một tác vụ thực tế (dù nhỏ). Ghi lại điều nào khó chịu và điều nào trôi chảy hơn.
Tuần 1: An toàn và thoải mái
Tập trung không bị kẹt. Luyện mở file, lưu, thoát và undo.
Tuần 2: Điều hướng và tìm kiếm
Bắt đầu di chuyển ở nhịp lớn hơn và dựa vào tìm kiếm để đến bất cứ đâu nhanh.
Tuần 3–4: Workflow chỉnh sửa
Thêm một bộ “chỉnh + lặp” nhỏ: change/delete/yank, lặp bằng ., và một macro cơ bản cho việc bạn làm thường xuyên.
:w, :q, :wq, :q!, cùng u (undo) và <C-r> (redo)w, b, e, 0, $, gg, G, và chút f{char}/pattern, n / N, và :%s/old/new/g (thử không dùng flags trước)Sửa README: chỉnh tiêu đề, sắp xếp bullet, và viết lại một đoạn mà không dùng chuột.
Refactor file nhỏ: đổi tên biến bằng tìm + thay, tách vài dòng, và căn lại indent.
Viết nhật ký trong Vim: một entry ngắn mỗi ngày. Lặp lại tạo cảm giác thoải mái nhanh hơn các bài tập “khó”.
Theo dõi sự thoải mái (bớt hoảng) và tính nhất quán (ít chuyển ngữ cảnh), không phải tốc độ thô. Nếu bạn dự đoán được lệnh sẽ làm gì — và phục hồi khi sai — bạn đang học phần bền vững nhất.
Tác động kéo dài của Bram Moolenaar không chỉ ở việc tạo ra Vim — mà ở cách ông làm gương cho sự gìn giữ kiên nhẫn. Hàng thập kỷ ông xem xét patch, quản lý phát hành, trả lời câu hỏi và giữ cảm giác chung của công cụ: hiệu quả, nhất quán và khoan dung khi bạn học ngữ pháp của nó. Truyền thống “charityware” của Vim cũng phản ánh giá trị của Bram: phần mềm như một lợi ích công cộng, và bảo trì là công việc thực sự đáng trân trọng.
Vim thưởng cho việc chú ý đến các hành động nhỏ, có thể lặp lại. Bài học lớn không phải là một lệnh cụ thể, mà là tư duy: đầu tư vào thói quen giảm ma sát. Một vài giây tiết kiệm mỗi lần sửa nghe có vẻ nhỏ — cho đến khi nó trở thành cách mặc định bạn nghĩ khi viết code, ghi chú hoặc văn bản. Theo thời gian, trình soạn thảo biến từ một công cụ bạn điều khiển thành một phương tiện bạn làm việc xuyên qua.
Thú vị là, tư duy “ý định trước” này chuyển tốt sang các workflow mới hơn. Nếu bạn xây phần mềm qua giao diện chat — như cách vibe-coding của Koder.ai — cùng thói quen vẫn áp dụng: đưa ra thay đổi như một chỉ dẫn rõ ràng, lặp từng bước nhỏ, và dựa vào mạng lưới an toàn (ví dụ snapshots và rollback) thay vì một lần sửa mạo hiểm.
Vim còn dạy nghề xã hội: học công khai, chia dotfiles có suy nghĩ, viết báo cáo lỗi rõ ràng, và đối xử kiên nhẫn với người mới. Chuẩn mực lành mạnh khiến một công cụ “khó” dễ tiếp cận hơn. Nếu bạn muốn đào sâu, tài liệu tích hợp và tài nguyên cộng đồng là một phần của sản phẩm, không phải phụ kiện.
Trước khi bạn đóng bài viết này, chọn một thay đổi workflow bạn sẽ thử trong tuần: map lại một phím bạn hay với tới, luyện một mẫu chỉnh có thể lặp, hoặc ghi một mặc định nhỏ vào vimrc.
Cuối cùng, một lời nhắc kính trọng: cộng đồng mã nguồn mở tồn tại khi người dùng trở thành người hỗ trợ — bằng quyên góp, tài liệu, issue cẩn thận, code review, hoặc đơn giản là nói lời cảm ơn. Di sản của Bram nhắc rằng những người duy trì công cụ quan trọng không kém gì chính công cụ đó.
Văn hóa trình soạn thảo là tập hợp các thói quen, phím tắt, từ vựng và cách hướng dẫn lẫn nhau phát triển quanh một công cụ.
Trong trường hợp Vim, điều đó bao gồm suy nghĩ theo kiểu “operator + motion”, việc trao đổi mẹo trong các buổi pairing, và coi cấu hình (một vimrc) là một phần của quy trình làm việc — không phải thứ để bỏ qua.
Modal editing tách biệt ý định:
Điều này giảm các chỉnh sửa vô tình và khiến thay đổi cảm nhận như các chỉ dẫn rõ ràng (xoá/đổi/chuyển), còn việc gõ xảy ra chỉ khi bạn thực sự muốn.
“Tính tổ hợp” của Vim làm các lệnh trở nên dự đoán được: một động từ (delete/change/yank) áp lên một mục tiêu (từ, câu, trong dấu nháy, đến cuối dòng).
Ví dụ:
cw = change a worddi" = delete inside quotesBạn học ít khái niệm lõi hơn và tái sử dụng chúng trong nhiều tình huống, thay vì phải nhớ từng phím tắt cho mỗi kịch bản.
Dùng . khi bạn thực hiện cùng một kiểu thay đổi lặp lại.
Một quy trình thực tế là:
. để lặp lại.Thói quen này khuyến khích bạn chia sửa thành các “khối” có thể lặp lại, thường giảm lỗi và công việc lại hơn là chỉ tăng tốc độ thuần túy.
Macro hữu ích khi văn bản nhất quán và các bước mang tính cơ học.
Dùng tốt cho:
Tránh dùng macro khi mỗi dòng cần đánh giá khác nhau (chỉnh sửa có điều kiện), vì macro có thể sinh ra lỗi nhanh và khó phát hiện. Trong những trường hợp đó, dùng tìm + xác nhận hoặc các lặp nhỏ an toàn hơn.
Một vimrc là file cấu hình của Vim, nơi bạn đặt mặc định (thụt lề, hành vi tìm kiếm, dòng trạng thái, v.v.).
Cách tiếp cận thực tế:
Hãy coi nó như một “bàn làm việc” di động, chứ không phải tập hợp các tweak ngẫu nhiên.
Bắt đầu với một nền tảng tối giản (thụt lề, thiết lập tìm kiếm, số dòng, màu sắc dễ đọc). Rồi chỉ thêm plugin khi bạn có thể nêu rõ vấn đề chúng giải quyết.
Một quy tắc hay: nếu plugin không giúp tiết kiệm thời gian hoặc giảm lỗi trong tuần này, hãy hoãn nó. Điều này ngăn việc “xoay tua cấu hình” thay thế cho việc học và thói quen hiệu quả.
Với việc dùng thỉnh thoảng (như SSH), ưu tiên một “bộ sơ cứu” nhỏ:
Nhiều dev dùng Vim cho commit message và interactive rebase vì họ dành nhiều thời gian đọc và sắp xếp văn bản. Modal editing phù hợp vì ở đó bạn chủ yếu xem lại và chỉnh sửa chứ không phải nhập liệu liên tục.
Một bước thiết lập đơn giản là:
git config --global core.editor "vim"Ngay cả điều hướng + tìm kiếm cơ bản cũng giúp việc xem lại và sửa commit trở nên kiểm soát hơn so với workflow chỉ dùng chuột.
Vim có thể thoải mái hơn với một số người (ít di chuyển chuột hơn), nhưng cũng có thể tăng gánh nặng ngón tay tuỳ thuộc vào bàn phím và thói quen.
Sử dụng bền vững gồm:
Workflow tốt nhất là workflow bạn duy trì được mà không đau đớn.
i, Esc, :w, :q, :wq, :q!u, <C-r>/pattern, rồi n/NMục tiêu là tự tin và có thể phục hồi, chứ không phải một thiết lập cá nhân đầy đủ.