emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Package initialization


From: Stephen J. Turnbull
Subject: Re: Package initialization
Date: Mon, 20 Jul 2015 00:52:09 +0900

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]