help-gnu-emacs
[Top][All Lists]
Advanced

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

Re: ELPA and EmacsWiki Updates


From: Tom Tromey
Subject: Re: ELPA and EmacsWiki Updates
Date: Sun, 09 Sep 2007 14:37:54 -0600
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.990 (gnu/linux)

>>>>> "Drew" == Drew Adams <address@hidden> writes:

Drew> What's really needed much of the time is a way to move smoothly
Drew> along the continuum between #1 and #2.

It depends.  Not everybody wants to learn how to hack elisp, or has
the time, or whatever.  But this doesn't mean they should not use
Emacs or install an external package or whatever... sure, we know it
was better for us to learn all this stuff, but we probably live in
Emacs (I do) -- but there are plenty of casual users as well.

Anyway package.el can't disguise the nature of the Emacs on which it
rests.  If you hit a bug, elisp hacking skills are needed, no question
there.

Drew> OK, but do you need to modify a user's .emacs to do that?
Drew> Couldn't you use Customize?

I don't see how it could use customize.  It needs to run code at
startup.  Is that possible with customize?

Drew> And edit your .emacs to remove the changes package.el made to
Drew> it, including to the load-path? Anything else? ;-)

load-path is hacked at runtime, during package activation.  The result
isn't written to any file.

I thought you were asking about deleting a single package.  If you
want to really uninstall package.el, then you must remove the bits
from your .emacs, and then "rm -rf ~/.emacs.d/elpa/".

Nothing else is modified... well, unless you customize some variable
for use by a package you just deleted.  I don't know how to handle
that case.

>> Eventually I'll write package deletion support for the package menu
>> mode.  I've put it off.

Drew> I'd think that would be the first thing to write ;-).

*Shrug*.  There's a reason package.el is only version 0.5.

Drew> I don't know. I'm all in favor of making things easy for
Drew> users. But in practice that too often means imposing a bunch of
Drew> stuff that a user might not really want (if fully aware) and
Drew> that s?he finds it difficult to get rid off or bypass
Drew> thereafter.

In my view, package.el is just doing what an experienced Emacs user
would do -- only, better than most folks bother, and regularized.  The
way this scratches my own itch -- since I'm not really a beginning
Emacs user -- is that it eliminates the drudgery of package install.

Of course there are always folks who want complete control, who (e.g.)
detest the file name ~/.emacs.d/elpa/, or whatever.  Not to be too
harsh or anything, but they should probably roll their own.  We'll all
be happier that way :-)

Drew> I would think that installing and activating (depending on what
Drew> is meant by the latter) would be two different choices for a
Drew> user to make. Why couple them?

Convenience.  Also, my thought experiment is: what external package is
there that is useful enough for me to install but which, if it were
incorporated into Emacs, should not be autoloaded?

Tom




reply via email to

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