[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
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, (continued)
- Customize is only for newbies? [was: use-package.el -> Emacs core], Drew Adams, 2015/11/10
- Re: Customize is only for newbies? [was: use-package.el -> Emacs core], John Wiegley, 2015/11/10
- Re: use-package.el -> Emacs core, João Távora, 2015/11/10
- Re: use-package.el -> Emacs core, Pedro Silva, 2015/11/10
- Re: use-package.el -> Emacs core, João Távora, 2015/11/10
- Re: use-package.el -> Emacs core, Phillip Lord, 2015/11/10
- Re: use-package.el -> Emacs core,
João Távora <=
- Re: use-package.el -> Emacs core, Oleh Krehel, 2015/11/10
- Re: use-package.el -> Emacs core, Nicolas Richard, 2015/11/10
- Re: use-package.el -> Emacs core, João Távora, 2015/11/10
- Re: use-package.el -> Emacs core, John Wiegley, 2015/11/10
- Re: use-package.el -> Emacs core, Nicolas Richard, 2015/11/12
- Re: use-package.el -> Emacs core, Phillip Lord, 2015/11/10
Re: use-package.el -> Emacs core, Artur Malabarba, 2015/11/09