[Top][All Lists]

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

Re: use-package.el -> Emacs core

From: João Távora
Subject: Re: use-package.el -> Emacs core
Date: Tue, 10 Nov 2015 13:37:58 +0000
User-agent: Gnus/5, (Gnus v5.13) Emacs/25.0.50 (windows-nt)

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

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

   (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

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

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.


reply via email to

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