Larry Tesler ghét mode đến mức biển số xe ghi NOMODES. Cuộc chiến ấy đã định hình thao tác cắt và dán.

10/10/2026 · VietTechies · Biên tập

Ngày 30 tháng 5 năm 1973, tại Trung tâm Nghiên cứu Palo Alto (PARC) của Xerox, Larry Tesler, người về sau góp phần đưa thao tác cắt và dán vào việc dùng máy tính hằng ngày, tiến hành một thí nghiệm hoàn toàn không cần đến phần mềm.

Ông cho nhân viên mới Sylvia Adams ngồi trước một màn hình trống. Theo một bài viết đăng sau này trên tạp chí kỹ thuật IEEE Spectrum, ông đưa cho Adams một trang văn bản có đánh dấu các chỗ cần sửa, rồi hỏi bà sẽ sửa những chỗ đó ra sao.

Spectrum thuật lại câu trả lời của bà: “Tôi phải chèn thêm gì đó vào chỗ kia, nên tôi sẽ chỉ vào đó, rồi gõ những gì mình muốn.”

Ngày nay, ô nhập văn bản vốn dĩ hoạt động như thế. Nhưng năm 1973, các trình soạn thảo không làm việc theo cách đó, và khi ấy Tesler đã theo đuổi mục tiêu xóa bỏ khoảng cách này. Năm 1995, những vị khách đang lái xe tới một bữa tiệc sinh nhật đã nhận ra xe của ông trên đường cao tốc nhờ tấm biển số. Tấm biển ghi NOMODES, tức “no modes”: không có chế độ (mode) nào.

Hơn bất kỳ phát minh riêng lẻ nào, chính chiến dịch chống mode mới là sợi dây gắn Tesler với các thao tác cắt, sao chép và dán mà bạn dùng hằng ngày.

Vấn đề mang tên mode

Mode là một trạng thái ẩn làm thay đổi ý nghĩa của những gì bạn nhập vào. Cùng một phím, bấm ở hai mode sẽ cho ra hai kết quả khác nhau. Nếu bạn từng gõ một câu vào Vim rồi thấy cả câu chạy như một chuỗi lệnh, thì bạn đã gặp mode rồi đấy.

Các trình soạn thảo quanh Tesler khi ấy đầy rẫy mode. Nhiều đồng nghiệp của ông trong nhóm làm hệ thống văn phòng ở PARC vốn từ nhóm của Doug Engelbart chuyển sang. Họ chuộng cách ra lệnh của NLS, hệ thống “oN-Line System” của nhóm cũ: nêu thao tác trước, rồi mới trỏ vào đối tượng. Theo mô tả của Tesler, ngoài lúc nhập văn bản, gần như mỗi lần gõ phím hay nhấp chuột đều làm đổi mode.

Tháng 8 năm 1973, Adams được hướng dẫn dùng CGEDIT, một phiên bản rút gọn của NLS do Bill Duvall viết. Ghi chép của Tesler cho thấy muốn xóa một ký tự phải qua năm bước: gõ hai chữ cái lệnh, trỏ vào ký tự đó, nhấp một lần để đánh dấu, và cuối cùng là lệnh xác nhận “command accept”. Bà nhận xét: “Phải bấm quá nhiều lần mới làm xong một việc đơn giản như xóa một ký tự.” Bà muốn chỉ cần hai thao tác: trỏ vào, rồi xóa.

Bravo, trình soạn thảo mới của PARC do Butler Lampson, Charles Simonyi và các đồng nghiệp làm ra, cũng mắc đúng tật đó. Phần lớn phím bấm đều là lệnh, trừ khi bạn đã chuyển sang chế độ chèn hoặc chế độ nối thêm từ trước. Có một câu chuyện kể rằng một người dùng gõ chữ “edit” khi đang ở chế độ lệnh: phím E chọn toàn bộ tài liệu, D xóa sạch, I bắt đầu chèn, còn T gõ ra một chữ “t”. Một bài đăng năm 1986 trên diễn đàn Usenet có kể lại chuyện này, và gọi đây là giai thoại không đáng tin. Dù có thật hay không, mối nguy mà câu chuyện ấy mô tả vốn đã nằm sẵn trong lối soạn thảo dựa trên mode.

Những gì Tesler và Tim Mott thực sự làm ra

Cơ hội đến từ một nhà xuất bản sách giáo khoa. Ginn and Company, công ty do Xerox sở hữu, muốn có một trình soạn thảo để sửa bản in thử. Ginn đã thuê kỹ sư phần mềm Tim Mott để tìm hiểu cách nhân viên của công ty ở gần Boston thực sự làm việc. Năm 1974, Mott đến PARC giúp Tesler xây dựng trình soạn thảo này và đặt cho nó cái tên Gypsy. Hai người lấy mã nguồn của Bravo, bỏ giao diện dựa trên mode và thay bằng một giao diện không có mode.

Gõ phím luôn ra chữ. Bạn nhấp chuột, một con trỏ nhấp nháy hiện ra, và bạn cứ thế viết. Không có chế độ chèn nào để phải bật lên, hay để mà quên.
Chọn trước, ra lệnh sau. Bạn kéo chuột qua đoạn văn bản để chọn, rồi mới đến lệnh. Khi các ý tưởng của Tesler về cách chọn một từ đều không ổn, Mott nghĩ ra thao tác nhấp đúp.
Cắt, sao chép và dán. Gypsy có phím riêng cho cắt, sao chép, dán và hoàn tác (undo). Thao tác di chuyển văn bản trở thành: chọn, cắt, nhấp chuột, dán; giữa các bước, bạn có thể làm việc khác.

Chọn trước rồi mới ra lệnh chính là cốt lõi kỹ thuật của Gypsy. Trong NLS, nếu chỉ định sai đối tượng, bạn phải xóa ngược lại dòng lệnh đang gõ dở. Tesler lập luận rằng khi đối tượng đã được chọn từ trước, lỡ chọn sai thì bạn chỉ việc chọn lại, và tác dụng của lệnh hiện ra ngay lúc bạn ra lệnh. Còn nếu dùng nhầm lệnh, bạn có thể hoàn tác.

Đầu năm 1975, Gypsy đến tay Ginn. Trình soạn thảo này chưa bao giờ được bán ra thị trường, nhưng Ginn đã dùng nó để biên tập bản thảo trong nhiều năm. Năm 1980, Tesler chuyển sang Apple để làm giao diện và ứng dụng cho máy tính Lisa. Theo lời ông kể, các trình soạn thảo không mode của Xerox đã ảnh hưởng đến Lisa và Macintosh của Apple, cũng như Word và Windows của Microsoft, những sản phẩm đã khiến cắt, sao chép và dán có mặt ở khắp nơi.

Ngộ nhận: “người phát minh ra cắt và dán”

Khi Tesler qua đời vào tháng 2 năm 2020, ở tuổi 74, Xerox viết trong lời tưởng nhớ: “Người phát minh ra cắt/sao chép & dán, tìm & thay thế, và nhiều thứ khác nữa, chính là cựu nhà nghiên cứu Xerox Larry Tesler.” Chính bản lý lịch của ông cũng nói gần như vậy: “Người phát minh chính ra lối soạn thảo không mode và cắt, sao chép, dán.”

Trong bài viết năm 2012 kể lại lịch sử công việc này, Tesler thận trọng hơn. Ông viết rằng mình không phải người đầu tiên nhận ra mode làm tăng tỷ lệ lỗi, và cho biết ông đã phát triển cắt/sao chép-dán trong vài năm, cùng một loạt cộng sự. Tại Stanford, phiên bản trình soạn thảo TVEDIT của Pentti Kanerva từ trước đó đã tách việc di chuyển văn bản thành hai bước: xóa văn bản và cất vào một ngăn xếp (stack), rồi lấy ra ở chỗ khác.

Bản thân cụm từ “cut and paste” vốn là thuật ngữ của nghề xuất bản. Từ năm 1968 đến 1970, Tesler từng tự tay cắt dán bằng lưỡi dao và keo khi làm một cuốn catalog. Còn cụm từ “copy and paste”, theo ông viết, dường như bắt nguồn từ Gypsy.

Như vậy, muốn nói cho có cơ sở thì phải nói khiêm tốn hơn. Tesler và các đồng nghiệp không phát minh ra việc di chuyển văn bản. Họ bỏ mode khỏi thao tác đó, thử nghiệm với người dùng thật, rồi đưa cách làm ấy vào những sản phẩm đã biến nó thành mặc định.

Vì sao mode chưa bao giờ biến mất

Soạn thảo không mode cũng có cái giá phải trả. Một lần di chuyển văn bản trong Gypsy tốn bốn thao tác. Về sau, trình soạn thảo BravoX và hệ thống văn phòng Star của Xerox giảm con số đó xuống còn hai hoặc ba, bằng cách đưa trở lại một mode ngắn giữa hai bước chọn nguồn và chọn đích.

Còn lập trình viên thì vẫn cố ý giữ lại mode. Trong khảo sát lập trình viên năm 2025 của Stack Overflow, 24,3% người trả lời câu hỏi về môi trường phát triển cho biết họ dùng Vim, và 14% dùng Neovim. Với một người dùng thành thạo phải soạn thảo cả ngày, chế độ lệnh biến cả bàn phím thành các động từ.

Chính Tesler cũng phải thừa nhận điều đó. Trong một buổi nói chuyện năm 1997 về nguồn gốc giao diện của Apple, ông nhớ lại chiếc áo phông mà một người bạn từng làm tặng ông, in dòng chữ “Don’t Mode Me In” (đừng nhốt tôi vào mode). Ông nói việc cố loại bỏ mọi mode khỏi giao diện người dùng “chưa hẳn là ý hay, nhưng chắc chắn đó là sứ mệnh tôi đã theo đuổi”.

Định luật Tesler: ai gánh phần phức tạp?

Tesler còn để lại một quy tắc, thường được gọi là Định luật Tesler, mà theo ông có từ khoảng năm 1984: “Ứng dụng nào cũng có một lượng phức tạp cố hữu, không thể giảm bớt.” Phần hữu ích nằm ở câu hỏi ông đặt ra tiếp theo: người dùng, lập trình viên ứng dụng hay lập trình viên nền tảng, ai sẽ phải xử lý phần phức tạp ấy?

Mode là một cách giao phần phức tạp đó cho người dùng. Với những người dùng thành thạo tự chọn mode, đó có thể là sự đánh đổi đúng đắn. Còn với tất cả những người khác, mode là một biến ẩn mà họ phải giữ trong đầu.

Vì vậy, trước khi thêm một nút bật/tắt, một trạng thái hay một “mode” vào sản phẩm của mình, hãy thu gọn câu hỏi của Tesler vào đúng một phím: khi ai đó nhấn phím này, liệu họ có biết phím đó làm gì mà không cần nhớ một điều màn hình không hiển thị?

Bài liên quan

Đọc bằng ngôn ngữ khác: English