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: Mon, 20 Jul 2015 00:52:09 +0900 Message-ID: <21931.51113.826895.663216@uwakimon.sk.tsukuba.ac.jp> References: <87twt1dmxu.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1437323466 3465 80.91.229.3 (19 Jul 2015 16:31:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Jul 2015 16:31:06 +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 18:30:56 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 1ZGrUK-00066n-VJ for ged-emacs-devel@m.gmane.org; Sun, 19 Jul 2015 18:30:53 +0200 Original-Received: from localhost ([::1]:52026 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZGrUK-0004sH-5Q for ged-emacs-devel@m.gmane.org; Sun, 19 Jul 2015 12:30:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60384) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZGrU2-0004sC-Vz for emacs-devel@gnu.org; Sun, 19 Jul 2015 12:30:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZGrTz-0005fK-ON for emacs-devel@gnu.org; Sun, 19 Jul 2015 12:30:34 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:40211) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZGrTz-0005f3-0K for emacs-devel@gnu.org; Sun, 19 Jul 2015 12:30:31 -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 38EF71C3983; Mon, 20 Jul 2015 00:52:10 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 0FDA011EF83; Mon, 20 Jul 2015 00:52:10 +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:187990 Archived-At: Helmut Eller writes: > I don't see how. Either (require 'slime-autoloads) calls slime-setup or > not. In XEmacs it would be considered pollution, and we'd change the XEmacs version of the package so that the autoloads do not call slime-setup. XEmacs (and I assume Emacs ;-) is designed to be usable on a multiuser system, and I have yet to find a package that absolutely everybody thinks should be enabled. For example, you'd think AUCTeX would be a no-brainer in this day and age, but as far as I know RMS doesn't use it, and there is at least one long since inactive XEmacs developer who didn't use AUCTeX and objected vehemently to making it the default TeX-mode if available. Ditto cc-mode (although that person did eventually switch). Also, any of the schemes that I propose would mean that emacs -u disables slime except for autoloads (I assume package autoloads can be defeated some other way, as in XEmacs). This is an important feature for debugging. > Calling it lazily when a SLIME related command is invoked the > first time would kinda work for SLIME, but it would be rather strange > that say the slime-connect command implicitly adds hooks to > lisp-mode-hook. Why is that stranger than saying that slime-setup implicitly adds hooks to lisp-mode-hook? Or stranger than saying that simply installing the SLIME package on your system implicitly adds hooks to lisp-mode-hook? > In general, lazy initialization would also not work well if those > autoloaded commands should be bound to keys because before the > first invocation the keys would not be bound. Why would you expect them to be bound? The existence of a package doesn't necessarily mean that the user wants it invoked at startup. If the user does want those keys bound, I don't see why it's a problem to have the user put a call to slime-setup in .emacs, or put it on lisp-mode-hook itself. If users really object to that, well, you're right -- the XEmacs policy would not satisfy their requirements. But in a setup where package installation implies package initialization, putting a call to slime-setup in .emacs looks quite silly. What I think would be nice for this kind of situation would be to have a way for SLIME to add slime-setup to a checklist of defcustom options for lisp-mode-hook. Then users who do always want slime can use Customize to enable it "permanently", and it's not in their .emacs. Since slime-setup should be idempotent, it doesn't hurt to put it in .emacs even if it would be invoked some other way (including by the Customized lisp-mode-hook.