RE: ELPA and EmacsWiki Updates

[Drew Adams]

> 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.

Casual users are the ones I'm worried about here. #1 gives them the
impression that they can count on help when they get into trouble. "Would
that it were..."

> 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?

When you save customizations, they are saved in your `custom-file', if that
variable is defined. If not, they are saved in your .emacs. At startup, both
.emacs and `custom-file' are loaded. So yes, customizations are read at
startup.

> 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.

OK, I misunderstood that.

> 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/".

That's what will bite a casual user. It's error prone, and it might require
some knowledge of Emacs Lisp or OS commands. IMO, it should be just as easy
to uninstall something as to install it. No - it should be easier. This is
not as important for experienced users as it is for novices, but it helps
everyone.

> 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.

And that is a good thing.

> 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 :-)

Agreed.

> 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.

That argues for being _able_ to do them at the same time, but not for being
_obliged_ to do them together.

> 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?

You might want to try a package, without committing yourself to integrating
it with your regular Emacs startup. It's not so much a question about "what
package" but a question about what a user might want to do in different
contexts. I have some libraries that I use all of the time, and others that
I use only occasionally, on demand.