[Top][All Lists]

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

Re: Summary and next steps for (package-initialize)

From: Radon Rosborough
Subject: Re: Summary and next steps for (package-initialize)
Date: Tue, 22 Aug 2017 09:58:50 -0700

> On what ground was item 2. dismissed in previous discussions?

I've been arguing against it on the grounds that if one Emacs package
out of several thousand needs an extra init-file to work right, while
all the others don't, it's probably a sign of bad design on the part
of the one package. In other words, it seems like needless complexity.

And besides, if package.el gets its own init-file to make its job
easier, why not Org? And Gnus? And Dired? And EPG? And Flymake? It
would be chaos.

> The only disadvantage is that there is an extra init file now.

Well, consider the confusion when people put customization of
package.el in their init-file and it doesn't work. I feel like we
might be trading a bunch of user confusion over package customizations
not working for a bunch of user confusion over package.el
customizations not working. And I feel like "put package-initialize in
your init-file" is an easier-to-understand resolution than "put
customizations of this specific list of variables into a second

> Could somebody please summarize why it's such a fundamental
> rule that there can only be one emacs init file?

There's no rule; just a strong precedent that's been followed for
several decades (AFAIK).

reply via email to

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