Re: Include leaf in Emacs distribution

[John Wiegley]

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