unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Tom Tromey <tromey@redhat.com>
To: "Drew Adams" <drew.adams@oracle.com>
Cc: help-gnu-emacs@gnu.org
Subject: Re: ELPA and EmacsWiki Updates
Date: Sun, 09 Sep 2007 14:37:54 -0600	[thread overview]
Message-ID: <m3hcm34lst.fsf@fleche.redhat.com> (raw)
In-Reply-To: <DNEMKBNJBGPAOPIJOOICEEJPDPAA.drew.adams@oracle.com> (Drew Adams's message of "Sun\, 9 Sep 2007 11\:46\:26 -0700")

>>>>> "Drew" == Drew Adams <drew.adams@oracle.com> 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	other threads:[~2007-09-09 20:37 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-02 20:38 ELPA and EmacsWiki Updates Nordlöw
2007-09-02 21:05 ` Tom Tromey
2007-09-03  1:53   ` Drew Adams
2007-09-03 20:59     ` Tom Tromey
2007-09-03 23:28       ` Drew Adams
2007-09-06  0:14         ` Tom Tromey
2007-09-06 17:00           ` Drew Adams
2007-09-09 17:06             ` Tom Tromey
2007-09-09 18:46               ` Drew Adams
2007-09-09 20:37                 ` Tom Tromey [this message]
2007-09-09 21:41                   ` Drew Adams
2007-09-03  5:50   ` Edward O'Connor
2007-09-03 19:57     ` Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3hcm34lst.fsf@fleche.redhat.com \
    --to=tromey@redhat.com \
    --cc=drew.adams@oracle.com \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).