emacs-devel
[Top][All Lists]
Advanced

[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 15:46:45 +0000
User-agent: Gnus/5, (Gnus v5.13) Emacs/25.0.50 (windows-nt)

John Wiegley <address@hidden> writes:

>>>>>> João Távora <address@hidden> 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












reply via email to

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