[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Future role of ELPA
From: |
Phillip Lord |
Subject: |
Re: Future role of ELPA |
Date: |
Wed, 17 Feb 2016 18:42:01 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Stefan Reichör <address@hidden> 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
- Re: Future role of ELPA, (continued)
- Re: Future role of ELPA, John Wiegley, 2016/02/16
- Re: Future role of ELPA, Stefan Reichör, 2016/02/16
- Re: Future role of ELPA, Michael Albinus, 2016/02/16
- Re: Future role of ELPA, John Wiegley, 2016/02/16
- Re: Future role of ELPA, Richard Stallman, 2016/02/17
- Re: Future role of ELPA, Stefan Monnier, 2016/02/20
- Re: Future role of ELPA, Philipp Stephani, 2016/02/21
- Re: Future role of ELPA, Stefan Monnier, 2016/02/21
- Re: Future role of ELPA, Richard Stallman, 2016/02/21
- Re: Future role of ELPA, Richard Stallman, 2016/02/22
- Re: Future role of ELPA,
Phillip Lord <=
- Re: [ELPA] tramp-theme.el, Alexis, 2016/02/16
- Re: [ELPA] tramp-theme.el, Joost Kremers, 2016/02/16
- Re: [ELPA] tramp-theme.el, Stefan Reichör, 2016/02/16
- Re: [ELPA] tramp-theme.el, Joost Kremers, 2016/02/16
- Re: [ELPA] tramp-theme.el, John Wiegley, 2016/02/16
- Re: [ELPA] tramp-theme.el, Stefan Reichör, 2016/02/16
- Re: [ELPA] tramp-theme.el, John Wiegley, 2016/02/16
- Re: [ELPA] tramp-theme.el, Michael Albinus, 2016/02/16
- Re: [ELPA] tramp-theme.el, John Wiegley, 2016/02/16
- Re: [ELPA] tramp-theme.el, Michael Albinus, 2016/02/17