From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: find-file-hook as illustration of Custom problems Date: Sat, 5 Feb 2005 21:16:21 -0600 (CST) Message-ID: <200502060316.j163GL216049@raven.dms.auburn.edu> References: <200502040036.j140atb03430@raven.dms.auburn.edu> <200502060207.j1627Kp15685@raven.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1107661198 6237 80.91.229.2 (6 Feb 2005 03:39:58 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 6 Feb 2005 03:39:58 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 06 04:39:57 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1CxdH2-000470-Sg for ged-emacs-devel@m.gmane.org; Sun, 06 Feb 2005 04:39:49 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CxdUt-0004Hz-KA for ged-emacs-devel@m.gmane.org; Sat, 05 Feb 2005 22:54:07 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CxdU4-00046N-QG for emacs-devel@gnu.org; Sat, 05 Feb 2005 22:53:16 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1CxdTz-000442-4L for emacs-devel@gnu.org; Sat, 05 Feb 2005 22:53:12 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CxdTy-0003yD-PB for emacs-devel@gnu.org; Sat, 05 Feb 2005 22:53:10 -0500 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Cxcvg-0002jb-JQ; Sat, 05 Feb 2005 22:17:44 -0500 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.12.10/8.12.10) with ESMTP id j163Hh9N003499; Sat, 5 Feb 2005 21:17:43 -0600 (CST) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id j163GL216049; Sat, 5 Feb 2005 21:16:21 -0600 (CST) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: teirllm@dms.auburn.edu In-reply-to: <200502060207.j1627Kp15685@raven.dms.auburn.edu> (message from Luc Teirlinck on Sat, 5 Feb 2005 20:07:20 -0600 (CST)) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org X-MailScanner-To: ged-emacs-devel@m.gmane.org Xref: main.gmane.org gmane.emacs.devel:32929 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:32929 >>From my previous message: Code that runs later will override the user's veto and add the stuff back anyway. Note that this is not a problem that would be a consequence of the discussed changes. It is a problem that exists right now. If, in present code, a non-preloaded Lisp file adds elements to a defcustomed hook, list or alist, then there is no way that you can presently override that in your `custom-set-variables' form. To override it in your .emacs you have to use `eval-after-load' or similar. To avoid this, I believe that the following conventions should be documented and followed. Is there any objection against any of the following conventions? In the following "changing" a defcustomed variable means _changing the global default value_. Changing buffer local values or `let' bindings are OK. Just _loading_ a non-preloaded file should not change any defcustomed variable unless "harmless" (like a hook function only used to gather info and without user visible consequences). Currently, just loading autorevert.el adds a function to find-file-hook, but that function is "harmless" in the above sense. When changing a defcustomed variable from a function, that function should be interactively called by the user and either the _only_ effect should be to implement the documented behavior of the function (for instance by adding a function to a hook that implements that behavior and does not interfere with anything else), or the fact that elements are going to be added to the defcustom should be clearly documented in the docstring and in any manual where the function is described. Sincerely, Luc.