Re: use-package.el -> Emacs core

[joaotavora@gmail.com (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