use-package.el -> Emacs core

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

Re: use-package.el -> Emacs core

[Dmitry Gutov]

On 11/10/2015 02:02 AM, John Wiegley wrote:

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

Re: use-package.el -> Emacs core

[John Wiegley]

>>>>> Dmitry Gutov <dgutov@yandex.ru> writes:

> 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
    

Re: use-package.el -> Emacs core

[Dmitry Gutov]

On 11/10/2015 02:31 AM, John Wiegley wrote:

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

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

Re: use-package.el -> Emacs core

[Oleh Krehel]

John Wiegley <jwiegley@gmail.com> writes:

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

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.

Re: use-package.el -> Emacs core

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 671 bytes --]

On Tue, Nov 10, 2015 at 8:55 AM, Oleh Krehel <ohwoeowho@gmail.com> wrote:

> 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

[-- Attachment #2: Type: text/html, Size: 860 bytes --]

Re: use-package.el -> Emacs core

[Oleh Krehel]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Tue, Nov 10, 2015 at 8:55 AM, Oleh Krehel <ohwoeowho@gmail.com> wrote:
>
>> 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.

Re: use-package.el -> Emacs core

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 999 bytes --]

On Tue, Nov 10, 2015 at 1:10 PM, Oleh Krehel <ohwoeowho@gmail.com> wrote:

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

[-- Attachment #2: Type: text/html, Size: 3050 bytes --]

Re: use-package.el -> Emacs core

[Oleh Krehel]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Tue, Nov 10, 2015 at 1:10 PM, Oleh Krehel <ohwoeowho@gmail.com> wrote:
>
>> 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.

Re: use-package.el -> Emacs core

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 457 bytes --]

On Tue, Nov 10, 2015 at 1:40 PM, Oleh Krehel <ohwoeowho@gmail.com> wrote:

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

[-- Attachment #2: Type: text/html, Size: 631 bytes --]

Re: use-package.el -> Emacs core

[John Wiegley]

>>>>> Juanma Barranquero <lekktu@gmail.com> writes:

> On Tue, Nov 10, 2015 at 1:40 PM, Oleh Krehel <ohwoeowho@gmail.com> wrote:
>> 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 (?)

Re: use-package.el -> Emacs core

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 227 bytes --]

On Tue, Nov 10, 2015 at 4:15 PM, John Wiegley <jwiegley@gmail.com> wrote:

> For (7):
>
> - Nicolas Petton
> - Joakim Verona
> - Phillip Lord
> - Dimtry Gutov
> - Artur Malabarb
> - Kaushal Modi
> - Ted Zlatanov

I'm for

   J

[-- Attachment #2: Type: text/html, Size: 410 bytes --]

Re: use-package.el -> Emacs core

[Dmitry Gutov]

On 11/10/2015 05:42 PM, Juanma Barranquero wrote:

>  > For (7):
>  >
>  > - 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.

Re: use-package.el -> Emacs core

[Stephen Leake]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Tue, Nov 10, 2015 at 4:15 PM, John Wiegley <jwiegley@gmail.com> wrote:
>
>> For (7):
>>
>> - 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.

-- 
-- Stephe

Re: use-package.el -> Emacs core

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 146 bytes --]

On Wed, Nov 11, 2015 at 1:37 AM, Stephen Leake <
stephen_leake@stephe-leake.org> wrote:
> Would you support putting it in Gnu ELPA instead?

Yes.

[-- Attachment #2: Type: text/html, Size: 352 bytes --]

Re: use-package.el -> Emacs core

[João Távora]

On Tue, Nov 10, 2015 at 3:15 PM, John Wiegley <jwiegley@gmail.com> wrote:

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

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

-- 
João Távora

Re: use-package.el -> Emacs core

[John Wiegley]

>>>>> João Távora <joaotavora@gmail.com> writes:

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

> 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

RE: use-package.el -> Emacs core

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

Re: use-package.el -> Emacs core

[David Kastrup]

Oleh Krehel <ohwoeowho@gmail.com> writes:

> Juanma Barranquero <lekktu@gmail.com> writes:
>
>> On Tue, Nov 10, 2015 at 1:10 PM, Oleh Krehel <ohwoeowho@gmail.com> wrote:
>>
>>> 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.

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

-- 
David Kastrup

Re: use-package.el -> Emacs core

[Oleh Krehel]

David Kastrup <dak@gnu.org> writes:

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

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

Re: use-package.el -> Emacs core

[João Távora]

David Kastrup <dak@gnu.org> writes:

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

Re: use-package.el -> Emacs core

[John Wiegley]

>>>>> João Távora <joaotavora@gmail.com> writes:

> 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

Re: use-package.el -> Emacs core

[João Távora]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> João Távora <joaotavora@gmail.com> writes:
>
>> 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))

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.

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

Re: use-package.el -> Emacs core

[John Wiegley]

>>>>> João Távora <joaotavora@gmail.com> writes:

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

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

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

> 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

Re: use-package.el -> Emacs core

[João Távora]

John Wiegley <jwiegley@gmail.com> writes:
>>> (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?

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

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

> 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

Re: use-package.el -> Emacs core

[John Wiegley]

>>>>> João Távora <joaotavora@gmail.com> writes:

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

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

> 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

Re: use-package.el -> Emacs core

[João Távora]

John Wiegley <jwiegley@gmail.com> writes:

>>    (package-install 'markdown-mode)
>>    (with-eval-after-load 'markdown-mode
>>      (modify-syntax-entry ?` "\"" markdown-mode-syntax-table))
>
> To match those semantics, you'd use:
>
>     (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.

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

Re: use-package.el -> Emacs core

[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

Re: use-package.el -> Emacs core

[John Wiegley]

>>>>> Kaushal Modi <kaushal.modi@gmail.com> writes:

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

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

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

> 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

RE: use-package.el -> Emacs core

[Drew Adams]

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

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

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

Re: use-package.el -> Emacs core

[John Wiegley]

>>>>> Drew Adams <drew.adams@oracle.com> writes:

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

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

> 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

Re: use-package.el -> Emacs core

[Kaushal Modi]

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

Re: use-package.el -> Emacs core

[John Wiegley]

>>>>> Kaushal Modi <kaushal.modi@gmail.com> writes:

> 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

RE: use-package.el -> Emacs core

[Drew Adams]

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

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

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

Re: use-package.el -> Emacs core

[John Wiegley]

>>>>> Drew Adams <drew.adams@oracle.com> writes:

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

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

RE: use-package.el -> Emacs core

[Drew Adams]

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

Re: use-package.el -> Emacs core

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 454 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 554 bytes --]

Re: use-package.el -> Emacs core

[David Kastrup]

Oleh Krehel <ohwoeowho@gmail.com> writes:

> Juanma Barranquero <lekktu@gmail.com> writes:
>
>> On Tue, Nov 10, 2015 at 8:55 AM, Oleh Krehel <ohwoeowho@gmail.com> wrote:
>>
>>> 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.

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

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

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

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

-- 
David Kastrup

Re: use-package.el -> Emacs core

[Oleh Krehel]

David Kastrup <dak@gnu.org> writes:

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

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

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

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

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

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

Re: use-package.el -> Emacs core

[Evgeny Panasyuk]

10.11.2015 16:06, 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.

Re: use-package.el -> Emacs core

[Alan Mackenzie]

[ Mail-Followup-To: set ]

On Tue, Nov 10, 2015 at 09:15:51PM +0300, Evgeny Panasyuk wrote:
> 10.11.2015 16:06, 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-tangents@gnu.org.

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

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: use-package.el -> Emacs core

[Wolfgang Jenkner]

On Tue, Nov 10 2015, David Kastrup wrote:

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

Customize is only for newbies? [was: use-package.el -> Emacs core]

[Drew Adams]

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

Re: Customize is only for newbies? [was: use-package.el -> Emacs core]

[Wolfgang Jenkner]

On Tue, Nov 10 2015, Drew Adams wrote:

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

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

Customize is only for newbies? [was: use-package.el -> Emacs core]

[Drew Adams]

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

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

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

Re: Customize is only for newbies? [was: use-package.el -> Emacs core]

[John Wiegley]

>>>>> Drew Adams <drew.adams@oracle.com> writes:

> 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

Re: use-package.el -> Emacs core

[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

Re: use-package.el -> Emacs core

[Pedro Silva]

joaotavora@gmail.com (João Távora) writes:

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

-- 
Pedro

Re: use-package.el -> Emacs core

[João Távora]

Pedro Silva <psilva@pedrosilva.pt> writes:

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

Re: use-package.el -> Emacs core

[Phillip Lord]

João Távora <joaotavora@gmail.com> writes:

> Pedro Silva <psilva@pedrosilva.pt> writes:
>
>> :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)

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


> 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

Re: use-package.el -> Emacs core

[João Távora]

phillip.lord@russet.org.uk (Phillip Lord) writes:

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

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

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

> 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

Re: use-package.el -> Emacs core

[Oleh Krehel]

joaotavora@gmail.com (João Távora) writes:

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

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

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

Re: use-package.el -> Emacs core

[Nicolas Richard]

joaotavora@gmail.com (João Távora) writes:

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


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

-- 
Nico.

Re: use-package.el -> Emacs core

[João Távora]

Nicolas Richard <youngfrog@members.fsf.org> writes:

> joaotavora@gmail.com (João Távora) writes:
>
>>>   (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.
>
>
> 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

Re: use-package.el -> Emacs core

[John Wiegley]

>>>>> João Távora <joaotavora@gmail.com> writes:

> 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

Re: use-package.el -> Emacs core

[Nicolas Richard]

Hello,

joaotavora@gmail.com (João Távora) writes:
> Nicolas Richard <youngfrog@members.fsf.org> writes:
>> 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.

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

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

No.

-- 
Nico.

Re: use-package.el -> Emacs core

[Phillip Lord]

João Távora <joaotavora@gmail.com> writes:

> phillip.lord@russet.org.uk (Phillip Lord) writes:
>
>> 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.


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


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

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


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


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


> 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

Re: use-package.el -> Emacs core

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 670 bytes --]

On 10 Nov 2015 12:02 am, "John Wiegley" <jwiegley@gmail.com> wrote:
>
> 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.

[-- Attachment #2: Type: text/html, Size: 820 bytes --]

Re: use-package.el -> Emacs core

[John Wiegley]

>>>>> Artur Malabarba <bruce.connor.am@gmail.com> writes:

> 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

Re: use-package.el -> Emacs core

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 613 bytes --]

On 10 Nov 2015 1:05 am, "John Wiegley" <jwiegley@gmail.com> wrote:
> - 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.

[-- Attachment #2: Type: text/html, Size: 798 bytes --]

Re: use-package.el -> Emacs core

[John Wiegley]

>>>>> Artur Malabarba <bruce.connor.am@gmail.com> writes:

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

> 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

Re: use-package.el -> Emacs core

[Artur Malabarba]

John Wiegley <jwiegley@gmail.com> writes:

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

> diminish.el is only loaded if available

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

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

Re: use-package.el -> Emacs core

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 981 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1175 bytes --]

Re: use-package.el -> Emacs core

[John Wiegley]

>>>>> Kaushal Modi <kaushal.modi@gmail.com> writes:

> 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

Re: use-package.el -> Emacs core

[Stephen Leake]

Kaushal Modi <kaushal.modi@gmail.com> writes:

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


-- 
-- Stephe

Re: use-package.el -> Emacs core

[John Wiegley]

>>>>> Stephen Leake <stephen_leake@stephe-leake.org> writes:

> Kaushal Modi <kaushal.modi@gmail.com> writes:
>> 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

Re: use-package.el -> Emacs core

[Oleh Krehel]

John Wiegley <jwiegley@gmail.com> writes:

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

Re: use-package.el -> Emacs core

[John Wiegley]

>>>>> Oleh Krehel <ohwoeowho@gmail.com> writes:

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

Thanks, Oleh, I do think it belongs in ELPA, so long as it's on the user's
load-path by default after they install Emacs. Since we're converging toward a
notion of "tarball ELPA" in other threads, this should satisfy both our
concerns.

John

Re: use-package.el -> Emacs core

[Kaushal Modi]

Do all the contributors here:
https://github.com/jwiegley/use-package/graphs/contributors

need to have signed the FSF copyright assignment?

Re: use-package.el -> Emacs core

[John Wiegley]

>>>>> Kaushal Modi <kaushal.modi@gmail.com> writes:

> Do all the contributors here:
> https://github.com/jwiegley/use-package/graphs/contributors
> need to have signed the FSF copyright assignment?

Good call, Kaushal. They in fact do. I'll have to process that before
use-package.el can be considered for ELPA.

The same goes for the various backends people have contributed to alert.el. No
one has changed the core infrastructure but myself, I believe, but many of the
backends were written by other people.

pl.el has no contributors but myself.

Thanks for bringing this up, I don't fully have my GNU maintainer hat on tight
yet, clearly!

John

Copyright assignments in Gnu Elpa (was: use-package.el -> Emacs core)

[Michael Heerdegen]

Kaushal Modi <kaushal.modi@gmail.com> writes:

> Do all the contributors here:
> https://github.com/jwiegley/use-package/graphs/contributors
>
> need to have signed the FSF copyright assignment?

This is a good question.

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

Are we sure that this is currently the case at all with all those
packages developed on Github (pull requests!) ?

And should there not be something said about that in elpa/README?


Michael.

Re: Copyright assignments in Gnu Elpa

[John Wiegley]

>>>>> Michael Heerdegen <michael_heerdegen@web.de> writes:

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

I put out a call for papers today for use-package and alert, and so far the
results have been quite positive. At least six people are mailing in signed
assignments. Many others already had an assignment. No one has said they'd
rather have their change pulled.

John

Re: Copyright assignments in Gnu Elpa

[Artur Malabarba]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> This is a good question.
>
> I've never thought about it, but AFAIU all contributors for all external
> packages in Gnu Elpa need copyright assignments - right?

Non-trivial contributors, yes.

> Are we sure that this is currently the case at all with all those
> packages developed on Github (pull requests!) ?

Currently, for code to get into Gelpa it needs to be manually commited
by someone with push access. Gelpa (and Emacs) thus work on the
assumption that those with push access will only push code that they
have authored, or code that they were told was authored by someone with
an assignment on file.

> And should there not be something said about that in elpa/README?

Yes.

Re: Copyright assignments in Gnu Elpa (was: use-package.el -> Emacs core)

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

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Copyright assignments in Gnu Elpa

[Andreas Röhler]

  On 12.11.2015 23:31, Richard Stallman wrote:
> [[[ 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.




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

Re: Copyright assignments in Gnu Elpa

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

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

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: use-package.el -> Emacs core

[Ted Zlatanov]

On Mon, 09 Nov 2015 16:02:33 -0800 John Wiegley <jwiegley@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

Re: use-package.el -> Emacs core

[joakim]

John Wiegley <jwiegley@gmail.com> writes:

> 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.)
-- 
Joakim Verona

Re: use-package.el -> Emacs core

[Stephen Leake]

joakim@verona.se writes:

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

-- 
-- Stephe

Re: use-package.el -> Emacs core

[Dmitry Gutov]

On 11/11/2015 02:29 AM, Stephen Leake wrote:

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

Re: use-package.el -> Emacs core

[Stephen Leake]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 11/11/2015 02:29 AM, Stephen Leake wrote:
>
>>> 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?

-- 
-- Stephe

Re: use-package.el -> Emacs core

[Xue Fuqiao]

On Wed, Nov 11, 2015 at 5:30 PM, Stephen Leake
<stephen_leake@stephe-leake.org> wrote:

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

Re: use-package.el -> Emacs core

[Artur Malabarba]

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

Re: use-package.el -> Emacs core

[Andreas Röhler]

  On 10.11.2015 01:02, John Wiegley wrote:
> 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

Re: use-package.el -> Emacs core

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 451 bytes --]

John Wiegley <jwiegley@gmail.com> writes:

> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: use-package.el -> Emacs core

[Stephen Leake]

Nicolas Petton <nicolas@petton.fr> writes:

> John Wiegley <jwiegley@gmail.com> writes:
>
>> 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.

-- 
-- Stephe

Re: use-package.el -> Emacs core

[John Wiegley]

>>>>> Stephen Leake <stephen_leake@stephe-leake.org> writes:

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

> 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

Re: use-package.el -> Emacs core

[Stephen Leake]

John Wiegley <jwiegley@gmail.com> writes:

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

-- 
-- Stephe

Re: use-package.el -> Emacs core

[John Wiegley]

>>>>> Stephen Leake <stephen_leake@stephe-leake.org> writes:

> 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

Re: use-package.el -> Emacs core

[Dmitry Gutov]

On 11/10/2015 08:34 PM, John Wiegley wrote:

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

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

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

Re: use-package.el -> Emacs core

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

Re: use-package.el -> Emacs core

[John Wiegley]

>>>>> Kaushal Modi <kaushal.modi@gmail.com> writes:

> 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

Re: use-package.el -> Emacs core

[Stephen Leake]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>
>> 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).

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

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

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

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

-- 
-- Stephe