Tin xấu, Emacs
(eshelyaron.com)- Đây vốn là một bài viết chỉ trích những thay đổi của tính năng registers trong Emacs 30, nhưng ở phần nội dung công khai hiện tại thì bản gốc đã bị gỡ xuống
- Bản gốc đã bị xóa vì bị cho là đề cập đến quá trình phát triển Emacs gần đây theo cách quá mức tiêu cực và thiếu thiện chí với những người liên quan
- Chỉ còn lại hướng dẫn rằng nếu muốn xem nội dung đã bị xóa thì hãy tìm Git log trên trang web của tác giả
- Điểm cốt lõi còn lại là tác giả đã bắt đầu dùng một nhánh (branch) hơi khác của Emacs cho nhu cầu hằng ngày
- Chỉ với phần nội dung công khai hiện tại, rất khó xác nhận những thay đổi cụ thể hay các vấn đề kỹ thuật xoay quanh tính năng registers của Emacs 30
Bài viết chỉ trích Emacs 30 đã bị gỡ xuống
- Bản gốc là bài viết nói về những thay đổi mà tác giả cho rằng đã làm tính năng registers trong Emacs 30 trở nên tệ hơn
- Trong phần nội dung công khai, lý do xóa bài còn được giữ lại: bài viết gốc đã chỉ trích quá mức quá trình phát triển Emacs gần đây và thiếu thiện chí với những người liên quan
- Việc bài viết này nhận được nhiều sự chú ý hơn hẳn các bài blog trước đó cũng được nhắc đến như một phần bối cảnh của quyết định xóa
Thông tin hiện có thể xác nhận
- Nếu thực sự muốn đọc bài đã bị xóa, bạn có thể kiểm tra Git log của trang web này
- Tác giả cho biết đã bắt đầu dùng một branch hơi khác của Emacs cho nhu cầu hằng ngày
- Phần nội dung công khai hiện tại không bao gồm các vấn đề cụ thể, ví dụ minh họa hay nội dung bản vá liên quan đến thay đổi của tính năng registers trong Emacs 30
1 bình luận
Ý kiến trên Hacker News
Ngay cả khi trong nhánh phát triển của Emacs xuất hiện một thay đổi phá vỡ tính tương thích, dù có chủ ý hay không, và một số người dùng bày tỏ lo ngại, quá trình cũng không diễn ra theo kiểu lập tức hoàn tác thay đổi đó
Cần có quá trình thảo luận ưu và nhược điểm, triển khai và cải thiện nhiều giải pháp, rồi tìm điểm thỏa hiệp. Mới chỉ 3 ngày kể từ khi người dùng nêu lo ngại, nên khó có thể cho rằng quá trình này đáng lẽ đã phải kết thúc rồi
Phản hồi gần đây của Eli cũng có ý rằng “hai người ban đầu tham gia thảo luận cho rằng hành vi mới hợp lý hơn nhiều so với hành vi cũ, nhưng giờ đã có ý kiến phản đối, nên có thể tiếp tục thảo luận về hành vi đó rồi sau đó mới bàn đến giá trị mặc định”
Tôi cho rằng cách phát triển Emacs có những vấn đề nghiêm trọng, nhưng việc người dùng bình thường thì đổ lỗi cho những người cứng đầu trên emacs-devel, còn khi có thay đổi mình không thích thì hành xử như thể tận thế đến nơi, cũng là một vấn đề. Điều đó khiến người bảo trì trở nên phòng thủ
Đọc chuỗi email thì thấy đây giống một bất đồng mạnh hơn là “kiêu ngạo”, và việc đạt được đồng thuận chắc chắn cần thời gian. Công khai gọi ai đó là “kiêu ngạo” chỉ vì họ không lập tức lùi bước theo góc nhìn của mình, rồi cố kéo vào một đám đông thậm chí sẽ không đọc chuỗi thảo luận, trông gần như là quấy rối
Ngoài ra, nói rằng bản vá biến thay đổi thành tùy chọn đã bị phớt lờ cũng không trung thực. Bản vá đó không chỉ thêm tùy chọn mà còn loại bỏ cả những thay đổi khác, nên mới bị từ chối; và việc quy trách nhiệm cho một người theo cách đó cũng khó chấp nhận
Nếu người dùng không phản ứng, theo quy trình đã mô tả, rất có khả năng thay đổi ban đầu mà họ phản đối sẽ được đưa vào nguyên trạng. Trong clojure-mode cũng vậy, rms đã cố lấy tên của tác giả từ cộng đồng Clojure vốn duy trì lâu nay để viết lại; mọi người phản đối trên danh sách thư nên việc đó bị chặn, nhưng chính những người ấy lại bị nói là phóng đại. Vì vậy, lời chỉ trích “phóng đại” có vẻ không mấy ý nghĩa
Nếu đưa một tính năng phá vỡ luồng làm việc của người dùng vào nhánh chính mà không thảo luận với cộng đồng rộng hơn, việc mọi người nổi giận là điều đương nhiên. Kiểu hợp nhất như thế này là cách các công cụ lâu đời đánh mất sự ủng hộ của cộng đồng
Nếu không cân nhắc mạnh mẽ việc hoàn tác ngay thay đổi phá vỡ tương thích, đó sẽ là tín hiệu rằng các nhà phát triển Emacs không còn coi trọng tính tương thích ngược như trước nữa, và điều này đồng nghĩa với việc bỏ rơi một phần đáng kể người dùng hiện tại
https://www.murilopereira.com/the-values-of-emacs-the-neovim...
Giá trị cốt lõi rất quan trọng. Những người bảo trì Emacs đã vi phạm giá trị cốt lõi, và việc cộng đồng khó chịu là chính đáng
Việc phá vỡ luồng làm việc của người dùng mà không biến nó thành tùy chọn, không chỉ không phải opt-in mà thậm chí còn không thể tắt, trông như một sự phớt lờ vô tâm đối với trải nghiệm người dùng
Tóm tắt theo cách hiểu của tôi: gần đây Emacs đã chấp nhận một commit thay đổi thao tác register, vốn tổng quát hơn một chút so với copy
Giờ đây Emacs sẽ mở minibuffer để cho thấy chuyện gì đang xảy ra, và bạn phải phê duyệt thay đổi bằng Enter hoặc một input tương ứng. Tác giả bài gốc cho rằng đây là một phá vỡ tương thích khủng khiếp, vì nó thay đổi hành vi mặc định, có thể không dễ tắt bằng cấu hình, và cũng không được thảo luận đầy đủ
Nếu ví với Vim, thì giống như khi bạn nhập
"dyyđể copy dòng hiện tại vào registerd, sau đó nó mở scratch buffer, hiển thị văn bản và buffer, rồi yêu cầu một lần nhấn phím để đóng. Với người dùng Vim thông thường hiểu về register thì điều này rất tệ, nhưng cũng có người thích hành vi “hiển thị rõ ràng thứ gì sẽ được copy”, như những người copy trong visual modePhần còn lại của bài viết nói rằng tác giả bài gốc đã cố khơi mào thảo luận nhưng bị Thierry, người viết commit, chặn lại, và ngầm cho rằng phần còn lại của cộng đồng phát triển Emacs cũng có trách nhiệm
Tôi đã dùng Emacs hàng chục năm nhưng chưa đi sâu vào register; cá nhân tôi dùng kill/yank để copy và dùng multiple cursors hoặc macro bàn phím dùng một lần cho các thao tác chỉnh sửa phức tạp. Dù vậy, Emacs có rất nhiều tính năng chỉnh sửa nâng cao tùy chọn dành cho những người muốn dựa vào muscle memory
Thêm một lần nhấn phím xác nhận ở đây là điều kỳ lạ. Nó giống như gắn “bàn đạp xác nhận hợp âm lạ” vào đàn piano điện, tức là chèn thêm một bước vào một thao tác nhập nhanh và phức tạp
Emacs có undo rất tốt, nên thay vì hỏi “Bạn có muốn dán nội dung trong register d không?”, cứ dán luôn, nếu người dùng chọn nhầm thì để họ undo
Vì vậy việc phá tương thích ở đây là kỳ lạ, và nếu không có cách tắt thì nhiều người dùng tức giận cũng dễ hiểu. Emacs là một công cụ còn lâu đời hơn các quy ước GUI hiện đại, nên không thể quen thuộc với người dùng mới như vscodium; vì thế cũng có lý khi phục vụ power user tốt nhất có thể
kill-ring-save, mặc địnhM-w, không bị ảnh hưởng; chỉ tính năng nâng cao hơn là lưu vào register mới thay đổiRegister không phải là một siêu tập của clipboard, tức kill ring
Ngoài ra, những người nói rằng thay đổi này sẽ không cấu hình được có vẻ không hiểu rõ khả năng tùy biến của Emacs. “Cấu hình” chỉ là để tiện lợi; nếu muốn, bạn có thể thay toàn bộ code. Đây là phần Elisp của Emacs, và ngay cả nếu nó được đưa vào nguyên trạng, trong vài phút sẽ có package thay đổi hành vi này. Không cần fork, và việc nói đến fork ở đây cùng lắm chỉ gần như một cử chỉ mang tính trình diễn
Nếu không được revert, tôi hy vọng có thể tìm được một đoạn macro xử lý thay cho lần nhấn phím bổ sung đó. Emacs vốn đã cần nhiều lần nhấn phím ngay cả cho việc đơn giản, còn tôi thì không đủ chuyên để tự tạo macro cho thay đổi này
Chuyện này có vẻ bắt đầu khi Thierry phát hiện vài vấn đề trong hành vi register và cố sửa chúng
Lỗi quan trọng nhất là sau khi nhấn
C-x r SPCđể gọisave-to-register, bất kỳ phím nào nhấn tiếp theo cũng sẽ khiến văn bản được lưu vào register tương ứng với phím đó. Đặc biệt,C-g, phím hủy đa dụng của Emacs, cũng không hoạt động ở đây mà sẽ lưu văn bản hoặc vị trí vào một register tên là^g. Nếu lỡ nhấnjump-to-registerhoặcinsert-registerthì cũng không thể hủy bằngC-ghay tương tự, mà bắt buộc phải chọn một registerThứ hai, register có thể chứa văn bản, vị trí hoặc giá trị rỗng.
jump-to-registerchỉ hoạt động với register chứa vị trí, còninsert-registerkỳ vọng văn bản. Emacs có cung cấp preview các register không rỗng khi chạy lệnh, nhưng không phân biệt, chẳng hạn vẫn hiển thị register chứa chuỗi như một ứng viên chojump-to-registerThierry đã cố sửa các vấn đề này cùng với phản hồi code review, và các reviewer cho rằng đây là thay đổi quan trọng dù có phát sinh tương tác bổ sung. Họ xem việc phải nhấn
RETsau khi chọn register thông thường, hoặc phải dùng thêm phím nếu muốn lưu vào một register kỳ lạ như^g, là phá vỡ tương thích có thể chấp nhận được so với lợi ích thu đượcTác giả bài gốc yêu cầu một switch để chuyển giữa hành vi mới và cũ, và được trả lời là hãy gửi patch, nhưng patch mà tác giả gửi lại hoàn tác toàn bộ các cải tiến nói trên và triển khai bằng flag một tính năng hoàn toàn khác là “xác nhận ghi đè register không rỗng”. Thierry thử áp dụng, đưa ra phản hồi ngắn gọn, và tác giả về cơ bản trả lời rằng “không cần những thứ đó”
Sau đó, khi nhiều người hơn dùng tính năng này, niềm tin của Thierry và các reviewer ban đầu rằng tác động của thay đổi phá vỡ là nhỏ đã hóa ra sai, và Thierry bắt đầu tạo một flag để vừa giữ công việc mới vừa cho phép luồng cũ. Đặc biệt, việc bỏ thêm
RETkhông phải bản chất mà gần như là tác dụng phụNhìn chung, quy trình có vẻ hoạt động khá tốt, và việc bỏ qua bối cảnh rồi cố đẩy thảo luận theo thái độ phản hacker rằng “nếu đại khái chạy được thì không được thay đổi theo bất kỳ cách nào” gần với phía tác giả bài gốc hơn
dyynghĩa là xóa dòng hiện tạiNhưng có lẽ chính điều đó chứng tỏ tôi là người mới
Nhìn vào thread mailing list này, có vẻ sẽ có một tùy chọn để hoàn nguyên hành vi đó: https://yhetil.org/emacs/87h6kr9817.fsf@posteo.net/#t
Có vẻ tùy chọn này đã được nhắc tới trước khi bài gốc được đăng, nhưng có thể tác giả chưa thấy. Điều này có vẻ sẽ giải quyết vấn đề, dù cũng có thể có phần nào đó tôi bỏ sót
Sửa: Xem câu trả lời của ginko bên dưới thì dường như vẫn sẽ cần nhấn phím RETURN
RETnếu muốn xác nhận ghi đè registerhttps://yhetil.org/emacs/87a5qi1vui.fsf@posteo.net/
register-use-previewstrông như công tắc bật/tắt cho hành vi nàyTuy nhiên có nhắc đến một bug là ngay cả khi đặt thành
never, trong một số workflow nhất định vẫn hiện xác nhận. Nếu đây là tùy chọn thật sự thì có lẽ phần lớn lo ngại sẽ được giải quyếtTrong Emacs, cần nâng trí nhớ cơ bắp lên thành mối quan tâm hạng nhất
Vì trí nhớ cơ bắp đã tích lũy bị phá hỏng. Trước khi bình tĩnh lại, tôi còn nghĩ vài điều khá độc ác. Có thể trông như chuyện nhỏ, nhưng tôi hiểu vì sao phản ứng trước tội “phản bội trí nhớ cơ bắp” lại có thể leo thang đến mức “fork you”
Điều này áp dụng cho Google Maps hay iOS cũng y như với Emacs
Trí nhớ cơ bắp cho phép ta thao tác phần mềm theo kiểu bán bất đồng bộ “không cần nhìn”, không phải kiểm tra bằng mắt ở từng tương tác nhỏ. Đáng tiếc là trong phần mềm desktop đang có xu hướng làm việc thao tác bằng bàn phím ngày càng rườm rà hơn, hoặc thậm chí bất khả thi
Đây là một bài rant hay, nhưng việc không giải thích tính năng đang nói đến là gì thì không giúp thuyết phục
Register của Emacs là một abstraction rất lâu đời. Register có thể chứa và lấy giá trị ra như các clipboard riêng, và có 62 register gắn với các ký hiệu ASCII cốt lõi
[a-zA-Z0-9], cung cấp một giao diện bàn phím linh hoạt và nhanh. Cũng có thể làm những việc thú vị như chạy keyboard macro từ register. Có người dùng nhiều, nhưng cá nhân tôi thì khôngLý do tác giả tức giận là binding mặc định đã thay đổi, khiến một modal UI chen vào trước thao tác trước đây hoàn toàn làm được chỉ bằng bàn phím và home row. Nghe như một phàn nàn hợp lý, và nếu một tính năng đã ăn sâu vào trí nhớ cơ bắp của tôi bị đổi như vậy, chắc tôi cũng sẽ bực
Nếu giữa mỗi lần chọn và dán lại có một hộp thoại modal xác nhận chen vào, và không có thiết lập để quay về hành vi cũ, thì chắc chắn tôi sẽ nổi cáu. Chỉ cần triển khai hành vi cũ dưới dạng tùy chọn là được. Đúng nghĩa chỉ vài dòng code
C-achẳng hạnTôi biết có người dùng chữ cái cho vị trí, và dùng
C-chữ cáicho văn bản. Với ai đó thì đây có thể là trường hợp rất đặc biệt, nhưng những người như vậy hẳn sẽ cực kỳ tức giậnTại https://yhetil.org/emacs/8334wawfvg.fsf@gnu.org/, Eli nói rằng “vì đã có ý kiến phản đối nên chúng ta đang tiếp tục thảo luận xem hành vi nên là gì, và khi có kết luận thì có thể nói về mặc định”
Cách diễn giải của tác giả bài gốc không tốt. Người dùng muốn ổn định nên ở trên release branch hoặc ghim một commit của master
Nên kỳ vọng rằng branch phát triển được dùng để phát triển các tính năng đang làm dở, và những tính năng như vậy có thể cần thời gian để được hoàn thiện. Nếu theo master, bạn sẽ thường gặp các thay đổi phá vỡ tương thích, và nếu có gì làm hỏng workflow thì nên quen với việc quay lại commit trước đó. Lựa chọn tốt hơn là ở lại bản phát hành
Cốt lõi của Emacs là một nền tảng cực kỳ tùy biến, nên nếu không thích hành vi của tính năng nào đó, bạn có thể tự sửa bằng vài dòng Lisp
Fork cả dự án chỉ vì thay đổi ở một tính năng obscure thì hoàn toàn vô lý. Tôi đã dùng Emacs từ khoảng năm 1981, thời nó còn được triển khai bằng macro TECO, nhưng tôi không dùng register
Nếu không, mỗi lần nền tảng thay đổi thì ai cũng phải viết lại hoặc sửa toàn bộ tùy biến của mình
Nếu patch này giữ nguyên và ai đó muốn dùng đúng theo cách cũ, thực tế họ phải áp dụng patch revert vào kho Emacs cục bộ rồi chồng thay đổi của mình lên. Mỗi lần upstream Emacs thay đổi, để lấy các thay đổi mới về thì phải rebase
Đó là fork riêng. Fork mãi mãi và rebase mãi mãi
Cũng có thể monkey patch đại khái bằng cách load file của mình thay cho, hoặc sau, file được ship để định nghĩa lại hàm, nhưng đó cũng là một dạng fork. Bạn phải lưu tài liệu/mã đó ở đâu đó như một dự án, và sẵn sàng điều chỉnh khi thay đổi làm monkey patch bị hỏng
Tôi đã rời Emacs 20 năm rồi, nhưng tôi hiểu thay đổi này khá phá vỡ
Điều tôi không hiểu là Emacs, vốn tự hào là “có cả bồn rửa bát”, tại sao lại không thêm một tùy chọn để quay về hành vi cũ
Patch đó thêm một flag nhưng cũng loại bỏ hết các cải tiến khác
Giọng văn của bài này khá có cảm giác “neckbeard”. Đây là một tính năng cực kỳ obscure chỉ có ba nerd dùng, chứ không phải chiếc thang không thể di chuyển của Nhà thờ Mộ Thánh
Việc một maintainer không lương hơi thay đổi nó mà không hỏi trước bạn không nhất thiết là “làm hỏng master”. Thứ đang nói đến ở đây là master, không phải bản ổn định hay tagged release
Dĩ nhiên giải pháp khả thi duy nhất là thử thêm một fork hoặc bản tái triển khai Emacs nữa
Lần này chắc chắn sẽ thành công, và sẽ không trở nên hoàn toàn không liên quan như những cái khác
Tuy vậy, fork có kéo dự án chính ra bàn đàm phán hay không thì không quan trọng lắm. Tác giả bài gốc có đủ khả năng và ý chí để giữ patch đó trong kho cục bộ của mình đến cùng. Thứ còn thiếu để hoàn tất fork chỉ là công khai kho cục bộ đó
Có lẽ nó chỉ nhằm thuyết phục maintainer của mainline