all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: phillip.lord@russet.org.uk (Phillip Lord)
To: "Stefan Reichör" <stefan@xsteve.at>
Cc: emacs-devel@gnu.org
Subject: Re: Future role of ELPA
Date: Wed, 17 Feb 2016 18:42:01 +0000	[thread overview]
Message-ID: <874md7p4au.fsf@russet.org.uk> (raw)
In-Reply-To: <87vb5paxlp.fsf_-_@xsteve.at> ("Stefan \=\?utf-8\?Q\?Reich\=C3\=B6r\?\= \=\?utf-8\?Q\?\=22's\?\= message of "Tue, 16 Feb 2016 09:05:54 +0100")

Stefan Reichör <stefan@xsteve.at> writes:
>
> I am reading the emacs devel list. And I know that this is the direction
> that is desired by most/all developers.
>
> As I user I am not happy with that direction.
> Let me try to explain it.
> I use Emacs since about 20 years. I use it daily and it is my primary
> interface to computer related tasks. For sure I can adopt to what ever
> direction emacs goes.
>
> I use a hand crafted .emacs and I am used to install emacs packes
> manually to a site-lisp folders.

I stopped doing that in favour of use a package-install statement, in
this case via use-package. In total this means that, 

(require 'feature)

get replaced by

(use-package feature :ensure t)

There's even a way to avoid doing the :ensure bit if you want. In the
.emacs, the use of package.el can be pretty invisible.


> Consider a simple customization like tramp-theme. When everything is in
> stock emacs: I just can change the value of a customization variable and
> see what happens.

One thing that is an issue with package.el as it stands is
discoverability. Currently, if I open a *.lua file, I get fundamental
mode. While if I open a *.python file, I get python mode. Clearly the
former is unfriendly, and nothing tells me that installing lua-mode
solves the problem. If python-mode (for example) moved to ELPA, then
clearly we'd have the same problem there.

I think that there are two solutions to this: some packages should go to
ELPA, but could be packaged up with an Emacs distribution. Emacs "point"
releases then might have no changes to the core, but just changes to
ELPA packages.

The other possibility would be to have an something like autoloads for
ELPA packages. So, the first time you open a *.py file, and Emacs says
"Do you want to install python-mode".


> With GNU ELPA I have to install the package first and get rid of it if I
> don't like it.

Just leave it -- disk space is cheap!

> My main concern with GNU ELPA is that I have to install a lot of extra
> packages manually using the package manager. When they are built-in they
> are just there.
>
> So I hope that many useful features will still be shipped with Emacs as
> integrated packages.

I would modify this to "I hope that many useful features will continue
to be as usable as currently". Do you really care about whether they are
integrated, or if they just appear to be but some magic is happening
somewhere.

Phil



  parent reply	other threads:[~2016-02-17 18:42 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-15 15:50 [ELPA] tramp-theme.el Michael Albinus
2016-02-15 15:55 ` Marcin Borkowski
2016-02-15 17:55   ` Michael Albinus
2016-02-16  7:21     ` Stefan Reichör
2016-02-16  7:36       ` John Wiegley
2016-02-16  8:05         ` Future role of ELPA (was: [ELPA] tramp-theme.el) Stefan Reichör
2016-02-16  8:25           ` Future role of ELPA Christian Kruse
2016-02-16  8:46             ` Michael Albinus
2016-02-16  9:02               ` Christian Kruse
2016-02-16  9:15                 ` Michael Albinus
2016-02-16 10:16                   ` Christian Kruse
2016-02-16  9:18               ` Przemysław Wojnowski
2016-02-16  8:57           ` Oleh Krehel
2016-02-16 15:26           ` Future role of ELPA (was: [ELPA] tramp-theme.el) Drew Adams
2016-02-16 17:52           ` Future role of ELPA John Wiegley
2016-02-16 18:51             ` Stefan Reichör
2016-02-16 19:26               ` Michael Albinus
2016-02-16 19:45               ` John Wiegley
2016-02-17 15:59               ` Richard Stallman
2016-02-21  2:18               ` Stefan Monnier
2016-02-21 10:05                 ` Philipp Stephani
2016-02-21 14:19                   ` Stefan Monnier
2016-02-21 23:37                   ` Richard Stallman
2016-02-22 18:00                     ` Richard Stallman
2016-02-17 18:42           ` Phillip Lord [this message]
2016-02-16  7:53       ` [ELPA] tramp-theme.el Alexis
2016-02-16  7:55       ` Joost Kremers
2016-02-16  8:20         ` Stefan Reichör
2016-02-16  8:53           ` Joost Kremers
2016-02-16 17:57           ` John Wiegley
2016-02-16 18:41             ` Stefan Reichör
2016-02-16 19:48               ` John Wiegley
2016-02-16  8:14       ` Michael Albinus
2016-02-16 17:58         ` John Wiegley
2016-02-17  9:04           ` Michael Albinus

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

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

  git send-email \
    --in-reply-to=874md7p4au.fsf@russet.org.uk \
    --to=phillip.lord@russet.org.uk \
    --cc=emacs-devel@gnu.org \
    --cc=stefan@xsteve.at \
    /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.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.