From: John Wiegley <johnw@gnu.org>
To: Stefan Kangas <stefankangas@gmail.com>
Cc: caiohcs0@gmail.com, Naoya Yamashita <conao3@gmail.com>,
monnier@iro.umontreal.ca, emacs-devel@gnu.org
Subject: Re: Include leaf in Emacs distribution
Date: Fri, 23 Oct 2020 13:04:22 -0700 [thread overview]
Message-ID: <m24kmkaeux.fsf@newartisans.com> (raw)
In-Reply-To: <CADwFkm=mSZHeKf0=G7rXhOKOqSxOYWwOQfUv8=7fZWEaDOCTKg@mail.gmail.com> (Stefan Kangas's message of "Fri, 23 Oct 2020 18:41:21 +0000")
>>>>> Stefan Kangas <stefankangas@gmail.com> writes:
> The leaf package, here proposed for inclusion, is superficially very similar
> to use-package. I have therefore asked some questions regarding the
> difference between `use-package' and `leaf':
>> Do you see any other major benefits of leaf over use-package? Or the other
>> way around?
>>
>> Could you explain why I would want to use one or the other (as a user)?
>>
>> Could you explain why Emacs would want to include one or the other (as
>> developers)?
> As far as I can tell, the above hasn't been clarified. Or perhaps I've
> missed it.
> Could you provide an answer to the above, even if only briefly?
I will try to answer from the other side. Reading the leaf documentation, the
two packages appear so superficially similar that it's hard to see the
differences between them at first glance:
- Both are declarative macros that turn user specified configuration into
appropriate and efficient Lisp code for configuring packages. The choice of
keywords is nearly identical in both naming and purpose.
- I've heard the complaint that use-package is "larger and more complex". To
which I would say that *any* package becomes more complex once it's been
around for several years and has fielded the issues brought up by a large
user base. It's a nearly universal truism that greenfield rewrites will be
smaller and cleaner.
- Here are the code counts for the two projects, although I have a hard time
seeing this as an important distinction:
use-package, without tests:
Language Files Lines Blanks Comments Code Complexity
----------- --------- ------- ------- ---------- ------ ----------
Emacs Lisp 12 3008 432 539 2037 80
leaf, without tests:
Language Files Lines Blanks Comments Code Complexity
----------- --------- ------- ------- ---------- ------ ----------
Emacs Lisp 1 1170 144 116 910 23
I'm not sure if the amount of reduction in such a small project justifies a
near-but-not-quite rewrite.
- use-package's approach to keyword handling, since the 2.0 rewrite, is 100%
modular. This means anyone can add, drop or replace the meaning of a keyword
without needing to change the implementation of use-package. Supporting this
configurability is the main reason for its additional code size and
complexity. It was done in this manner to allow 3rd party developers to
extend the ecosystem with their own addon packages, rather than relying on a
`defcustom' that could conflict with the user's own customizations.
Thus, any new keywords provided by leaf (like :emacs) could easily be added
to use-package with a use-package-leaf extension module, in the same way
that we have modules for chords, delight, diminish, ensure, etc.
If I exclude these extension modules, btw, lines of code is reduced by 300.
- use-package is used by Spacemacs, and several of its features -- such as
developer hooks for finer control over loading and initialization -- exist
only for that set of users.
What I care about more than the implementation is the interface. If leaf truly
offers a better internal design, it should become the basis for use-package
3.0, rather than competing as a replacement.
Alternatively, given how moduler use-package already is, a use-package-leaf
addon could be written to introduce the desired changes in behavior that
prompted a leaf rewrite. The "smallness and simplicity" of the two
implementations shouldn't matter to users -- just that we get their
configurations right.
After all, we're talking about something that is <2k lines of code, and has no
functionlity of its own; it merely expands a config block into other code! As
long as users are able to rely on a consistent pattern for declaring their
Emacs config, any further details should be the concern of emacs-devel alone.
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
next prev parent reply other threads:[~2020-10-23 20:04 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-08 1:37 Include leaf in Emacs distribution Naoya Yamashita
2020-10-08 9:00 ` Ergus
2020-10-08 9:22 ` Naoya Yamashita
2020-10-10 10:11 ` Eli Zaretskii
2020-10-11 5:24 ` Richard Stallman
2020-10-11 8:39 ` Naoya Yamashita
2020-10-11 9:52 ` Thibaut Verron
2020-10-11 16:50 ` Naoya Yamashita
2020-10-11 17:12 ` Thibaut Verron
2020-10-12 2:10 ` Naoya Yamashita
2020-10-12 20:23 ` Ergus via Emacs development discussions.
2020-10-11 17:02 ` Stefan Kangas
2020-10-11 16:51 ` Stefan Kangas
2020-10-12 20:53 ` Mingde (Matthew) Zeng
2020-10-11 17:22 ` Stefan Kangas
2020-10-12 1:35 ` Naoya Yamashita
2020-10-12 22:13 ` Stefan Kangas
2020-10-12 22:19 ` Qiantan Hong
2020-10-12 22:39 ` Caio Henrique
2020-10-13 13:23 ` Stefan Monnier
2020-10-13 14:14 ` Thibaut Verron
2020-10-13 14:29 ` Stefan Monnier
2020-10-13 15:29 ` Thibaut Verron
2020-10-18 9:32 ` Phil Sainty
2020-10-13 15:25 ` Caio Henrique
2020-10-23 2:37 ` Naoya Yamashita
2020-10-23 3:41 ` John Wiegley
2020-10-23 14:33 ` Stefan Monnier
2020-10-23 15:53 ` Naoya Yamashita
2020-10-23 16:46 ` Warnings in init files (was: Include leaf in Emacs distribution) Stefan Monnier
2020-10-23 18:11 ` Include leaf in Emacs distribution T.V Raman
2020-10-23 18:41 ` Stefan Kangas
2020-10-23 20:04 ` John Wiegley [this message]
2020-11-16 5:29 ` Naoya Yamashita
2020-11-17 0:39 ` John Wiegley
2020-11-20 11:04 ` Naoya Yamashita
2020-11-20 11:29 ` Pankaj Jangid
2020-11-20 15:44 ` T.V Raman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m24kmkaeux.fsf@newartisans.com \
--to=johnw@gnu.org \
--cc=caiohcs0@gmail.com \
--cc=conao3@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=stefankangas@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.