From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: find-file-hook as illustration of Custom problems Date: Sun, 06 Feb 2005 16:02:03 -0500 Message-ID: References: <200502040036.j140atb03430@raven.dms.auburn.edu> <200502060150.j161oqh15336@raven.dms.auburn.edu> Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1107724606 6611 80.91.229.2 (6 Feb 2005 21:16:46 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 6 Feb 2005 21:16:46 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 06 22:16:45 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Cxtlo-0003XO-Kg for ged-emacs-devel@m.gmane.org; Sun, 06 Feb 2005 22:16:40 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Cxtzo-00067f-Dp for ged-emacs-devel@m.gmane.org; Sun, 06 Feb 2005 16:31:08 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CxtxK-0005SX-Lz for emacs-devel@gnu.org; Sun, 06 Feb 2005 16:28:36 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1CxtxB-0005Ml-C7 for emacs-devel@gnu.org; Sun, 06 Feb 2005 16:28:28 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Cxtx9-0005Jc-Lc for emacs-devel@gnu.org; Sun, 06 Feb 2005 16:28:23 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Cxtaq-0002mb-9F for emacs-devel@gnu.org; Sun, 06 Feb 2005 16:05:20 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1CxtXf-0001yW-FX; Sun, 06 Feb 2005 16:02:03 -0500 Original-To: Luc Teirlinck In-reply-to: <200502060150.j161oqh15336@raven.dms.auburn.edu> (message from Luc Teirlinck on Sat, 5 Feb 2005 19:50:52 -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:32969 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:32969 Actually, the situation is more complex, certainly for non-hook atoms (and I would guess probably also for many hooks). Code puts things in variables like completion-ignored-extensions, debug-ignored-errors, file-coding-system-alist, help-event-list, minibuffer-prompt-properties, mode-line-format, same-window-buffer-names, same-window-regexps, and many others, that the user definitely might want to override. The right thing to do may not be the same for all these variables. We would need to look at them one by one in order to come to conclusions about what to do with them. For same-window-buffer-names, we could arrange for all the values added by Lisp packages to be part of the "standard value". That would be a start at solving the problem. I don't think that minibuffer-prompt-properties is a problem. It is simply a customizable variable whose value is set up with a setq. Likewise for help-event-list. If there is a problem with these, it is only that they are built-in and handled by cus-start.el rather than a defcustom. We just need to give them the right standard value. Do you want to try to do that? It would be useful to look for other variables that are in the same situation, and handle them. These being localized bug fixes, we could safely install them now. Maybe we could avoid that additional complexity if non-preloaded code strictly adhered to the conventions proposed in another message and if preloaded code put, for all involved list-vars, all elements of the involved hook, list or alist, that should be user-overridable in custom-list-var (instead of just in list-var). We could say that any adding of values to these variables by Lisp code has to be done by an autoload, so that the whole value is constructed by loadup.el. Then we can arrange to record it as the standard value, and that will be a good start at solving the problems. We could have a function custom-add-to-list which adds an element to a list and makes it part of the standard value. 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). This is already the convention. Do you know of any cases where this case is violated? 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. This seems plausible. Do you know of any specific exceptions?