Ưu điểm của việc đặt biến với setq thay vì custom.el?

Tôi thấy rất nhiều người (tác giả mở rộng và những người khác) đưa ra các ví dụ cấu hình với setq:

(setq foo 'bar)

Các tham số này thường được xác định với defcustom, làm cho chúng có sẵn để tùy chỉnh thông qua custom.el.

Tôi thường sử dụng custom.elđể thiết lập chúng. Sẽ có bất kỳ lợi thế để sử dụng setqthay thế hoặc là hai phương pháp gần như tương đương?

Một số người có thể nghĩ rằng đó là đơn giản để sử dụng setq. Một số người có thể nghĩ rằng nó là lispy hơn. Trong thực tế, nó là ngây thơ trong trường hợp chung.

Đúng là đối với một số tùy chọn người dùng, điều đó không thành vấn đề. Nhưng đối với những người khác, nó có vấn đề, và setqlà cách tiếp cận sai cho những lựa chọn đó. Vì vậy, như một quy tắc chung, setqlà cách tiếp cận sai.

Nếu bạn sử dụng custom-set-variableshoặc customize-set-variablethay vì setqhoặc nếu bạn sử dụng Giao diện người dùng Tùy chỉnh (ví dụ M-x customize-option), thì bạn chắc chắn rằng mọi mã khởi tạo hoặc cập nhật dự định cần thiết cho giá trị tùy chọn sẽ được tự động kích hoạt và chạy khi cần. Nếu bạn sử dụng setq, điều này sẽ không được thực hiện.

Bây giờ, nó cũng là trường hợp mà hầu hết các tùy chọn của người dùng, đặc biệt là nhiều trong số họ bằng văn bản cho các thư viện của bên thứ 3, không tận dụng các defcustomtừ khóa :setvà :initialize, và sử dụng setqkhông quan trọng đối với họ. Nhưng rất nhiều tùy chọn Emilla vanilla sử dụng các từ khóa như vậy, và đối với những từ đó, setqkhông phải là điều đúng đắn. Vì vậy, nếu bạn muốn sử dụng mã Lisp chứ không phải UI tùy chỉnh để đặt các tùy chọn của mình, thì tốt hơn hết bạn nên sử dụng custom-set-variableshoặc customize-set-variablethay vì setq. Nó không bao giờ đau và đôi khi nó giúp (rất nhiều).

Nhưng những gì tôi khuyên là nên làm cả hai điều này:

• Sử dụng Tùy chỉnh giao diện người dùng thay vì viết mã Lisp cho việc này.

• Xác định biếncustom-file , để Tùy chỉnh ghi các tùy chỉnh vào tệp đó chứ không phải vào tệp init của bạn ( ~/.emacs). IOW, giữ mã khởi tạo viết tay của bạn tách biệt với mã tự động được viết bởi Tùy chỉnh.

Tôi thích setqhơn customizevì nhiều lý do:

1. Đầu tiên và quan trọng nhất, nó cho phép các biến được đặt theo chương trình (như trong, (setq foo (calculate-foo))). Tôi sử dụng năng lượng này mọi lúc trong cấu hình của mình để giữ mọi thứ KHÔ. Đối với tôi, toàn bộ quan điểm của việc sử dụng Emacs là khả năng lập trình và customizegiao diện không làm gì khác ngoài việc cản trở.
2. setqcho vay tốt hơn để kiểm soát phiên bản và tổ chức mã. Tôi chia phần khởi tạo của tôi giữa hàng tá tệp; nếu mọi thứ nằm trong một custom.eltệp lớn , việc tìm và chỉnh sửa cài đặt sẽ khó hơn nhiều.
3. Điều này là chủ quan, nhưng với tôi toàn bộ customizegiao diện cảm thấy như một di tích khủng khiếp từ các UI tồi tệ nhất của thập niên 90. Tôi muốn chỉnh sửa văn bản với sức mạnh của Emacs bất cứ ngày nào.

@Drew làm cho một số điểm tốt về một số tinh tế với :setvà :initialize. Tôi đã sử dụng Emacs trong nhiều năm và hiếm khi gặp phải vấn đề như vậy. Khi tôi làm, thật dễ dàng để trao đổi ra setqcho custom-set-variablecác trường hợp cụ thể.

Một lợi thế của việc sử dụng setqthay vì customizelà khả năng đọc. Một người được tự do chú thích từng tùy chỉnh theo ý thích mà IMO cải thiện khả năng đọc. Người ta cũng có thể nhóm các tùy chỉnh liên quan với nhau để cải thiện tính mô đun. Cuối cùng, tôi sẽ lập luận rằng việc điều hướng qua một bộ đệm elisp "dễ dàng" hơn sau đó điều hướng UI và các widget tùy chỉnh.

Mặt khác, tùy chỉnh cho phép bạn dễ dàng trở lại các giá trị mặc định có thể là vô giá khi mọi thứ trở nên rắc rối.

EDIT: Câu trả lời của Drew cung cấp một lý do tuyệt vời để sử dụng customize-set-variablescó thể cung cấp tất cả những lợi thế tôi đã chỉ ra. Tuy nhiên, UI UI không cho vay cấu hình di động giữa các nền tảng khác nhau dễ dàng như elisp thô. Nếu bạn yêu cầu một biến để có cài đặt phụ thuộc os, bạn sẽ phải chuyển sang elisp trong nhiều trường hợp. Quan điểm của tôi về điều hướng dễ dàng hơn trong bộ đệm elisp vẫn đứng.

Một lựa chọn khác là sử dụng John Wiegley của sử dụng gói . Điều này cung cấp một cách lập trình để cấu hình các gói chơi độc đáo với quá trình khởi tạo gói 24+ của emacs. Đây là một ví dụ về việc sử dụng từ readme:

(use-package color-moccur
  :commands (isearch-moccur isearch-all)
  :bind (("M-s O" . moccur)
         :map isearch-mode-map
         ("M-o" . isearch-moccur)
         ("M-O" . isearch-moccur-all))
  :custom (isearch-lazy-highlight t)
  :config (use-package moccur-edit))

Vấn đề là gói sử dụng là một macro và không đánh giá các đối số của nó ngay lập tức. Các tham số :initvà :configđược đánh giá ở các giai đoạn khác nhau của quá trình khởi tạo, cho phép cấu hình của từng gói ở một nơi, nhưng có từng phần được thực thi ở giai đoạn khởi tạo thích hợp.

Không có cái gì đó giống như use-packagemột số gói yêu cầu một phần mã khởi tạo của chúng đi trước (package-initialize)và một phần khác để đi sau. Nếu bạn có nhiều packegas như vậy thì việc khởi tạo sẽ phải được xen kẽ.

Một lợi ích khác use-packagelà nó có thể tự động cài đặt các gói bị thiếu từ việc sử dụng gói.el nếu bạn đưa bạn .emacs sang máy mới hoặc nếu bạn chia sẻ cấu hình của mình với người dùng khác và tất cả việc khởi tạo có thể được hoãn lại cho đến khi gói thực sự cần được tải.

Ngoài ra còn có các đối số từ khóa bổ sung cho phép kiểm soát nhiều hơn quá trình khởi tạo.

Tất cả những gì đã nói, một lợi thế lớn của tùy chỉnh là nó cho bạn thấy những gì cần phải được cấu hình trong bất kỳ gói nào. Đó là một lý do tôi vẫn sử dụng nó cho nhiều gói của mình.