use-package.el -> Emacs core

[John Wiegley]

I'd like to integrate use-package.el into Emacs core, as an alternative for
package management to those who do not rely on package.el. I know Stefan had
some reservation, but I think enough people have enjoyed its utility to be
worth including.

Are there any objections to moving this into core before the 25.1 freeze?

John

[Dmitry Gutov]

Post by John Wiegley
Are there any objections to moving this into core before the 25.1 freeze?

Will it add a different way to install packages? Is that wise?

Were it only up to me, I'd just incorporate the features that work well
with package.el.

[John Wiegley]

Post by Dmitry Gutov
Will it add a different way to install packages? Is that wise?
Were it only up to me, I'd just incorporate the features that work well with
package.el.

No, it does not install packages. There is a keyword, :ensure, which causes it
to use package.el to install a configured package if it is not already
present.

`use-package' is a macro to abstract a common pattern among .emacs files, such
as:

(add-hook 'foo-init-hook 'some-function)
(add-to-list 'auto-mode-alist '("\\.foo$" . foo-mode))
(eval-after-load "foo-mode"
'(progn
(define-key foo-mode-map (kbd "C-c k") 'foo-hello)))

It abstracts the common cases I encountered in my use of 100+ Emacs packages,
and macroexpands to code that tries to minimize Emacs load time as much as
possible. It also adds features that would be cumbersome to do manually, such
as optionally installing an idle-timer so a package is always loaded if Emacs
has been idle for X seconds.

(use-package foo-mode
:mode "\\.foo$"
:bind (:map foo-mode-map
("C-c k" . foo-hello))
:init (add-hook 'foo-init-hook 'some-function))

There is a README with examples at:

https://github.com/jwiegley/use-package

I also discuss it with Sacha Chua in a video:

http://sachachua.com/blog/2015/04/john-wiegley-on-organizing-your-emacs-configuration-with-use-package/

John

[Dmitry Gutov]

Post by John Wiegley
No, it does not install packages. There is a keyword, :ensure, which causes it
to use package.el to install a configured package if it is not already
present.

Um, yes. That part I'm aware of. :)

Post by John Wiegley
`use-package' is a macro to abstract a common pattern among .emacs files, such
as: ...

So you meant "who do not rely on package.el UI"? That's entirely fine
by me, I also use some of those common patterns.

Thanks.

[Oleh Krehel]

Post by John Wiegley
`use-package' is a macro to abstract a common pattern among .emacs files, such
(add-hook 'foo-init-hook 'some-function)
(add-to-list 'auto-mode-alist '("\\.foo$" . foo-mode))
(eval-after-load "foo-mode"
'(progn
(define-key foo-mode-map (kbd "C-c k") 'foo-hello)))
It abstracts the common cases I encountered in my use of 100+ Emacs packages,
and macroexpands to code that tries to minimize Emacs load time as much as
possible. It also adds features that would be cumbersome to do manually, such
as optionally installing an idle-timer so a package is always loaded if Emacs
has been idle for X seconds.
(use-package foo-mode
:mode "\\.foo$"
:bind (:map foo-mode-map
("C-c k" . foo-hello))
:init (add-hook 'foo-init-hook 'some-function))

I have some reservations for this. While I use use-package, I started
with it long after learning basic Elisp. Essentially, use-package is a
black box that abstracts and creates new syntax. Which is fine for
veteran users, since they have an idea of what it does. But I think it
might be detrimental to new Elisp users. Using the first method, they
learn what `add-hook' is, what `add-to-list' is, what keymaps are etc.
These things are useful in all kinds of places, not just in the context
of setting up packages.

Concerning bind-key: if the functionality is useful, it should be merged
into `define-key', instead of adding yet another syntax for the same
thing.

One more concern that I see is the stability of use-package API. I
wouldn't want to add logic to my config to disable the built-in
use-package and install the new version to use a new feature. This was
the case for CEDET for a long time, and it was a headache.

Having said all that, I'm against adding use-package to the core. It
would add potential headache without adding utility, since I don't see
any code in the core benefiting from re-using use-package. I am for
augmenting `define-key' with `bind-key' features, though.

[Juanma Barranquero]

Post by Oleh Krehel
I have some reservations for this. While I use use-package, I started
with it long after learning basic Elisp. Essentially, use-package is a
black box that abstracts and creates new syntax. Which is fine for
veteran users, since they have an idea of what it does. But I think it
might be detrimental to new Elisp users. Using the first method, they
learn what `add-hook' is, what `add-to-list' is, what keymaps are etc.
These things are useful in all kinds of places, not just in the context
of setting up packages.

Wouldn't that be an argument against Customize, too?

J

[Oleh Krehel]

Post by Juanma Barranquero

Post by Oleh Krehel
I have some reservations for this. While I use use-package, I started
with it long after learning basic Elisp. Essentially, use-package is a
black box that abstracts and creates new syntax. Which is fine for
veteran users, since they have an idea of what it does. But I think it
might be detrimental to new Elisp users. Using the first method, they
learn what `add-hook' is, what `add-to-list' is, what keymaps are etc.
These things are useful in all kinds of places, not just in the context
of setting up packages.

Wouldn't that be an argument against Customize, too?

Customize is for people that aren't yet ready to learn Elisp. Once they
do, it indeed becomes redundant. I used Customize when I started out
around 5 years ago. I don't use it now, except for providing it to the
users of my packages.

Use-package is already an Elisp thing. We should encourage the core
Elisp to be simple to learn, because it is actually very simple. Not
anymore so with macros like `cl-loop', `pcase' and `use-package'. They
are powerful, but /they are their own language/ completely separate from
Elisp. They have their place, but in my opinion Elisp newbies should not
be encouraged to use them. And including `use-package' into the core
somehow promotes and recommends the use of it over the built-in
facilities, which are newbie-friendly, while `use-package' is not.

[Juanma Barranquero]

Post by Oleh Krehel
Customize is for people that aren't yet ready to learn Elisp. Once they
do, it indeed becomes redundant.

Then, that's an argument *for* use-package. It's for users that aren't yet
ready to learn Elisp, but who want to load a package easily from their
init.el.

use-package is syntactic sugar, yes, and as such, it's easier to use that
the "real deal". It is its own language, but that's a feature: if you're a
user not interested in learning Elisp, to borrow from Phillip's example,
certainly

(use-package foo
:load-path "~/foo"
:commands foo-a foo-b foo-c
:defer 5
)

seems much easier than

(progn
(eval-and-compile
(push "~/foo" load-path))
(run-with-idle-timer 5 nil #'require 'foo nil t)
(unless
(fboundp 'foo-a)
(autoload #'foo-a "foo" nil t))
(unless
(fboundp 'foo-b)
(autoload #'foo-b "foo" nil t))
(unless
(fboundp 'foo-c)
(autoload #'foo-c "foo" nil t)))

[Oleh Krehel]

Customize is for people that aren't yet ready to learn Elisp. Once they
do, it indeed becomes redundant.

Then, that's an argument *for* use-package. It's for users that aren't yet ready to learn Elisp, but who want to load a package easily from their init.el.
use-package is syntactic sugar, yes, and as such, it's easier to use that the "real deal". It is its own language, but that's a feature: if you're a user not interested in learning Elisp, to borrow from Phillip's example, certainly

I have a completely opposite opinion regarding syntactic sugar: it's
detrimental unless you know what it does. In fact, I generally dislike
it even if I know what it does (see my thread on `pcase').

A user who's copy-pasting syntactic sugar won't see the structure behind
it. A user who's copy-pasting a bunch of `setq', `define-key' and
`add-hook' statements will eventually see the pattern and actually learn
the language.

(use-package foo
:load-path "~/foo"
:commands foo-a foo-b foo-c
:defer 5
)
seems much easier than
(progn
(eval-and-compile
(push "~/foo" load-path))
(run-with-idle-timer 5 nil #'require 'foo nil t)
(unless
(fboundp 'foo-a)
(autoload #'foo-a "foo" nil t))
(unless
(fboundp 'foo-b)
(autoload #'foo-b "foo" nil t))
(unless
(fboundp 'foo-c)
(autoload #'foo-c "foo" nil t)))

The above `use-package' example essentially translates to 0 lines of
code if one uses package.el, since all commands are autoloaded
anyway. Regarding idle loading, I've found exactly one use for it - Org:
it simply doesn't pay off for the other packages.

Compare to this code, if the user decides against package.el for some reason:

(add-to-list 'load-path "~/foo")
(require 'foo)

The above 2 lines show how Emacs actually works, and are in fact very
simple. And they teach the new user `add-to-list' and `require' which
are relevant absolutely everywhere, not just in init config setups.

[Juanma Barranquero]

Post by Oleh Krehel
I have a completely opposite opinion regarding syntactic sugar: it's
detrimental unless you know what it does.

I think you're assuming that someone who uses such syntactic sugar will
eventually want to learn what's underneath the sugar coating. Some do, some
don't. I've had colleagues who were happy using Emacs but wouldn't want to
learn even the simplest thing about elisp.

[John Wiegley]

Post by Juanma Barranquero

Post by Oleh Krehel
I have a completely opposite opinion regarding syntactic sugar: it's
detrimental unless you know what it does.

I think you're assuming that someone who uses such syntactic sugar will
eventually want to learn what's underneath the sugar coating. Some do, some
don't. I've had colleagues who were happy using Emacs but wouldn't want to
learn even the simplest thing about elisp.

I agree, Juanma. I see what Oleh is saying pedagogically, but there are *many*
Emacs users who will never want to know anything about Emacs Lisp. Even if
they cut&paste an `add-to-list' form from some blog post -- and even given the
obvious nature of the name -- they won't know what Lisp lists are, or why they
need to be added to, or any of the things we take for granted. They just want
their Emacs to work.

use-package.el is a valuable DSL, in my opinion, because package configuration
is the one place in Emacs where non-Lisp programmers (and people who don't
want to become programmers) are forced to use Emacs Lisp to configure Emacs in
ways not allowed by the customization interface.

To suggest that we might lose an educational opportunity because we aren't
driving them towards define-key and with-eval-after-load, is to think of Emacs
as a Lisp environment rather than a text editor. Those who are motivated will
learn what these things do anyway; those who are not just want to get stuff
done with Emacs.

To me the primary reasons for having a DSL are: It makes it easier to do the
Right Thing; there are fewer things you need to learn; it offers more targeted
error handling and reporting; and for those who will cargo cult anyway, it
makes Emacs configuration (i.e., not Lisp, but configuration) more uniform
and approachable.

Oleh's arguments against use-package.el seems to be that it will widen the gap
between users and Lisp; I want it to narrow the gap between users and Emacs.

John

Summary of responses so far:

For (7):

- Nicolas Petton
- Joakim Verona
- Phillip Lord
- Dimtry Gutov
- Artur Malabarb
- Kaushal Modi
- Ted Zlatanov

Cautious (1):

- Andreas Röhler

Against (2):

- Oleh Krehel - It encourages people away from learning Elisp
- João Távora - Adds too many bells & whistles
- [Stefan Monnier] - It detracts from authors taking package.el more seriously (?)

[João Távora]

Post by John Wiegley
- Oleh Krehel - It encourages people away from learning Elisp
- João Távora - Adds too many bells & whistles
- [Stefan Monnier] - It detracts from authors taking package.el more seriously (?)

I missed the recent changes in emacs-devel regarding maintainership. I
understand
you, John, are the head maintainer, but has emacs-devel moved to a
"vote" system?

Also "adds too many bells & whistles" is not a good summary of my
opinion. I'm not even
sure I am "against it". I haven't seen any fair comparisons. Basically
"wants to see
fair comparisons between different alternatives" would be a more
objective summary, if
such a thing is needed

[John Wiegley]

Post by João Távora
I missed the recent changes in emacs-devel regarding maintainership. I
understand you, John, are the head maintainer, but has emacs-devel moved to
a "vote" system?

emacs-devel hasn't moved to a vote system, but I prefer to rule by consensus
when feasible. People have a lot of experience and expertise that I do not,
so I want to gather feedback before committing anything on this scale.

Post by João Távora
Also "adds too many bells & whistles" is not a good summary of my opinion.
I'm not even sure I am "against it". I haven't seen any fair comparisons.
Basically "wants to see fair comparisons between different alternatives"
would be a more objective summary, if such a thing is needed

Yes, we do need this summary. I'll craft a proposal for the Emacs Wiki, then,
as the way to move forward.

John

[Juanma Barranquero]

Post by John Wiegley
- Nicolas Petton
- Joakim Verona
- Phillip Lord
- Dimtry Gutov
- Artur Malabarb
- Kaushal Modi
- Ted Zlatanov

I'm for

J

[Dmitry Gutov]

Post by John Wiegley
- Nicolas Petton
- Joakim Verona
- Phillip Lord
- Dimtry Gutov
- Artur Malabarb
- Kaushal Modi
- Ted Zlatanov

I simply do not mind (too much). But it can go into GNU ELPA just as
well, as far as I'm concerned.

[Stephen Leake]

Post by Juanma Barranquero

Post by John Wiegley
- Nicolas Petton
- Joakim Verona
- Phillip Lord
- Dimtry Gutov
- Artur Malabarb
- Kaushal Modi
- Ted Zlatanov

I'm for

Would you support putting it in Gnu ELPA instead?

It seems it's already there.

I'm trying to clarify ELPA vs core policy.

[Juanma Barranquero]

On Wed, Nov 11, 2015 at 1:37 AM, Stephen Leake <

Post by Stephen Leake
Would you support putting it in Gnu ELPA instead?

Yes.

[Drew Adams]

package configuration is the one place in Emacs where non-Lisp
programmers (and people who don't want to become programmers)
are forced to use Emacs Lisp to configure Emacs in
ways not allowed by the customization interface.

Wrong, in two ways:

1. No one is required to use packages, AFAIK.

2. Binding keys requires Lisp. The Customize UI is not
sufficient. (This is unfortunate - there should be
a reasonable Customize UI for key bindings.)

(Of course, no one is required to bind keys either.)


---- OT ----

FWIW, I use this to let users use Customize to bind keys.
I don't claim it is ideal. Just one attempt to provide
something.

(define-widget 'icicle-key-definition 'lazy
"Key definition type for Icicle mode keys.
A list of three components: KEY, COMMAND, CONDITION, that represents
an `icicle-mode-map' binding of COMMAND according to KEY, if CONDITION
evaluates to non-nil.

KEY is either a key sequence (string or vector) or a command.
COMMAND is a command.
CONDITION is a sexp.

If KEY is a command, then the binding represented is its remapping to
COMMAND."
:indent 1 :offset 0 :tag ""
:type
'(list
(choice
(key-sequence :tag "Key" :value [ignore])
;; Use `symbolp' instead of `commandp', in case the
;; library defining the command is not loaded.
(restricted-sexp :tag "Command to remap"
:match-alternatives (symbolp) :value ignore))
;; Use `symbolp' instead of `commandp'...
(restricted-sexp :tag "Command"
:match-alternatives (symbolp) :value ignore)
(sexp :tag "Condition")))

Example:

(defcustom foo
`((,(kbd "C-x m") alpha t)
(,(kbd "C-x C-m -") beta t)
(,(kbd "C-x C-m +") gamma (require 'toto nil t))
(,(kbd "C-x v -") delta t))
"*List of key bindings for blah..."
:type '(repeat icicle-key-definition) :group 'some-group)

[David Kastrup]

Post by Oleh Krehel

Post by Juanma Barranquero

Customize is for people that aren't yet ready to learn Elisp. Once they
do, it indeed becomes redundant.

Then, that's an argument *for* use-package. It's for users that
aren't yet ready to learn Elisp, but who want to load a package
easily from their init.el.
use-package is syntactic sugar, yes, and as such, it's easier to use
if you're a user not interested in learning Elisp, to borrow from
Phillip's example, certainly

I have a completely opposite opinion regarding syntactic sugar: it's
detrimental unless you know what it does. In fact, I generally dislike
it even if I know what it does (see my thread on `pcase').
A user who's copy-pasting syntactic sugar won't see the structure behind
it. A user who's copy-pasting a bunch of `setq', `define-key' and
`add-hook' statements will eventually see the pattern and actually learn
the language.

`setq' is syntactic sugar for `set' and `quote'. `define-key' and
`add-hook' are syntactic sugar for various forms of `set'.

The whole point of not using primitives is not having to provide every
part of some pattern by hand.

[Oleh Krehel]

Post by David Kastrup
`setq' is syntactic sugar for `set' and `quote'. `define-key' and
`add-hook' are syntactic sugar for various forms of `set'.

`setq' is a simple and reusable abstraction (this one in particular has
survived the test of time, having been used and abused for decades), so
are `define-key' and `add-hook'.

Post by David Kastrup
The whole point of not using primitives is not having to provide every
part of some pattern by hand.

My point is that it's harmful to aggregate every single thing into one
construct, e.g:

(use-package foo
:setq (bar 1 baz 2 boo 3))

instead of

(require 'foo)
(setq bar 1)
(setq baz 2)
(setq boo 3)

It's like multiple inheritance vs. composition in C++: composition is
usually more clear.

[João Távora]

Post by David Kastrup
`setq' is syntactic sugar for `set' and `quote'. `define-key' and
`add-hook' are syntactic sugar for various forms of `set'.
The whole point of not using primitives is not having to provide every
part of some pattern by hand.

I don't think anyone is arguing against the usefulness of macros in
general, only skeptic macros that introduce a totally new mini-language
for a lot independent functionality, most of it already user-visible and
documented in the user manual. Such is the case of `use-package'

For fairness, such is also the case of the `define-minor-mode' macro,
which is invaluable, but that is for package developers, not users, and
that makes a difference in my opinion.

João

[John Wiegley]

I don't think anyone is arguing against the usefulness of macros in general,
only skeptic macros that introduce a totally new mini-language for a lot
independent functionality, most of it already user-visible and documented in
the user manual. Such is the case of `use-package'

use-package is not aimed at replacing the Lisp skills of the members of this
list; it is also for those whose only exposure to add-hook is an opaque thing
they copied from a web page. They will never read up on what it does, and
forcing them to see it does not encourage them to become programmers.

(use-package python-mode :load-path "site-lisp/python-mode" :mode "\\.py$")

This is also something they'll just copy and paste, maybe not even knowing
what a mode is. Compare with:

(add-to-list 'load-path (expand-file-name "site-lisp/python-mode"
user-emacs-directory))
(autoload 'python-mode "python-mode" nil t)
(add-to-list 'auto-mode-alist '("\\.py$" . python-mode))

"Only a mother could love that". To an Emacs Lisp expert, the latter does have
some beauty, owing to its directness, and clarity with regard to fundamental
operations. Somehow, though, I prefer the former.

John

[João Távora]

Post by John Wiegley

I don't think anyone is arguing against the usefulness of macros in general,
only skeptic macros that introduce a totally new mini-language for a lot
independent functionality, most of it already user-visible and documented in
the user manual. Such is the case of `use-package'

use-package is not aimed at replacing the Lisp skills of the members of this
list; it is also for those whose only exposure to add-hook is an opaque thing
they copied from a web page. They will never read up on what it does, and
forcing them to see it does not encourage them to become programmers.
(use-package python-mode :load-path "site-lisp/python-mode" :mode "\\.py$")
This is also something they'll just copy and paste, maybe not even knowing
(add-to-list 'load-path (expand-file-name "site-lisp/python-mode"
user-emacs-directory))
(autoload 'python-mode "python-mode" nil t)
(add-to-list 'auto-mode-alist '("\\.py$" . python-mode))

But, if using package.el (or el-get), I don't need to write this, right? It's
already setup by python.el and by whatever method I used to install it.

For this simple example, doesn't `package-install' do exactly the same
thing? Why should we have a new way to solve the same problem?

Can we have an example of real-world third-party emacs packages (perhaps
one in (m)ELPA and another one not on any package repository) and a fair
comparison of the different alternatives there are for setting it up? I
haven't seen any convincing examples, but I'm sure you can come up with
some.

I can help include other third-party alternatives like `el-get' for
instance in that comparison.

I think this is what we need before coming to a more objective
conclusion regarding usefulness.

Regarding functionality, correctness and the needs for documenting such
a high-profile feature in the user manual, that's a whole different
matter.

Post by John Wiegley
"Only a mother could love that". To an Emacs Lisp expert, the latter does have
some beauty, owing to its directness, and clarity with regard to fundamental
operations. Somehow, though, I prefer the former.

Then by all means use it :). But should I have to learn it too?

Do you see my point about the impact that endorsing (another) package
installation/configuration method has for package maintainers?

Note that up until now I'm not talking, as others are, about "confusing"
new users. That is quite hard to measure or estimate. I can only
conjecture that some people are more attracted to the "single form"
aspect of it than to its particular mini-language. I know I am. And
someone mentioned bind-key's advantages and the logging also looks like
a nice feature.

In this sense, the particular merits of each particular feature could be
used to contribute to improving existing functionality, or to add new
functionality that helps everybody, not just fans of
use-package. Wouldn't that satisfy you? Wouldn't that be easier than
introducing and documenting a whole new way of configuring packages,
something that is a super-central pillar of Emacs?

João

[John Wiegley]

Post by João Távora

Post by John Wiegley
(use-package python-mode :load-path "site-lisp/python-mode" :mode "\\.py$")

But, if using package.el (or el-get), I don't need to write this, right?
It's already setup by python.el and by whatever method I used to install it.

Correct. In fact, I'd _prefer_ it if the user didn't have to touch use-package
at all, and could get by with package.el and customize. use-package is the
"next step", after those two.

Post by João Távora
Can we have an example of real-world third-party emacs packages (perhaps one
in (m)ELPA and another one not on any package repository) and a fair
comparison of the different alternatives there are for setting it up? I
haven't seen any convincing examples, but I'm sure you can come up with
some.
I can help include other third-party alternatives like `el-get' for instance
in that comparison.

The only alternatives we need to consider right now is with and without
use-package.el -- for details not taken care of by package.el. el-get is
neither in core nor ELPA, so that knowledge doesn't help this discussion.

Post by João Távora
Then by all means use it :). But should I have to learn it too?

Not necessarily. There are plenty of areas of Emacs that you don't have to
learn, but that doesn't prohibit them from being in Emacs. If you see a bug
dealing with use-package and don't want to handle it, don't.

Post by João Távora
In this sense, the particular merits of each particular feature could be
used to contribute to improving existing functionality, or to add new
functionality that helps everybody, not just fans of use-package. Wouldn't
that satisfy you? Wouldn't that be easier than introducing and documenting a
whole new way of configuring packages, something that is a super-central
pillar of Emacs?

It's not a "new way" of configuring packages. It's a WAY period. The
alternative, beyond package and customize, is to learn enough Emacs Lisp to
manually configure the package yourself. This is beyond many users' comfort
area, as I've learned from helping people with their Emacs setups.

I do want use-package in core, although it should probably be in ELPA for
25.1, until we flesh out what will happen to bind-key, a pillar feature. It
should also be documented as an official way of handling more complex
configuration scenarios. Such documentation would also, to answer Oleh's
concern, reference the various Emacs Lisp topics one would need to learn to
understand the logic beneath the sugar.

John

[João Távora]

Post by John Wiegley

Post by João Távora

Post by John Wiegley
(use-package python-mode :load-path "site-lisp/python-mode" :mode "\\.py$")

But, if using package.el (or el-get), I don't need to write this, right?
It's already setup by python.el and by whatever method I used to install it.

Correct. In fact, I'd _prefer_ it if the user didn't have to touch use-package
at all, and could get by with package.el and customize. use-package is the
"next step", after those two.

Righto. So after having agreed that `python.el' is not an ideal
demonstration of the potential of use-package, in fact it's useless in
that one, can you give some better examples?

Post by John Wiegley
The only alternatives we need to consider right now is with and without
use-package.el -- for details not taken care of by package.el. el-get is
neither in core nor ELPA, so that knowledge doesn't help this
discussion.

But aren't we discussing the potential installation in Emacs of *a* new
tool to ease the installation and the configuration of package? If
el-get is such a tool, why shouldn't it be included in this discussion?

Here's a very simple example: here's a way to configure markdown-mode

(package-install 'markdown-mode)
(with-eval-after-load 'markdown-mode
(modify-syntax-entry ?` "\"" markdown-mode-syntax-table))

Here's a completely different way using el-get (actually, untested and I
suspect there's a simpler way, but I think it does what I want)

(add-to-list 'el-get-sources
'(:name 'markdown-mode
:after (modify-syntax-entry ?` "\"" markdown-mode-syntax-table)))
(el-get 'sync 'markdown-mode)

And, for completeness, here's the package.el-less way for people who
downloaded it separately?

(add-to-list 'load-path "path/to/markdown-mode")
(require 'markdown-mode-autoloads)
(with-eval-after-load 'markdown-mode
(modify-syntax-entry ?` "\"" markdown-mode-syntax-table))

How would use-package handle this simple example?

Post by John Wiegley

Post by João Távora
Then by all means use it :). But should I have to learn it too?

Not necessarily. There are plenty of areas of Emacs that you don't have to
learn, but that doesn't prohibit them from being in Emacs. If you see a bug
dealing with use-package and don't want to handle it, don't.

I don't think you understood. I don't mean bugs in `use-package', I mean
bug reports in my extensions that are reported in terms of
`use-package'. Should I not handle those bugs?

Post by John Wiegley
It's not a "new way" of configuring packages. It's a WAY period. The

I don't understand. It's a "new way", at least for me.

João

[John Wiegley]

Post by João Távora
Here's a very simple example: here's a way to configure markdown-mode
(package-install 'markdown-mode)
(with-eval-after-load 'markdown-mode
(modify-syntax-entry ?` "\"" markdown-mode-syntax-table))
How would use-package handle this simple example?

To match those semantics, you'd use:

(use-package markdown-mode
:ensure t
:config (modify-syntax-entry ?` "\"" markdown-mode-syntax-table))

Post by João Távora
I don't think you understood. I don't mean bugs in `use-package', I mean bug
reports in my extensions that are reported in terms of `use-package'. Should
I not handle those bugs?

Ah. Does it help that you can macro-expand use-package forms, so that you see
what the underlying Emacs Lisp calls? I try hard to make the expanded code
"look like what you'd write", as much as possible.

Post by João Távora
I don't understand. It's a "new way", at least for me.

I meant that between customize and Emacs Lisp, there nothing in between for
users of core Emacs right now. Beyond Emacs, there do exist several other
ways.

John

[João Távora]

Post by John Wiegley

Post by João Távora
(package-install 'markdown-mode)
(with-eval-after-load 'markdown-mode
(modify-syntax-entry ?` "\"" markdown-mode-syntax-table))

(use-package markdown-mode
:ensure t
:config (modify-syntax-entry ?` "\"" markdown-mode-syntax-table))

OK, so we would agree that in this particular example it doesn't bring a
great advantage, if any. Perhaps you could provide another example where
you definitely think it does.

Post by John Wiegley

Post by João Távora
I don't think you understood. I don't mean bugs in `use-package', I mean bug
reports in my extensions that are reported in terms of `use-package'. Should
I not handle those bugs?

Ah. Does it help that you can macro-expand use-package forms, so that you see
what the underlying Emacs Lisp calls? I try hard to make the expanded code
"look like what you'd write", as much as possible.

That's what I would do yes. But then I have to have a running emacs with
`use-package' myself, right? I've seen some macroexpansions of it
somewhere in this thread and it's not particularly pretty (also not
particularly correct apparently: see my criticism of the use of fboundp
and autoload, for example).

But I can't resist pointing out a certain irony in your argument: if
use-package is not hiding any ugly implementation details, there's
really no use for it :-).

For contrast, and quite a scare, see the macroexpansions of
`define-minor-mode` or `define-globalized-minor-mode'. yucky.

On the other hand, I have to admit that by participanting in this
discussion I ended up probably learning more than enough of the
use-package minilanguage to handle such a bug report.

So I don't know. Count me in the "initially against, but now doesn't
care" category and let the masses decide :-)

João

[Kaushal Modi]

I would also fit in the cautious category, leaning towards against
(see below for what I mean).

My biggest concern is the duplication and confusion for end-user code.
define-key vs bind-key. As João mentioned in a different context, I
feel this kind of syntactic sugar is probably not OK for end-user
code; providing many options increases the complexity when debugging
code for the user and the maintainer.

My suggestion would be to first merge bind-key into define-key and
sister defuns/macros. If that is feasible, then we can think if
use-package can be merged.

Biggest concerns with bind-key

(1) Plain bind-key macro is not very much different for define-key or
global-set key. I believe its addition is not necessary in the core.
(2) bind-key*, bind-keys, bind-keys* would be good additions but
should they be refactored as define-key* (while retaining the original
define-key arg order) + global-set-key*, define-keys and define-keys*?
(3) How would describe-personal-bindings work? Because if bind-key is
made part of the core, we cannot control which internal package makes
use of it. Write now the only way we know that the user
added/redefined a key is if they made use of one of the bind-key
macros. That luxury will go away once it is part of the core.

About use-package: I also have a opinion that the user will understand
less of how requires, autoloads, eval-after-loads and idle timers work
if they start using use-package as the first thing.

Until we have a solid solution for the above, my vote is against for
both bind-key and use-package.

With that said, would adding bind-key and use-package to GNU Elpa be a
better option?

If we do that,
- There is no concern of duplication and confusion among users that I
mentioned above.
- Maintainers do not have to worry about the use/debug of
use-package+bind-key in the core packages.
- When helping out users debug something, the instructions for
defining keys are pretty consistent: either define-key or
global-set-key (usually the latter) vs the options of
define-key/global-set-key/bind-key/bind-key*/bind-keys/bind-keys*
- Also only the users who know what they are doing would install these packages.
- use-package + bind-key would still reach a wider user-base as not
all users add Melpa to package-archives

[John Wiegley]

Post by Kaushal Modi
My biggest concern is the duplication and confusion for end-user code.
define-key vs bind-key. As João mentioned in a different context, I feel
this kind of syntactic sugar is probably not OK for end-user code; providing
many options increases the complexity when debugging code for the user and
the maintainer.

`define-key' is not really an end-user function, as I've met countless people
who have never even heard of it. `global-set-key' is much more user-facing,
and I could see merging `bind-key' into `global-set-key'.

Post by Kaushal Modi
My suggestion would be to first merge bind-key into define-key and sister
defuns/macros. If that is feasible, then we can think if use-package can be
merged.

I don't see a need for that much caution. The two can proceed in parallel.
use-package.el should go into the ELPA-subset-that-comes-with-Emacs today, and
then receive official blessing and documentation as an announced feature in
25.2.

Post by Kaushal Modi
About use-package: I also have a opinion that the user will understand less
of how requires, autoloads, eval-after-loads and idle timers work if they
start using use-package as the first thing.

Yes! That is the *point*. Emacs is not just for Lisp programmers.

Post by Kaushal Modi
With that said, would adding bind-key and use-package to GNU Elpa be a
better option?

Certainly a good starting place, as long as it's available in the tarball so
that it's immediately available, and users don't have to go through some other
configuration work to start using it.

John

[Drew Adams]

Post by John Wiegley
`define-key' is not really an end-user function,

Until/unless we have an alternative that is more "end-user", it
definitely _is_ an end-user function, and the only one we offer,
for keys on maps other than `global-map'.

End users often want/need to add or change a key binding in
a particular keymap. Questions of how to do that are FAQ.

But yes, `global-set-key' is also a command; `define-key' is not.

Post by John Wiegley
as I've met countless people who have never even heard of it.

That means nothing in this regard. There are countless people,
including countless Emacs users, who have never heard of plenty
of end-user features. There are probably countless such who
have never heard of `M-x' or `C-h f' or even `C-h C-h'...

Post by John Wiegley
`global-set-key' is much more user-facing,

Only because (1) users more commonly add/change global bindings
and (2) it is also a command.

But both are "end-user functions" and "user-facing". (That
doesn't mean that something better cannot be found for end
users to use.)

[John Wiegley]

Post by Drew Adams
End users often want/need to add or change a key binding in
a particular keymap. Questions of how to do that are FAQ.
But yes, `global-set-key' is also a command; `define-key' is not.

Yep, enriching global-set-key to take on the role of bind-key will mean
expanding it to handle keymaps, and this would make it the "Right Way" for end
users to modify their keybindings.

Core Emacs code should always use define-key, so that global-set-key bindings
can appear in the personal keybindings list.

Post by Drew Adams

Post by John Wiegley
as I've met countless people who have never even heard of it.

That means nothing in this regard. There are countless people, including
countless Emacs users, who have never heard of plenty of end-user features.
There are probably countless such who have never heard of `M-x' or `C-h f'
or even `C-h C-h'...

It means something to me, Drew, and I'm the one acting on behalf of those
users.

Post by Drew Adams
But both are "end-user functions" and "user-facing". (That
doesn't mean that something better cannot be found for end
users to use.)

I think that moving define-key to an internal/programmatic mechanism, and
enriching global-set-key toward an external/user mechanism, with all the
features of bind-key, is the solution we both want.

John

[Kaushal Modi]

Post by John Wiegley
Yep, enriching global-set-key to take on the role of bind-key will mean
expanding it to handle keymaps, and this would make it the "Right Way" for end
users to modify their keybindings.

But then wouldn't global-set-key become a misnomer? global-set-key is
to set bindings only in the global-map.
Should `define-key` be enriched instead?

[John Wiegley]

But then wouldn't global-set-key become a misnomer? global-set-key is to set
bindings only in the global-map. Should `define-key` be enriched instead?

I'd like to rename it to "set-key", with global-set-key as an alias.

John

[Drew Adams]

Post by John Wiegley

Post by Drew Adams

Post by John Wiegley
`define-key' is not really an end-user function,
...
as I've met countless people who have never even heard of it.

That means nothing in this regard. There are countless people,
including countless Emacs users, who have never heard of plenty
of end-user features. There are probably countless such who
have never heard of `M-x' or `C-h f' or even `C-h C-h'...

It means something to me, Drew, and I'm the one acting on behalf
of those users.

Sure, but it's not an argument that just _because_ some end users
are unaware of something that is used by other end users (especially
if there is no alternative to using that something) it _follows_
that that thing is not "end-user". That's a phony argument.

`define-key' is "end-user" because end users sometimes want/need
to use keymaps other than `global-map', and it is their only way
to do that. It might not be "end-user" enough for you, but that
is something different.

It is only the argument that I find fault with, not the attempt
to come up with something better or more end-userish.

Post by John Wiegley

Post by Drew Adams
But both are "end-user functions" and "user-facing". (That
doesn't mean that something better cannot be found for end
users to use.)

I think that moving define-key to an internal/programmatic mechanism, and
enriching global-set-key toward an external/user mechanism, with all the
features of bind-key, is the solution we both want.

That's not a solution that I proposed or necessarily want.
Just as I have no problem with end users using `setq', I have
no problem with them using `define-key'.

That doesn't mean that I oppose giving them something better
as well (for both `setq' and `define-key'). But that does
not imply "moving define-key to an internal/programmatic
mechanism" (whatever you might mean by that).

FWIW, I also object to some kind of definite line, dividing
non-Lisp Emacs users from "internal/programmatic mechanisms"
and Lisp. There is naturally a spectrum of Emacs usage that
involves different degrees of using Lisp. And that's a good
thing. All kinds of Emacs user are welcome.

Attempts to provide non-Lisp ways to do things can be helpful.
(They are not always/necessarily helpful, however.) But in
general my attitude is that Emacs _is_ Elisp - Emacs is a Lisp
environment. That is what makes Emacs different and specially
useful.

It is a mistake to draw a hard line between Emacs "end use"
and Lisp. Lisp vastly increases one's use of Emacs. Without
some use of Lisp, you are not really taking advantage of Emacs.
You might even say that you are not _really_ using it.

We should, yes, cater to helping novice users who do not
know Lisp. But we should also encourage the use of Lisp
with Emacs, not discourage it. You don't need Lisp to
start using Emacs. But if you really want to use Emacs
then you will want to learn some Lisp. That should not
be because you _have to_ learn it, but because you can
do so much more with Emacs if you do.

Lack of Lisp knowledge should not be an unnecessary obstacle
to using basic Emacs features. But we should not hide Lisp
from users, as something that isn't helpful to them or
something they really shouldn't bother with.

The other aspect of not having a dividing line between
internal/programmer and external/end-user is that this is
what free software is about: users can and do dive into
whatever level of the "internals" - the source code - they
feel like. And they are not discouraged from doing so -
quite the contrary.

Users _are_ developers in this context, even just by
suggesting things that can affect them directly, but also
by, themselves, getting involved with Lisp and coming up
with other ways to do things. GNU Emacs has a privileged
role to play in this regard. It is the use-it, customize-it,
fiddle-with-it, extend-it end-user application par excellence.

(Just one opinion.)

Post by John Wiegley
I'm the one acting on behalf of those users.

^^^^^^^^^^^

You are not the only one. Lots of us here keep those
users in mind and try to act on their behalf. I'm glad
you do too. Welcome aboard. ;-)

[John Wiegley]

Sure, but it's not an argument that just _because_ some end users are
unaware of something that is used by other end users (especially if there is
no alternative to using that something) it _follows_ that that thing is not
"end-user". That's a phony argument.
`define-key' is "end-user" because end users sometimes want/need to use
keymaps other than `global-map', and it is their only way to do that. It
might not be "end-user" enough for you, but that is something different.
It is only the argument that I find fault with, not the attempt to come up
with something better or more end-userish.

Ah, OK, I concede your point. I have no grounds for saying define-key *isn't*
user facing, just that I'd like a clearer divide between what developers would
use for this functionality, and something that caters more to users.

FWIW, I also object to some kind of definite line, dividing non-Lisp Emacs
users from "internal/programmatic mechanisms" and Lisp. There is naturally a
spectrum of Emacs usage that involves different degrees of using Lisp. And
that's a good thing. All kinds of Emacs user are welcome.

Yes!

It is a mistake to draw a hard line between Emacs "end use" and Lisp. Lisp
vastly increases one's use of Emacs. Without some use of Lisp, you are not
really taking advantage of Emacs. You might even say that you are not
_really_ using it.
We should, yes, cater to helping novice users who do not know Lisp. But we
should also encourage the use of Lisp with Emacs, not discourage it. You
don't need Lisp to start using Emacs. But if you really want to use Emacs
then you will want to learn some Lisp. That should not be because you _have
to_ learn it, but because you can do so much more with Emacs if you do.

So we probably agree that Emacs is a spectrum from "application" to
"programming heaven", and that while we'd like to be a good tool at every
point along that spectrum, we shouldn't discourage a gradual migration
towards the bliss most of us have found.

Post by John Wiegley
I'm the one acting on behalf of those users.

^^^^^^^^^^^
You are not the only one. Lots of us here keep those users in mind and try
to act on their behalf. I'm glad you do too. Welcome aboard. ;-)

I'm very glad to hear that. :)

John

[Drew Adams]

Post by John Wiegley
So we probably agree that Emacs is a spectrum from "application" to
"programming heaven", and that while we'd like to be a good tool at every
point along that spectrum, we shouldn't discourage a gradual migration
towards the bliss most of us have found.

Yes.

[Kaushal Modi]

I'd also like to add that as use-package is a top-level form, we cannot use
edebug and other defun-specific functions on the functions defined in that
form: http://emacs.stackexchange.com/q/7643/115

I then came up with a custom solution that works for me to make edebugging
possible for such functions. If you notice, it's more like a hack. So
something need to be done to make such defun-related functions work in
use-package too, if we go that route.

[David Kastrup]

Post by Oleh Krehel

Post by Juanma Barranquero

Post by Oleh Krehel
I have some reservations for this. While I use use-package, I started
with it long after learning basic Elisp. Essentially, use-package is a
black box that abstracts and creates new syntax. Which is fine for
veteran users, since they have an idea of what it does. But I think it
might be detrimental to new Elisp users. Using the first method, they
learn what `add-hook' is, what `add-to-list' is, what keymaps are etc.
These things are useful in all kinds of places, not just in the context
of setting up packages.

Wouldn't that be an argument against Customize, too?

Customize is for people that aren't yet ready to learn Elisp. Once
they do, it indeed becomes redundant.

Nonsense. It provides type safety and makes sure that the variables are
set in the intended way. It also makes sure that any followup actions
necessary after setting the variables are being performed.

It's like saying lamp sockets are for people that aren't yet ready to
learn soldering. Once they do, they indeed become redundant.

Post by Oleh Krehel
I used Customize when I started out around 5 years ago. I don't use it
now, except for providing it to the users of my packages.

I don't see that this makes any sense since it means you have to learn
all about the various dependencies and intricacies of every single
package you are going to use.

Post by Oleh Krehel
Use-package is already an Elisp thing.

It's for people that aren't yet read to manage load-file. Or something.
And Elisp is for people that aren't yet ready to learn C.

Post by Oleh Krehel
We should encourage the core Elisp to be simple to learn, because it
is actually very simple. Not anymore so with macros like `cl-loop',
`pcase' and `use-package'. They are powerful, but /they are their own
language/ completely separate from Elisp. They have their place, but
in my opinion Elisp newbies should not be encouraged to use them.

Sorry, but I cannot agree at all. That's like saying C++ users should
not learn about the standard libraries since they should rather write
their own.

Post by Oleh Krehel
And including `use-package' into the core somehow promotes and
recommends the use of it over the built-in facilities, which are
newbie-friendly, while `use-package' is not.

I think you got it backwards.

[Oleh Krehel]

Post by David Kastrup

Post by Oleh Krehel
Customize is for people that aren't yet ready to learn Elisp. Once
they do, it indeed becomes redundant.

Nonsense. It provides type safety and makes sure that the variables are
set in the intended way. It also makes sure that any followup actions
necessary after setting the variables are being performed.

I meant configuring your Emacs with the Customize interface is redundant
once you know Elisp. The type safety and :set handlers are separate from
that.

I only use this thing instead of `setq' for custom vars:

(defmacro csetq (variable value)
`(funcall (or (get ',variable 'custom-set) 'set-default) ',variable ,value))

Post by David Kastrup
It's like saying lamp sockets are for people that aren't yet ready to
learn soldering. Once they do, they indeed become redundant.

Lamp sockets are still relevant. Calling an electrician ("M-x"
`customize-group') isn't relevant.

Post by David Kastrup

Post by Oleh Krehel
I used Customize when I started out around 5 years ago. I don't use it
now, except for providing it to the users of my packages.

I don't see that this makes any sense since it means you have to learn
all about the various dependencies and intricacies of every single
package you are going to use.

Having to learn the various dependencies and intricacies of every single
package I use make perfect sense to me.

Post by David Kastrup

Post by Oleh Krehel
Use-package is already an Elisp thing.

It's for people that aren't yet read to manage load-file. Or something.
And Elisp is for people that aren't yet ready to learn C.

Bad analogy. Elisp is for people what want to get things done faster
than with C.

Post by David Kastrup

Post by Oleh Krehel
We should encourage the core Elisp to be simple to learn, because it
is actually very simple. Not anymore so with macros like `cl-loop',
`pcase' and `use-package'. They are powerful, but /they are their own
language/ completely separate from Elisp. They have their place, but
in my opinion Elisp newbies should not be encouraged to use them.

Sorry, but I cannot agree at all. That's like saying C++ users should
not learn about the standard libraries since they should rather write
their own.

No, it's like saying that it's OK for users to write Boost template
constructs and do QT stuff without learning the basic C++ and STL.

Post by David Kastrup

Post by Oleh Krehel
And including `use-package' into the core somehow promotes and
recommends the use of it over the built-in facilities, which are
newbie-friendly, while `use-package' is not.

I think you got it backwards.

Let's agree to disagree then. John asked for opinions and I gave mine.
What it boils down to is: new users should learn how to use "while"
before they use "loop". And they should be aware that even some veteran
programmers are against the use of "loop" in favor of "while"; they
should not see "while" as training wheels and "loop" as the big boy's
bike.

[Evgeny Panasyuk]

Post by Oleh Krehel

Post by David Kastrup

Post by Oleh Krehel
We should encourage the core Elisp to be simple to learn, because it
is actually very simple. Not anymore so with macros like `cl-loop',
`pcase' and `use-package'. They are powerful, but /they are their own
language/ completely separate from Elisp. They have their place, but
in my opinion Elisp newbies should not be encouraged to use them.

Sorry, but I cannot agree at all. That's like saying C++ users should
not learn about the standard libraries since they should rather write
their own.

No, it's like saying that it's OK for users to write Boost template
constructs and do QT stuff without learning the basic C++ and STL.

It is OK to use Boost.Function or Boost.Spirit before learning every
trick used inside. Yes, you have to read their documentation, but the
same applies "normal/usual" libraries.
Another example is Boost.Preprocessor - it provides high level interface
and uses a lot of tricks to make it portable across very different
(buggy) preprocessor implementations - but you can successfully use it
without knowing every internal trick and detail.

[Alan Mackenzie]

[ Mail-Followup-To: set ]

Post by Evgeny Panasyuk

Post by Oleh Krehel

Post by David Kastrup

Post by Oleh Krehel
We should encourage the core Elisp to be simple to learn, because it
is actually very simple. Not anymore so with macros like `cl-loop',
`pcase' and `use-package'. They are powerful, but /they are their own
language/ completely separate from Elisp. They have their place, but
in my opinion Elisp newbies should not be encouraged to use them.

Sorry, but I cannot agree at all. That's like saying C++ users should
not learn about the standard libraries since they should rather write
their own.

No, it's like saying that it's OK for users to write Boost template
constructs and do QT stuff without learning the basic C++ and STL.

It is OK to use Boost.Function or Boost.Spirit before learning every
trick used inside. Yes, you have to read their documentation, but the
same applies "normal/usual" libraries.
Another example is Boost.Preprocessor - it provides high level interface
and uses a lot of tricks to make it portable across very different
(buggy) preprocessor implementations - but you can successfully use it
without knowing every internal trick and detail.

I think this part of the thread, although interesting, no longer has
anything to do with Emacs. Therefore it is a prime example of what
should move to emacs-***@gnu.org.

I have attempted to direct follow ups there. This is something of an
experiment.

[Wolfgang Jenkner]

Post by David Kastrup
It also makes sure that any followup actions
necessary after setting the variables are being performed.

Sure, :set is kind of a custom(er) lock-in.

[Drew Adams]

Post by Wolfgang Jenkner

Post by David Kastrup
It also makes sure that any followup actions
necessary after setting the variables are being performed.

Sure, :set is kind of a custom(er) lock-in.

Dunno whether that was supposed to be a joke.

:set is a hook for variables. It runs code whenever
the variable is set. That's a feature that you can
use in your programming. It doesn't lock anyone into
anything.

We should have :set, :type etc. available for defvar
as well as defcustom, IMHO.

(Someone will no doubt chime in now about advising variables.)

[Wolfgang Jenkner]

Post by Drew Adams

Post by Wolfgang Jenkner

Post by David Kastrup
It also makes sure that any followup actions
necessary after setting the variables are being performed.

Sure, :set is kind of a custom(er) lock-in.

Dunno whether that was supposed to be a joke.

Quite serious, if a bit laconic.

Post by Drew Adams
:set is a hook for variables. It runs code whenever
the variable is set. That's a feature that you can
use in your programming. It doesn't lock anyone into
anything.

Please see

http://permalink.gmane.org/gmane.emacs.bugs/107690

The bug report's author makes my point in an admirably eloquent way.

Wolfgang :-)

[Drew Adams]

Post by Oleh Krehel
Customize is for people that aren't yet ready to learn Elisp.

Wrong - if you meant "only" for such people.

Customize is for anyone who is wise enough to take advantage
of type-checking (:type), :set, :initialize, and other
Customize features.

And Customize (`defcustom') is not only the Customize UI.
It includes all of the `custom-*' and `customize-*' functions.

Post by Oleh Krehel
Once they do, it indeed becomes redundant.

No, it ("indeed") does not. Unless you do not consider using
any of the Lisp functions in cus-*.el as part of Customize.

Or unless you are prepared to write your own Lisp to do what
they do. (At a certain level, all Lisp code except a very
few primitives can be called "redundant".)

It is a too common misconception (perhaps especially among
near-newbies) that Customize is only for newbies. It's
too bad to see folks here propagate the same misconception.
That is the wrong message, not only for newbies but for
those who are no longer newbies.

Too many people think they are being Lispy by using only
`setq' to set option values in their init files (and later
they wonder why some things don't work, only to be told
about :type or about :set functions etc.).

Post by Oleh Krehel
I used Customize when I started out around 5 years ago.
I don't use it now, except for providing it to the
users of my packages.

You don't use `custom-set-variables' or `custom-set-faces'
or any other `custom*' functions?

Or perhaps you use only simple options that have no :set
or :initialize triggers or other complications?

Or perhaps you don't need type-checking> Or more likely,
perhaps the options you use do not have very complex :type
control?

Too many defcustoms are written with rudimentary :type
declarations, essentially trying to turn defcustom into
defvar. (And this includes in the Emac core.) Dommage.

[John Wiegley]

It is a too common misconception (perhaps especially among near-newbies)
that Customize is only for newbies. It's too bad to see folks here propagate
the same misconception. That is the wrong message, not only for newbies but
for those who are no longer newbies.

Just to chime in: I use customize, love customize in fact, and try to
configure as much as I can using the customize interface. It's clear,
declarative, and gives me a visual way to browse through my settings for
various packages. It stops me from making stupid errors. I love it.

John

[João Távora]

Hi,

I'm reticent of this addition. In lisp (or anywhere else for that
matter), I don't like to learn new syntax unless the advantages are
clear. A perfect example would be cl's LOOP, which is it's own
mini-language which I've learned to love.

Of course adding use-package.el to Emacs wouldn't force me to use
it. However, as the maintainer of a few packages, I have to read users'
bug reports, and that mostly means I would have to learn
use-package.el's syntax, since users would more legitimately consider it
a proper way to install the packages I maintain.

Now, I see use-package.el as a `with-eval-after-load' replacement with
more bells and whistles. It appears to be weak in that sense: each of
those bells and whistles usually already has a nice concise way to
control in stock Emacs, so it's unfortunate that use-package.el
introduces new ones. And it doesn't even appear to save lines of
configuration code while at it, just someone shorter sexps. For example,
I don't see the benefit of replacing:

(when window-system
(with-eval-after-load 'foo
... more configuration
))

with

(use-package foo
:if window-system
... more configuration
)

The generic example you gave for `foo-mode' is also not to convincing to
me. I would write it as

(with-eval-after-load 'foo-mode
(add-hook 'foo-init-hook 'some-function)
(define-key foo-mode-map (kbd "C-c k") 'foo-hello))
(add-to-list 'auto-mode-alist '("\\.foo$" . foo-mode))

Which is just as long, just as readable and less voodoo than
use-package. If I grep for "auto-mode-alist" in my configuration, I'm
sure to find who's setting it.

But perhaps I can be convinced otherwise or am missing something
fundamentally. Can you provide more examples of package configurations
where you definitely think it beats `with-eval-after-load' or other
alternatives? I'm guessing those would be examples that include
automatically installing a package (lazily?) from ELPA, but you tell me.

Thanks,
João

[Pedro Silva]

Post by João Távora
But perhaps I can be convinced otherwise or am missing something
fundamentally. Can you provide more examples of package configurations
where you definitely think it beats `with-eval-after-load' or other
alternatives? I'm guessing those would be examples that include
automatically installing a package (lazily?) from ELPA, but you tell me.

:ensure (automatic ELPA installation), :defer (lazy loading) and
:commands (autoloading) are the things I most use in `use-package'
that are not as easy to achieve with `with-eval-after-load'.

[João Távora]

Post by Pedro Silva
:ensure (automatic ELPA installation), :defer (lazy loading) and
:commands (autoloading) are the things I most use in `use-package'
that are not as easy to achieve with `with-eval-after-load'.

Not as easy? Sure, more characters, but basically the same complexity. I
don't think it's worth a whole new language to be able to replace:

(package-install 'foo)

with

:ensure t

and

(autoload 'foo-bar 'foo)
(autoload 'foo-baz 'foo)

with

:commands (foo-bar foo-baz)

or even

(run-with-idle-timer 5 nil 'require 'foo)

with

:defer 5

Especially given that the use-package versions force the reader (or the
grepper) to look around for context, while the regular versions don't.

But perhaps I'm misinterpreting what these directives actually do, or
perhaps you can illustrate with some snippets of your own.

João

[Phillip Lord]

Post by João Távora

Post by Pedro Silva
:ensure (automatic ELPA installation), :defer (lazy loading) and
:commands (autoloading) are the things I most use in `use-package'
that are not as easy to achieve with `with-eval-after-load'.

Not as easy? Sure, more characters, but basically the same complexity. I
(package-install 'foo)
Especially given that the use-package versions force the reader (or the
grepper) to look around for context, while the regular versions don't.

use-package introduces a single (documented) form. So, it's easy to
re-eval everything, and keeps all your code in one place. Trivial as
this sounds, this is actually pretty useful.

In your examples, you need to "progn" everything to achieve the same.

Post by João Távora
But perhaps I'm misinterpreting what these directives actually do, or
perhaps you can illustrate with some snippets of your own.

What use-package does is syntactic sugar for sure, but it also does add
some nice functionality. So, for example, this

(use-package foo
:load-path "~/foo"
:commands foo-a foo-b foo-c
:defer 5
)

actually does this...


(progn
(eval-and-compile
(push "~/foo" load-path))
(run-with-idle-timer 5 nil #'require 'foo nil t)
(unless
(fboundp 'foo-a)
(autoload #'foo-a "foo" nil t))
(unless
(fboundp 'foo-b)
(autoload #'foo-b "foo" nil t))
(unless
(fboundp 'foo-c)
(autoload #'foo-c "foo" nil t)))

while the apparently much simpler:

(use-package foo
:load-path "~/foo"
)

actually does this:

(progn
(eval-and-compile
(push "~/foo" load-path))
(let
((now
(current-time)))
(message "%s..." "Loading package foo")
(prog1
(if
(not
(require 'foo nil 'noerror))
(ignore
(message
(format "Could not load %s" 'foo))))
(let
((elapsed
(float-time
(time-subtract
(current-time)
now))))
(if
(> elapsed 0.1)
(message "%s...done (%.3fs)" "Loading package foo" elapsed)
(message "%s...done" "Loading package foo"))))))

A useful system for working out why your .emacs is so slow to load.

*shrugs*. I really like it, and it's made my .emacs cleaner.

Phil

[João Távora]

Post by Phillip Lord
use-package introduces a single (documented) form. So, it's easy to
re-eval everything, and keeps all your code in one place. Trivial as
this sounds, this is actually pretty useful.
In your examples, you need to "progn" everything to achieve the same.

Or use `eval-region'. Or eval the whole .emacs while you're at it.

Post by Phillip Lord

Post by João Távora
But perhaps I'm misinterpreting what these directives actually do, or
perhaps you can illustrate with some snippets of your own.

(progn
(eval-and-compile
(push "~/foo" load-path))

How pushing foo to the load-path at compile-time needed/useful for this
example?

Post by Phillip Lord
(run-with-idle-timer 5 nil #'require 'foo nil t)
(unless
(fboundp 'foo-a)
(autoload #'foo-a "foo" nil t))

According to the `autoload' docstring:

If FUNCTION is already defined other than as an autoload,
this does nothing and returns nil.

So, unless I'm missing something, your example is misrepresenting the
alternative: when I asked about a fair comparison, I didn't mean a mere
macroexpansion of the `use-package' form.

Post by Phillip Lord
(message "%s...done" "Loading package foo"))))))

By the way, for the pretty logging functionality, why not add something
more atomic like a `timing' macro? It could be used as your `progn'
replacement

(with-timing "Loading bla"
... configure bla ...)

As well as anything else not related to packages

(with-timing "Frankinboging fretzels" ...)

I prefer reusable components to big obscure, hard-to-debug black magic
spells.

As another drawback, if a user messes up a line in use-package (still
totally possible right?) it's much easier to catch that error in a
backtrace, or a byte-compilation log, when *not* using the syntactic
sugar.

The problem could be slightly reduced if use-package came with an edebug
spec. I don't think it does.

If the user is already writing elisp, let him learn it while he's at it.

Post by Phillip Lord
A useful system for working out why your .emacs is so slow to load.
*shrugs*. I really like it, and it's made my .emacs cleaner.

If *you* like it and in your opinion it's cleaner then *you* really
should use it :-)

My argument is that, by adding it to Emacs, especially to the core,
you're effectively supporting another official package configuration
method, thus burdening every package maintainer with a different opinion
with the need to learn a new DSL when reading user's bug
reports. Perhaps every other package maintainer has converted already,
but at least I haven't, not yet.

João

[Oleh Krehel]

Post by João Távora
By the way, for the pretty logging functionality, why not add something
more atomic like a `timing' macro? It could be used as your `progn'
replacement
(with-timing "Loading bla"
... configure bla ...)
As well as anything else not related to packages
(with-timing "Frankinboging fretzels" ...)
I prefer reusable components to big obscure, hard-to-debug black magic
spells.

I very much agree on this point. A large chunk of `use-package'
functionality is this new `with-timing' that could indeed be a reusable
component. That macro could also wrap a `condition-case' around, barfing
"errored while Frankinboging fretzels" on error.

Post by João Távora
My argument is that, by adding it to Emacs, especially to the core,
you're effectively supporting another official package configuration
method, thus burdening every package maintainer with a different opinion
with the need to learn a new DSL when reading user's bug
reports.

I agree on this point as well. One official way of doing things is
better than two (three even, if we include Customize). If `use-package'
is in GELPA, as the author of package "foo" I don't feed obliged to help
a user configure "foo" with `use-package': the user should know what
she's getting into. But if `use-package' were in the core, I'd feel
that obligation, so that's more support tasks for all package authors.

Post by João Távora
Perhaps every other package maintainer has converted already, but at
least I haven't, not yet.

I switched to `use-package' only for the shorter autoload syntax and the
wrapped `condition-case'. If that's all it did, I see no problem with
it. However, it also includes >15 other keywords that have great
potential for misuse by inexperienced users, in my opinion.

The current status of `use-package' is perfect for me: if the user
installs it, she should take responsibility for it and not expect
support for `use-package' from third parties. However, if it becomes
official and encouraged, we might have a problem.

Additionally, `use-package' sort of cuts into the functionality of
package.el, which ideally should be a 0-config built-in utility, with
all useful commands autoloaded.

[João Távora]

Post by João Távora

Post by Phillip Lord
(unless
(fboundp 'foo-a)
(autoload #'foo-a "foo" nil t))

If FUNCTION is already defined other than as an autoload,
this does nothing and returns nil.

IIRC in the above snippet (from the expansion of a use-package
instance), `fboundp' is mostly used as `autoloadp' to avoid overwriting
existing autloads (I guess autloadp wasn't used because it takes an
OBJECT as argument instead of a symbol).

Is this useful or desirable? Doesn't this mean that making a correction
to a `use-package' instantiation and re-evaluating it will silently
produce a noop?

In the same vein, does `use-package' undo autoloads (or keybindings or
any other thing) when the directive's value changes?

João

[John Wiegley]

In the same vein, does `use-package' undo autoloads (or keybindings or any
other thing) when the directive's value changes?

No, it was designed with the intention that it would be executed "once" at
Emacs load time in init.el. It doesn't have features for being changed and
then re-evaluated. Suggested use would be to make the change and restart
Emacs, just to be sure that everything happens as expected.

John

[Nicolas Richard]

Hello,

Post by João Távora

IIRC in the above snippet (from the expansion of a use-package
instance), `fboundp' is mostly used as `autoloadp' to avoid overwriting
existing autloads (I guess autloadp wasn't used because it takes an
OBJECT as argument instead of a symbol).

Is this useful or desirable?

I guess it was useful to some people. This triggered its addition :
https://github.com/jwiegley/use-package/issues/135
(then later : https://github.com/jwiegley/use-package/issues/177)

I think however that this is a detail which is pretty much independent
from the question of adding use-package to core.

Post by João Távora
Doesn't this mean that making a correction
to a `use-package' instantiation and re-evaluating it will silently
produce a noop?

In case of autoloads it seems so. For other configuration keywords, not
necessarily.

Post by João Távora
In the same vein, does `use-package' undo autoloads (or keybindings or
any other thing) when the directive's value changes?

No.

[Phillip Lord]

Post by João Távora

Post by Phillip Lord
use-package introduces a single (documented) form. So, it's easy to
re-eval everything, and keeps all your code in one place. Trivial as
this sounds, this is actually pretty useful.
In your examples, you need to "progn" everything to achieve the same.

Or use `eval-region'. Or eval the whole .emacs while you're at it.

The first is error prone, the second assumes your entire .emacs is
idempotent.

Post by João Távora
So, unless I'm missing something, your example is misrepresenting the
alternative: when I asked about a fair comparison, I didn't mean a mere
macroexpansion of the `use-package' form.

The point is that the two forms have quite different expansions, despite
containing quite overlapping arguments.

Post by João Távora

Post by Phillip Lord
(message "%s...done" "Loading package foo"))))))

By the way, for the pretty logging functionality, why not add something
more atomic like a `timing' macro? It could be used as your `progn'
replacement
(with-timing "Loading bla"
... configure bla ...)
As well as anything else not related to packages
(with-timing "Frankinboging fretzels" ...)
I prefer reusable components to big obscure, hard-to-debug black magic
spells.

That would be nice, yes, and would be a valuable change, as the
with-timing could be turned on and off in a uniform way.

Post by João Távora
As another drawback, if a user messes up a line in use-package (still
totally possible right?) it's much easier to catch that error in a
backtrace, or a byte-compilation log, when *not* using the syntactic
sugar.

Yes. Although, the ability to turn lazy loading (with defer) on and off
is a big help in debugging .emacs files. Still use-package now has some
nice error handling. You can't use invalid keyword any more. I've also
found the clean mechanism for disabling all configuration for a package
at once to be helpful.

Post by João Távora
The problem could be slightly reduced if use-package came with an edebug
spec. I don't think it does.

That would be useful, but only so useful. In practice, edebug is not, in
my experience, enormously useful in debugging .emacs files.

Post by João Távora

Post by Phillip Lord
A useful system for working out why your .emacs is so slow to load.
*shrugs*. I really like it, and it's made my .emacs cleaner.

If *you* like it and in your opinion it's cleaner then *you* really
should use it :-)

I do.

Post by João Távora
My argument is that, by adding it to Emacs, especially to the core,
you're effectively supporting another official package configuration
method, thus burdening every package maintainer with a different opinion
with the need to learn a new DSL when reading user's bug
reports. Perhaps every other package maintainer has converted already,
but at least I haven't, not yet.

Yes, I agree. On the flip-side, you are removing the burden of bootstrap
problem that use-package has. I use it to ensure that all the packages I
use are installed, but I have to install it with a different technique
(I call package directly). I think that the bootstrap burden is a
sensible justification for keeping use-package in core.

Phil

[Artur Malabarba]

Post by John Wiegley
I'd like to integrate use-package.el into Emacs core, as an alternative for
package management to those who do not rely on package.el. I know Stefan had
some reservation, but I think enough people have enjoyed its utility to be
worth including.

Alternative? I was under the impression that use-package was a way of
organising your package configurations in the init file (and ensuring that
they are installed), with installation/upgrading itself still being done
via package.el.
Did I get it wrong?

I too have seen many people praise use-package, and I think it would make a
fine addition.

[John Wiegley]

Post by Artur Malabarba
Alternative? I was under the impression that use-package was a way of
organising your package configurations in the init file (and ensuring that
they are installed), with installation/upgrading itself still being done via
package.el. Did I get it wrong?

I think I said it wrong by using the words "package management":

- package.el is for installing, upgrading, and removing packages, and for
establishing autoloads and customization access to those packages.
use-package does none of these things, although it is able to make use
of package.el.

- use-package is for configuration only. The stuff you'd already write in
init.el, only more declaratively. Nor does it seek to replace M-x customize,
since the two work together rather nicely (this is what I do).

It was my error for making them seem as though they were on the same footing.
They are almost completely orthogonal. The two can live together in perfect
harmony; or, a user who makes no use of package.el can use use-package to
clean up configuration code that doesn't fit the customization interface.

John

[Artur Malabarba]

Post by John Wiegley
- use-package is for configuration only. The stuff you'd already write in
init.el, only more declaratively.

Ok, that's what I thought. Like I said, I'm in favour.

I suggest renaming it to something that starts with `package-'
(package-config perhaps). But it's just a suggestion.

I notice it has two dependencies that are not in core though, which would
have to be shed.

If it gets added, I'll probably have a look at its internals and ask your
permission to make some changes where there might be redundancy with
package.el internals.

[John Wiegley]

Post by Artur Malabarba
I notice it has two dependencies that are not in core though, which would
have to be shed.

bind-key.el would come with it, since it's a companion library. It provides a
convenience wrapper around both `define-key' and `kbd'. I suppose we ought to
discuss that separation if there are questions.

diminish.el is only loaded if available, although the fact that it's not in
core would indeed mean moving that support out of use-package and into an
external add-on. Fortunately, the use-package architecture makes this easy to
do.

I'd rather not rename to package-config, since it's not related to package.el,
and a strong association by name could get confusing.

Post by Artur Malabarba
If it gets added, I'll probably have a look at its internals and ask your
permission to make some changes where there might be redundancy with
package.el internals.

Sure, though I'd be surprised if that were any code they shared.

John

[Artur Malabarba]

Post by John Wiegley

Post by Artur Malabarba
I notice it has two dependencies that are not in core though, which would
have to be shed.

bind-key.el would come with it, since it's a companion library. It provides a
convenience wrapper around both `define-key' and `kbd'. I suppose we ought to
discuss that separation if there are questions.

We can also just incorporate the necessary `bind-key' functionality into
subr.el. In particular, that `bind-key*' function is something I've seen
people ask about before.

Post by John Wiegley
diminish.el is only loaded if available

All good then. I was deceived by that `(diminish "0.44")' in the
Package-Requires. :-)

Post by John Wiegley
I'd rather not rename to package-config, since it's not related to package.el,
and a strong association by name could get confusing.

Good point. 👍

[Kaushal Modi]

I use the use-package and bind-key packages in my config.

The use-package would be nice to have in the core but I think bind-key
should not be put into the core as it is.

The primary reason is that it creates duplication and thus confusion for
new users.

For define-key, we have

(define-key MAP KEY-VECTOR COMMAND)

whereas we have

(bind-key KEY-STRING COMMAND MAP)

Notice the shuffling of arguments and difference between the way the keys
are to be represented in the argument.

I see the benefits of bind-key*, bind-keys and bind-keys*, but I believe
that that should be merged with define-key.

The describe-personal-keybindings is useful. But how will it work as
expected if packages in the core started using bind-key macros. We then
need a robust means to distinguish between the default bindings and the
bindings in user config.

I don't have a proposal for the complete solution, but these are few things
that didn't feel right to me about putting bind-keys in core.

[John Wiegley]

Post by Kaushal Modi
For define-key, we have
(define-key MAP KEY-VECTOR COMMAND)
whereas we have
(bind-key KEY-STRING COMMAND MAP)

Actually, it's:

(bind-key KEY-STRING COMMAND [MAP])

Which is very close to:

(global-set-key KEY-STRING COMMAND)

`define-key' is more familiar to developers, but I don't think it's what most
users use in their init.el when they want to bind keys.

I could see adding an optional map argument to `global-set-key', although one
of the nice things about `bind-key' is that it sets up the necessary data to
allow `describe-personal-keybindings' to work.

And then there is `bind-key*', for truly global bindings that override minor
modes; and `bind-keys', for binding many keys at once, potentially into
multiple keymaps. So there might be a good reason to introduce a new layer
with this module, specifically intended for user customization in init.el
files.

John

[Stephen Leake]

Post by Kaushal Modi
I use the use-package and bind-key packages in my config.
The use-package would be nice to have in the core

Would it be just as nice in ELPA?

[John Wiegley]

Post by Stephen Leake

Post by Kaushal Modi
I use the use-package and bind-key packages in my config.
The use-package would be nice to have in the core

Would it be just as nice in ELPA?

I think now that it would be!

John

[Oleh Krehel]

Post by John Wiegley

Post by Stephen Leake
Would it be just as nice in ELPA?

I think now that it would be!

I use (a narrow subset of) use-package; I like it, and I'm all for
having it in GNU ELPA. That should cover my reservations for added
Elisp complexity: if it's not in the core, my previously listed concerns
are much less severe.

Oleh

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I've never thought about it, but AFAIU all contributors for all external
packages in Gnu Elpa need copyright assignments - right?

All those who make nontrivial contributions of code need to have their
work assigned to the FSF, or else disclaimed.

They can do these by signing individual papers, or they may be
covered by employer's papers.

[Andreas Röhler]

Post by Richard Stallman
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I've never thought about it, but AFAIU all contributors for all external
packages in Gnu Elpa need copyright assignments - right?

All those who make nontrivial contributions of code need to have their
work assigned to the FSF, or else disclaimed.

Is "else disclaimed" to be understood as signing the disclaimer handed
out by FSF?
Saying: I'm the author and coyright-owner etc.?

That would be great.

Post by Richard Stallman
They can do these by signing individual papers, or they may be
covered by employer's papers.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Post by Andreas Röhler

Post by Richard Stallman
All those who make nontrivial contributions of code need to have their
work assigned to the FSF, or else disclaimed.

Is "else disclaimed" to be understood as signing the disclaimer handed
out by FSF?
Saying: I'm the author and coyright-owner etc.?

The contributor can sign either a copyright assignment (which transfers
the copyright to the FSF) or a copyright disclaimer (which says only
"I don't claim any copyright").

This is explained in what we give to contributors to show them
the options for contributing.

[Ted Zlatanov]

On Mon, 09 Nov 2015 16:02:33 -0800 John Wiegley <***@gmail.com> wrote:

JW> I'd like to integrate use-package.el into Emacs core, as an alternative for
JW> package management to those who do not rely on package.el. I know Stefan had
JW> some reservation, but I think enough people have enjoyed its utility to be
JW> worth including.

JW> Are there any objections to moving this into core before the 25.1 freeze?

I think it's good. The prefix makes it clear it's not an interface to
the `package-*' functions.

Ted

[j***@verona.se]

Post by John Wiegley
I'd like to integrate use-package.el into Emacs core, as an alternative for
package management to those who do not rely on package.el. I know Stefan had
some reservation, but I think enough people have enjoyed its utility to be
worth including.
Are there any objections to moving this into core before the 25.1 freeze?
John

I use req-package, https://github.com/edvorg/req-package, which is
use-package with some additional features, like logging and load order
reordering. I think use-package would be a great addition to emacs core,
for people like me that like a clear and readable emacs
configuration. (I alse use the org-babel litterate mode for the emacs
init file for the same reasons.)

[Stephen Leake]

Post by j***@verona.se
I use req-package, https://github.com/edvorg/req-package, which is
use-package with some additional features, like logging and load order
reordering. I think use-package would be a great addition to emacs core,
for people like me that like a clear and readable emacs
configuration.

It's currently in Gnu ELPA; is that sufficient?

[Dmitry Gutov]

Post by Stephen Leake

Post by j***@verona.se
I use req-package, https://github.com/edvorg/req-package, which is
use-package with some additional features, like logging and load order
reordering. I think use-package would be a great addition to emacs core,
for people like me that like a clear and readable emacs
configuration.

It's currently in Gnu ELPA

What makes you think so?

[Stephen Leake]

Post by Dmitry Gutov

Post by Stephen Leake

Post by j***@verona.se
I use req-package, https://github.com/edvorg/req-package, which is
use-package with some additional features, like logging and load order
reordering. I think use-package would be a great addition to emacs core,
for people like me that like a clear and readable emacs
configuration.

It's currently in Gnu ELPA

What makes you think so?

Sorry, I misread the output of list-packages; it's currently in MELPA.

Which raises the question; what is the rationale for moving from MELPA
to Gnu ELPA?

[Xue Fuqiao]

On Wed, Nov 11, 2015 at 5:30 PM, Stephen Leake

what is the rationale for moving from MELPA to Gnu ELPA?

Some advantage of GNU ELPA (in comparison with MELPA):

* The GNU ELPA archive is the only archive that's configured by default,
so we can tell people to M-x package-install without worrying about
whether or not they've added MELPA to their config.

* The code uses the same copyright rules as Emacs code, so that we can
easily move code between the two. IOW it'd be ready for inclusion in
Emacs proper. (I'm aware of the controversy, but what if we want to
move it to the core in the future?)

* All Emacs developers have write access to the code, so it can benefit
from random cleanups or adjustments to new features.

[Artur Malabarba]

Post by Stephen Leake
Sorry, I misread the output of list-packages; it's currently in MELPA.
Which raises the question; what is the rationale for moving from MELPA
to Gnu ELPA?

Being the default package archive, adding a package to Gelpa increases
its visibility to users who don't have Melpa configured (either for
not knowing it or not wanting it).
And if the author/maintainer doesn't mind managing a package on Gelpa,
then there's no downside either.

[Andreas Röhler]

Post by John Wiegley
I'd like to integrate use-package.el into Emacs core, as an alternative for
package management to those who do not rely on package.el. I know Stefan had
some reservation, but I think enough people have enjoyed its utility to be
worth including.
Are there any objections to moving this into core before the 25.1 freeze?
John

Hi John,

as you know being your fan.
Nothing wrong with use-package AFAIU, but: please be careful, resist
temptation :)

For several reasons being a maintainer implies some tragic, kind of
offering if well-done,

all the best,

Andreas

[Nicolas Petton]

Post by John Wiegley
I'd like to integrate use-package.el into Emacs core, as an alternative for
package management to those who do not rely on package.el. I know Stefan had
some reservation, but I think enough people have enjoyed its utility to be
worth including.
Are there any objections to moving this into core before the 25.1 freeze?

That's fine with me. use-package.el is already used by many people.

Nico

[Stephen Leake]

Post by Nicolas Petton

Post by John Wiegley
I'd like to integrate use-package.el into Emacs core, as an alternative for
package management to those who do not rely on package.el. I know Stefan had
some reservation, but I think enough people have enjoyed its utility to be
worth including.
Are there any objections to moving this into core before the 25.1 freeze?

That's fine with me. use-package.el is already used by many people.

Which is an argument for it being in Gnu ELPA; would that be enough?

I'm bugging people about this to help clarify the ELPA vs core policy.

[John Wiegley]

Post by Stephen Leake

Post by Nicolas Petton
That's fine with me. use-package.el is already used by many people.

Which is an argument for it being in Gnu ELPA; would that be enough?

I think so.

Post by Stephen Leake
I'm bugging people about this to help clarify the ELPA vs core policy.

Thank you, it is helping. I can feel the mists converging toward a less
inchoate adumbration. :)

John

[Stephen Leake]

Post by John Wiegley
I'd like to integrate use-package.el into Emacs core, as an alternative for
package management to those who do not rely on package.el. I know Stefan had
some reservation, but I think enough people have enjoyed its utility to be
worth including.
Are there any objections to moving this into core before the 25.1 freeze?

What is the rationale for moving this to core instead of Gnu ELPA?

To me, this looks like a good ELPA package; no other core code will rely
on it, only some users want it.

[John Wiegley]

Post by Stephen Leake
What is the rationale for moving this to core instead of Gnu ELPA?

Well, it will be maintained by a core developer. :) It would also be in the
Emacs manual, and blessed as an official method for declaring complex package
configuration.

Further, I wouldn't want it changing on users as ELPA updates. Once a user
downloads Emacs X.Y and reads the manual on how to write such configurations,
the information should remain true until Emacs X.Z.

John

[Dmitry Gutov]

Post by John Wiegley
Well, it will be maintained by a core developer. :)

Quite a few packages in ELPA come from Emacs committers. Stefan has
several (e.g. sml-mode). I maintain three (2 of which are comparable in
popularity to use-package, judging by the number of stars on GitHub).

Post by John Wiegley
It would also be in the
Emacs manual, and blessed as an official method for declaring complex package
configuration.

Packages can also include manuals (I don't know the details, but e.g.
Flycheck does). Of course, you can't declare use-package to be "blessed"
that way.

Post by John Wiegley
Further, I wouldn't want it changing on users as ELPA updates. Once a user
downloads Emacs X.Y and reads the manual on how to write such configurations,
the information should remain true until Emacs X.Z.

Do you expect use-package to depend on new features in every Emacs
version? Otherwise, you can have pretty much the same by only releasing
a new version of use-package once a year. :)

[Kaushal Modi]

Packages can also include manuals (I don't know the details, but e.g. Flycheck does). Of course, you can't declare use-package to be "blessed" that way.

Also non-Elpa packages come with detailed manuals: magit

Do you expect use-package to depend on new features in every Emacs version? Otherwise, you can have pretty much the same by only releasing a new version of use-package once a year. :)

+1

The development for use-package can continue as it is happening now
and versions can be git-tagged as something like "stable". When the
time for next emacs release comes, the GNU Elpa version can be synced
with the latest "stable" tagged version from the development git.

[John Wiegley]

The development for use-package can continue as it is happening now and
versions can be git-tagged as something like "stable". When the time for
next emacs release comes, the GNU Elpa version can be synced with the latest
"stable" tagged version from the development git.

Hmmm... you guys are both encouraging me to consider putting it in ELPA
instead. It really kind of is an "optional package if you want to do things
this way..."

I so want that ELPA policy document now. :) We're spending too much time
having this same debate about a fine line, like a hair in the dark.

I think for 25.1, at least, everything I've suggested recently should go into
ELPA. Then we'll let the policy document decide whether they belong in core
for 25.2.

John

[Stephen Leake]

Post by John Wiegley

Post by Stephen Leake
What is the rationale for moving this to core instead of Gnu ELPA?

(My search of list-packages did not find `use-package' the first time,
so I did not realize it is already in Gnu ELPA).

Post by John Wiegley
Well, it will be maintained by a core developer. :)

Not a good reason; I maintain ada-mode in ELPA, because I want an
independent release cycle. But I still consider myself a minor Emacs
core developer.

Post by John Wiegley
It would also be in the Emacs manual,

It can provide a .info file, which will be in the user's top level info
list. Is that not sufficient?

Hmm. It might be that other sections of the Emacs manual want to
reference use-package. They can do so, as long as they clearly label it
as an ELPA package, so users will know how to find it. For example:

If you use the (really cool) ELPA package @elparef{use-package},
then you can do ...

I'm not clear exactly what "@elparef" should do, but it seems like a
good idea. Perhaps it should add the "ELPA package" text, so it is done
consistently. Can it add a clickable link to the package.el description
of the package?

Post by John Wiegley
and blessed as an official method for declaring complex package
configuration.

Ah. So you are asking us to agree that _this_ package is better than
other similar packages.

That's a reasonable request in general. But given the controversy around
CEDET, I think it needs to wait for emacs 25+, so we can establish a
process for such requests.

Post by John Wiegley
Further, I wouldn't want it changing on users as ELPA updates.
Once a user downloads Emacs X.Y and reads the manual on how to write
such configurations, the information should remain true until Emacs
X.Z.

As the package maintainer, that's under your control; if you don't want
it to change, don't change it.

You are completely free to determine the release schedule for your ELPA
package. If you want it synced with Emacs releases, do that. There is a
small race condition window at the actual release, but I don't think
that's a significant problem. Proper use of Emacs version in the
dependency header should handle that.

If you want to work on it between releases, use a branch in ELPA git, or
a separate repository.


On the other hand, that means you can't release bug fixes, either. Nor
really cool but backward-compatible enhancements. I'd rather have a
package in ELPA, so I don't have to wait for the next Emacs release.