From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Package initialization Date: Sun, 19 Jul 2015 09:13:17 +0900 Message-ID: <87twt1dmxu.fsf@uwakimon.sk.tsukuba.ac.jp> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1437264825 12062 80.91.229.3 (19 Jul 2015 00:13:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Jul 2015 00:13:45 +0000 (UTC) Cc: Artur Malabarba , emacs-devel To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 19 02:13:31 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZGcEU-0007yq-H4 for ged-emacs-devel@m.gmane.org; Sun, 19 Jul 2015 02:13:30 +0200 Original-Received: from localhost ([::1]:50171 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZGcET-0000eI-UJ for ged-emacs-devel@m.gmane.org; Sat, 18 Jul 2015 20:13:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50898) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZGcEQ-0000eB-QK for emacs-devel@gnu.org; Sat, 18 Jul 2015 20:13:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZGcEN-0002XZ-H6 for emacs-devel@gnu.org; Sat, 18 Jul 2015 20:13:26 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:56717) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZGcEN-0002XT-6a for emacs-devel@gnu.org; Sat, 18 Jul 2015 20:13:23 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 100FF1C39C7; Sun, 19 Jul 2015 09:13:18 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id DCCD811EF83; Sun, 19 Jul 2015 09:13:17 +0900 (JST) In-Reply-To: X-Mailer: VM undefined under 21.5 (beta34) "kale" ffb5abc8dc4e XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:187968 Archived-At: Helmut Eller writes: > Now with the package stuff the (require 'slime-autoloads) line is > unnecessary. But additionally somebody claimed that it's idiomatic to > call slime-setup automatically in slime-autoloads. FWIW, in XEmacs's package system calls to package initialization functions in autoloads has always been considered anti-social behavior (and it's one of the few things we care about enough to override a maintainer's preference). In fact, we don't even allow those functions to be called when a library is loaded. All too frequently packages contain useful utility functions in libraries that other packages require, even though the user doesn't want the require'd library's primary functionality. What is considered good style in an XEmacs package: 1. The package has an idempotent initialization function, typically implemented by wrapping the whole function in `(if (not -initialized-p) ...)'. 2. The autoloads include exactly those commands that users are expected to invoke in the uninitialized state. (Users who know what they are doing can of course explicitly require or load package files and call any function.) 3. All autoloaded commands should call the package initialization function as their first action. 4. The autoloads may defvar global variables in the package's namespace. However defcustoms (which are automatically initialized by the XEmacs package system) are preferred for variables the user might customize, even if that is unusual. XEmacs packages aren't supposed to manipulate load-path etc, but that's because XEmacs packages are supposed to have a standard layout, and those standard locations are added to load-path etc by the package system at startup. I personally like that system, analogous to FHS and/or LSB conformance in GNU/Linux systems, but many package maintainers were distressed by it because they had existing layouts which were incompatible with XEmacs's preferred layout. So as Artur says, it may be desirable to modify search paths and the like in autoloads, though I prefer to delegate that to the lazily-called initialization functions. > I quite like to see the explicit call to slime-setup in my .emacs, but > others might not. I think the rules 1-4 above would satisfy both you and those others.