From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.help Subject: RE: defcustom: changing from defvar - order of execution Date: Tue, 10 May 2005 11:32:55 -0700 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1115750078 18714 80.91.229.2 (10 May 2005 18:34:38 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 10 May 2005 18:34:38 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue May 10 20:34:36 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DVZY3-0006l0-S0 for geh-help-gnu-emacs@m.gmane.org; Tue, 10 May 2005 20:33:40 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DVZgd-0006sM-W6 for geh-help-gnu-emacs@m.gmane.org; Tue, 10 May 2005 14:42:32 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DVZZ6-0007E1-Rr for help-gnu-emacs@gnu.org; Tue, 10 May 2005 14:34:45 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DVZZ3-0007CK-Pj for help-gnu-emacs@gnu.org; Tue, 10 May 2005 14:34:42 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DVZZ3-0007Bw-Do for help-gnu-emacs@gnu.org; Tue, 10 May 2005 14:34:41 -0400 Original-Received: from [148.87.122.30] (helo=rgminet01.oracle.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1DVZdi-0008H1-68 for help-gnu-emacs@gnu.org; Tue, 10 May 2005 14:39:30 -0400 Original-Received: from rgminet01.oracle.com (localhost [127.0.0.1]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j4AIX0Sn023419 for ; Tue, 10 May 2005 12:33:00 -0600 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j4AIWw5s023400 for ; Tue, 10 May 2005 12:32:59 -0600 Original-Received: from rgmsgw301.us.oracle.com (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j4AIWwtu019701 for ; Tue, 10 May 2005 12:32:58 -0600 Original-Received: from dradamslap (dhcp-amer-csvpn-gw1-141-144-65-34.vpn.oracle.com [141.144.65.34]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id j4AIWuTT019684 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 10 May 2005 12:32:57 -0600 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:26487 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:26487 Per Abrahamsen said: Load hooks ... shouldn't be declared with defcustom. ... Emacs is very incosistent about when to use faces [vs variables] ... calculator-use-menu should be a global minor mode OK, I guess the standard libraries need a bit of cleanup in this regard. These samples came from just the first few files. I know that Luc Teirlinck already pointed out in emacs-devel that defcustoms for hooks were problematic, and that there will perhaps be an effort to clean up such stuff after release 23. As you see, the answer depends on the example. But a common answer is that if you need to depend on a user variable in the initialization, the user variable should have a :set that undo the effect if the user change it. Thanks; that guideline makes things a bit clearer. However, such use of :set seems complex to me (perhaps just because I'm not yet used to it). I need to look more at how it's used. The location in the .emacs file is just exposing the problem to more, in all cases the problem would show up if the library was loaded from the site initialization file, or even dumped Yes. That's part of what I meant. To come back to my original example, I guess the thing to do is this: - Ensure that libraries make no use of user options at the top level. IOW, always encapsulate such use inside defun's (e.g. `foo-fn'). - Tell the user (e.g. in library comments) that to use `foo-fn' at startup it must be called *after* `custom-set-variables', not before: (load-library "foo") ... (custom-set-variables '(foovar t)...) ... (foo-fn) ----------------------- The rest of this email is about the first of these guidelines, and it might be somewhat off-topic for help-gnu-emacs. I noticed that RMS said this recently in emacs-devel: Just loading appt.el probably should not activate the feature. In the 90s it was not unusual for packages to work that way, but when Custom was added it became common for a package to be loaded simply because someone wanted to customize a variable. So our convention, since then, is that just loading a package shouldn't really change anything. Not only was this common in standard libraries before this century, but it is still common for personal "libraries" - that is, .emacs and its extensions. It is normal for the latter, IMO, as long as they don't contain defcustom's. I said this in emacs-devel on Feb 8: I hope and expect that (beyond the bugs) few libraries will ever need to change user options, at least not by simply being loaded. Most will a) define standard values for options or b) provide commands to set options or c) behave themselves properly by modifying only non-user-option variables. I should make a distinction here - there are libraries and libraries. There are libraries that are intended for use by multiple users, and there are libraries that are essentially custom files or personal extensions thereof. Multi-user libraries are the ones that should not step on user options. Personal libraries are made to set user options. Some libraries start out life as a personal library and end up being shared to some extent by others. In some cases, user-option settings in a library shared this way are not bothersome - if the person using the library has the same environment and wants to do the same thing, for instance. This is essentially just cutting and pasting code. In general, however, a library destined for multiple users should not contain user-option settings - that is bad form. That is, some "libraries" are, in effect, .emacs settings (setq...) and startup code that have been relegated to one or more separate files loaded at startup. Lots of users do that, to help them organize their settings. (A common use is to deal with different settings for different platforms.) It might make sense to have a standard, recognizable (textual) way to distinguish these two types of emacs-lisp files ("libraries"), so users (and tools) could more easily apply the different kinds of guidelines to them. A first step, I think, is recognizing the different kinds of file and establishing clear guidelines for each. In particular, their treatment wrt customize is likely to be quite different. For example: 1) std library: defcustom, defun, etc. only - no top-level setq or function calls etc. 2) personal startup library: top-level function calls, setq etc. Executed after custom-set-variables, usually. Coming up with such guidelines would also help people migrate a personal library to become a clean multi-user library. A complete set of such guidelines would include heuristics, such as the :set rule Per mentioned, for dealing with customize. It is, I guess, thanks to the introduction of customize that the standard libraries are being forced to become cleaner wrt initializing and activating things. And customize considerations are driving the separation in form between standard libraries and personal startup libraries. Things that were commonly done in both a few years ago are now appropriate only for one or the other.