Tự động tải và biến


8

Tôi hiểu những gì tự động tải cho các chức năng (đăng ký tập tin để tải khi chức năng đó được gọi hoặc chuỗi tài liệu của nó được lấy). Tuy nhiên, không rõ cách sử dụng tiện ích tự động tải kết hợp với các biến và macro.

Tôi có hai câu hỏi:

  1. Điều gì xảy ra khi gói có tham số, được triển khai như một biến mà người dùng có thể đặt, nhưng nó không được tự động tải? Các biến như vậy có nên được tự động tải? Nếu không, hóa ra các biến như vậy không tồn tại, môi trường Lisp không biết gì về chúng, bao gồm các giá trị mặc định của chúng, cho đến khi một số chức năng tự động tải từ gói được sử dụng (thường là sau khi tải tệp cấu hình), sau đó nếu người dùng đặt chúng vào / tập tin cấu hình của cô ấy, nó giống như thiết lập biến không tồn tại. Nếu giá trị của biến là một danh sách không trống và người dùng sử dụng pushhoặc add-to-listđể thay đổi giá trị của nó, chính xác thì điều gì sẽ xảy ra? Là giá trị mặc định bị mất?

  2. Điều gì xảy ra khi một macro được tự động tải? Khi nào chúng ta nên tự động tải một macro?

Câu trả lời:


5

Tự động tải chỉ áp dụng cho khe giá trị chức năng của ký hiệu. Đặc biệt, không có thứ gọi là tự động tải một biến.

Đây có thể là hình thức xấu cho gói chứa các biến cho tùy chỉnh của người dùng có giá trị mặc định là danh sách không trống, chính xác vì nó trở nên khó tùy chỉnh biến trong trường hợp đó. Tệ hơn, nếu giá trị mặc định thay đổi, giá trị tùy chỉnh có lẽ cũng sẽ thay đổi, nhưng người dùng sẽ không nhận thức được nó. Nếu một số gói có các biến như vậy, tốt nhất nên thay đổi nó sau khi gói đã được tải, sử dụng eval-after-load.

Hầu hết các biến tùy chỉnh sẽ có giá trị mặc định là nil, trong trường hợp đó bạn chỉ đặt chúng bằng cách sử dụng setqtrong tệp init của mình (hoặc sử dụng giao diện tùy chỉnh). Giả sử gói sử dụng defvarhoặc defcustomđể đặt biến, vì vậy, nó sẽ không ghi đè cài đặt của bạn.

Các macro tự động tải: Đặt đối số thứ năm autoloadđể đạt được điều này. Giống như các hàm, điều này nên được thực hiện nếu có khả năng bạn muốn sử dụng macro mà không tải gói trước - rõ ràng hoặc ngầm bằng cách gọi các ký hiệu tự động tải khác từ gói.

Phụ lục: Như OP đã chỉ ra trong các bình luận, một ;;;###autoloadbình luận kỳ diệu cũng sẽ sao chép một defvar(thực sự, bất kỳ hình thức elisp nào) vào tệp tự động tải. Xem Autoload phần trong cuốn hướng dẫn elisp để biết chi tiết.


Vì vậy, các biến có thể chỉ là setqed (nghĩa là không có vấn đề gì với giá trị mà chúng có trước đó) có thể được chỉ định mặc định trong defvarhoặc defcustombiểu mẫu, nhưng trong trường hợp danh sách có thể được người dùng mở rộng thì tốt nhất nên sử dụng eval-after-loadphải không? Ngoài ra, đôi khi mặc định tốt là tốt, ngay cả khi chúng ở dạng danh sách ;-)
Mark Karpov

Đúng rồi. Tôi sẽ lập luận rằng nếu một tùy chỉnh phổ biến yêu cầu eval-after-load, đó là một lỗi trong việc thực hiện gói. Thông thường, eval-after-loadnên được sử dụng để sửa lỗi hoặc các tùy chỉnh rất bất thường. Nhân tiện, có thể tốt hơn để sử dụng một cái móc nếu gói làm cho nó có sẵn.
Harald Hanche-Olsen

Vấn đề là tôi muốn có một biến liên kết với danh sách ba yếu tố (mặc định). Mặc định là những gì hầu hết người dùng muốn, tôi chắc chắn. Nhưng nếu tôi đi eval-after-load, người dùng vẫn không thể xóa các thành phần khỏi danh sách! Điều này khiến tôi tự hỏi liệu tôi có nên từ bỏ mặc định không.
Đánh dấu Karpov

1
Tôi không đồng ý rằng eval-after-loadchỉ cần thiết cho những tình huống bất thường. Đây là một trong những công cụ tiêu chuẩn trong bộ công cụ tải hoãn lại. Nếu mọi người không muốn sử dụng các công cụ như vậy, họ có thể requirethư viện lên phía trước (đó thực sự là điều mà những người mới đến thường được khuyến nghị nên làm - đến lúc họ nghĩ rằng "Tôi ước Emacs bắt đầu nhanh hơn một chút", họ ' Có lẽ đã học đủ để không sợ hãi bởi cú pháp mới :)
phils

1
@Drew: Quan điểm của bạn về việc sử dụng customize-set-variablechứ không phải setqlà một quan điểm tốt. Nhưng tôi không có thời gian cho nghiên cứu cẩn thận cần thiết để cải thiện câu trả lời của tôi về vấn đề này. Nếu bạn nghĩ rằng điều này quan trọng, tại sao bạn không viết câu trả lời của riêng mình? Nó sẽ được nhìn thấy nhiều hơn chủ đề bình luận dài này.
Harald Hanche-Olsen
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.