[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: use-package.el -> Emacs core

From: Oleh Krehel
Subject: Re: use-package.el -> Emacs core
Date: Tue, 10 Nov 2015 15:07:49 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

address@hidden (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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]