Include leaf in Emacs distribution

Include leaf in Emacs distribution

[Naoya Yamashita]

Hello, all.

I'm author of leaf[1][2] which is one of ELPA package.  I propose
to add the package in the default Emacs dictribution.

leaf is included in ELPA from this message[3] but the 13 emails
with Stefan starting with this one did not appear to have been
sent to this ML and were not archived.  If anyone is interested,
I'll put them in public.  (It is needed from Stefan's agreement maybe.)

Now, leaf wraps the idiom for configuring Emacs packages.  If
you're using use-package[4], it's not hard to imagine.  The offering
is pretty much the same but bit different.

Why did I create leaf?  Because the syntax of the use-package was
a bit confusing and there were copyright issues[5].

If we have leaf as default Emacs package, users don't need the
leafs own bootstrap, and even the package.el configuration can
be written in leaf.  Now users need package.el to install leaf, and
he couldnt use leaf to configure it.

I believe that leaf is needed to make it easier and more
straightforward for Emacs users to install packages.  And I think
it will be the centerpiece of the upcoming Emacs-28[6].  Please comment.


[1]: https://elpa.gnu.org/packages/leaf.html
[2]: https://github.com/conao3/leaf.el
[3]: https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg00741.html
[4]: https://github.com/jwiegley/use-package
[5]: https://github.com/jwiegley/use-package/issues/282#issuecomment-624250623
[6]: https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg00357.html

Re: Include leaf in Emacs distribution

[Ergus]

[-- Attachment #1: Type: text/plain, Size: 2342 bytes --]

Hí Naoya:

Some weeks ago I mention exactly this same topic with not reply. I may say that I use use-package but it seems there is not progress with the copyright issues there.

So far if we add leaf, native-compiker, which-key and ivy probably it is enough to make a new release :p

So in that case I will be fine if leaf comes to vanilla and I wont have objection to migrate. 

I expect that leaf brings all the use-package functionalities right? AFAIR it didn't have a verbose obtion useful to debug and some other customs use-package has... But maybe I can live with that.

Thanks for the package,
Ergus



On October 8, 2020 3:37:47 AM GMT+02:00, Naoya Yamashita <conao3@gmail.com> wrote:
>
>Hello, all.
>
>I'm author of leaf[1][2] which is one of ELPA package.  I propose
>to add the package in the default Emacs dictribution.
>
>leaf is included in ELPA from this message[3] but the 13 emails
>with Stefan starting with this one did not appear to have been
>sent to this ML and were not archived.  If anyone is interested,
>I'll put them in public.  (It is needed from Stefan's agreement maybe.)
>
>Now, leaf wraps the idiom for configuring Emacs packages.  If
>you're using use-package[4], it's not hard to imagine.  The offering
>is pretty much the same but bit different.
>
>Why did I create leaf?  Because the syntax of the use-package was
>a bit confusing and there were copyright issues[5].
>
>If we have leaf as default Emacs package, users don't need the
>leafs own bootstrap, and even the package.el configuration can
>be written in leaf.  Now users need package.el to install leaf, and
>he couldnt use leaf to configure it.
>
>I believe that leaf is needed to make it easier and more
>straightforward for Emacs users to install packages.  And I think
>it will be the centerpiece of the upcoming Emacs-28[6].  Please
>comment.
>
>
>[1]: https://elpa.gnu.org/packages/leaf.html
>[2]: https://github.com/conao3/leaf.el
>[3]:
>https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg00741.html
>[4]: https://github.com/jwiegley/use-package
>[5]:
>https://github.com/jwiegley/use-package/issues/282#issuecomment-624250623
>[6]:
>https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg00357.html

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 3060 bytes --]

Re: Include leaf in Emacs distribution

[Naoya Yamashita]

Hi Ergus.

> Some weeks ago I mention exactly this same topic with not reply.

Thank you for bringing up my package topic in the Emacs28 thread.
But I found out a few weeks after that message so I couldn't
respond.  Sorry;

> I expect that leaf brings all the use-package functionalities
> right? AFAIR it didn't have a verbose obtion useful to debug
> and some other customs use-package has... But maybe I can live
> with that.

What I'm interested in is the use-package feature that is missing
in my leaf.  Is it `use-package-verbose` feature?

Re: Include leaf in Emacs distribution

[Eli Zaretskii]

> Date: Thu, 08 Oct 2020 18:22:41 +0900 (JST)
> From: Naoya Yamashita <conao3@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> > Some weeks ago I mention exactly this same topic with not reply.
> 
> Thank you for bringing up my package topic in the Emacs28 thread.
> But I found out a few weeks after that message so I couldn't
> respond.  Sorry;
> 
> > I expect that leaf brings all the use-package functionalities
> > right? AFAIR it didn't have a verbose obtion useful to debug
> > and some other customs use-package has... But maybe I can live
> > with that.
> 
> What I'm interested in is the use-package feature that is missing
> in my leaf.  Is it `use-package-verbose` feature?

FWIW, I find the name of the package, 'leaf', to be unintuitive.  Can
we please have a better name, like load-package or activate-package or
something like that?  Using 'leaf', which carries no mnemonic value,
will make it harder to discover.

TIA

Re: Include leaf in Emacs distribution

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > FWIW, I find the name of the package, 'leaf', to be unintuitive.  Can
  > we please have a better name, like load-package or activate-package or
  > something like that?

Hear, hear!

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Include leaf in Emacs distribution

[Naoya Yamashita]

> > FWIW, I find the name of the package, 'leaf', to be unintuitive.  Can
> > we please have a better name, like load-package or activate-package or
> > something like that?
> 
> Hear, hear!

A leaf represents a set of settings, not necessarily a package
unit.  It look at Emacs settings from a different perspective
from use-package's one as a package philosophy.

As the name implies, use-package expresses a package's
configuration in a single use-package macro.  So jweigley who is
the use-package author expects one use-package per package, and
they are all written at the top level with no nesting[1].  And
the keywordless use-package will be converted into a `require`
statement using the first argument.

On the other hand, what the leaf manages is a "block of
configuration". Therefore, leaf without the keyword will be
converted to `prog1`.  And because it is a configuration block, a
package configuration can be described in multiple leaves instead
of one leaf.  Also, while jweigley expects use-package to be
written without nesting, I expect the leaf statements to be
nested according to the context.

What I envisioned when I started the project was a picture of
each individual setting mass, each leaf, doing its part to make
up a whole, a big tree.  Because I envisioned multiple leaves for
a single package in this way, I came up with the package name
"leaf" instead of "package".

[1]: https://github.com/jwiegley/use-package/issues/453#issuecomment-347750736

Re: Include leaf in Emacs distribution

[Thibaut Verron]

> As the name implies, use-package expresses a package's
> configuration in a single use-package macro.  So jweigley who is
> the use-package author expects one use-package per package, and
> they are all written at the top level with no nesting[1].

Even if it is what the author expects, it is not enforced. For
instance, I have several instances in my init.el of packages with two
use-package specifications: one to specify where to find the package
and one to apply settings.

And I have several "use-package emacs" instances for settings which
don't belong to any package.

> And
> the keywordless use-package will be converted into a `require`
> statement using the first argument.

Isn't it eval-after-load?
In particular, if there are no autoloads, you need to explicitly
"require" the package in :init, no?


> On the other hand, what the leaf manages is a "block of
> configuration". Therefore, leaf without the keyword will be
> converted to `prog1`.  And because it is a configuration block, a
> package configuration can be described in multiple leaves instead
> of one leaf.  Also, while jweigley expects use-package to be
> written without nesting, I expect the leaf statements to be
> nested according to the context.
>
> What I envisioned when I started the project was a picture of
> each individual setting mass, each leaf, doing its part to make
> up a whole, a big tree.  Because I envisioned multiple leaves for
> a single package in this way, I came up with the package name
> "leaf" instead of "package".

In usual tree terminology (both in graph theory and in botany), leaves
do not have children. So the name does not really convey the meaning
that leaves are expected to be nested.

Re: Include leaf in Emacs distribution

[Naoya Yamashita]

> Even if it is what the author expects, it is not enforced. For
> instance, I have several instances in my init.el of packages with two
> use-package specifications: one to specify where to find the package
> and one to apply settings.
> 
> And I have several "use-package emacs" instances for settings which
> don't belong to any package.

Good point.  Since `(use-package emacs)` generates `(require
'emacs)`, we need to use such a hack to generate a harmless
require statement.  Since leaf generates prog1 without a keyword,
no hack is needed.  You can write a leaf expression with free
descriptive symbols such as `(leaf *elpa-workaround)`.  You can
also descrive this using use-package, but this requires the
`:no-require` keyword in each use-package expression to suppress
generate `require` Sexp.

EXAMPLE (leaf/use-package :no-require comparison):
```
(use-package package
  :custom ((package-archives '(("gnu" . "https://elpa.gnu.org/packages/")
                               ("melpa" . "https://melpa.org/packages/")
                               ("org" . "https://orgmode.org/elpa/"))))
  :config
  (use-package *elpa-workaround
    :no-require
    :when (version= emacs-version "26.2")
    :custom ((gnutls-algorithm-priority "NORMAL:-VERS-TLS1.3"))))

(leaf package
  :custom ((package-archives . '(("gnu" . "https://elpa.gnu.org/packages/")
                                 ("melpa" . "https://melpa.org/packages/")
                                 ("org" . "https://orgmode.org/elpa/"))))
  :config
  (leaf *elpa-workaround
    :emacs= "26.2"
    :custom ((gnutls-algorithm-priority . "NORMAL:-VERS-TLS1.3"))))
```

(use-package/leaf divided by such a chunk of configuration gives
us the opportunity to disable that unit using `:disabled`
keyword.  And jump to the Sexp quickly using `imenu`.)

>> And
>> the keywordless use-package will be converted into a `require`
>> statement using the first argument.
>
> Isn't it eval-after-load?

No.  Please expand like `(use-package flymake)`.  This
use-package expression is expanded `(require 'flymake)`.  On the
other hand, `(leaf flymake)` is expanded `(prog1 'flymake)` which
just wrap other generated Sexps.

> In particular, if there are no autoloads, you need to explicitly
> "require" the package in :init, no?

If you need `require` package, you can use explicit `:require`
keyword in leaf.  But, because now modern packages is well
configured and maintained autoload comment, we don't needed
explicit `require` Sexp.  So leaf contribute speeding up Emacs's
startup time.  This has been reported by users who have migrated
from use-package to leaf.

> In usual tree terminology (both in graph theory and in botany), leaves
> do not have children. So the name does not really convey the meaning
> that leaves are expected to be nested.

Yes, good point.  This is true.

Since I manage over 200 packages with this package, I needed to
find the names of the packages as short as possible as I would be
describing them over and over again.

My favorite features in use-package are :disabled and :when.  As
a chunk of configuration, these could be disabled on a
situational basis, contributing to quick init.el management.  For
me, as a Japanese, I find the same heart as Bonsai[1] in the
Emacs setup.  A Bonsai is something he will spend a long time
loving, depending on his preferences.  In this analogy, If it's
divided into functional units using leaf, you might be able to
incorporate someone else's leaf into your Bonsai.  And you may be
able to absorb the differences in your some of environment by
temporarily disabling the leaf.

And already leaf is an ELPA package[2] and has a large number of
users with over 150,000+ downloads from MELPA[3].  In addition,
there are several packages[3] that depend on leaf.  Changing the
name of leaf from now on is not practical I think.

(DISCLAIMER:
use-package is downloaded 1,100,000+ from MELPA[4].  This is
because it's been distributed by MELPA since 2013 and because
it's the first package in this field.  leaf has been distributed
since 2019 and is in the process of rapidly growing its user base.)

[1]: https://en.wikipedia.org/wiki/Bonsai
[2]: https://elpa.gnu.org/packages/leaf.html
[3]: https://melpa.org/#/?q=leaf
[4]: https://melpa.org/#/?q=use-package

Re: Include leaf in Emacs distribution

[Thibaut Verron]

> Good point.  Since `(use-package emacs)` generates `(require
> 'emacs)`, we need to use such a hack to generate a harmless
> require statement.  Since leaf generates prog1 without a keyword,
> no hack is needed.  You can write a leaf expression with free
> descriptive symbols such as `(leaf *elpa-workaround)`.  You can
> also descrive this using use-package, but this requires the
> `:no-require` keyword in each use-package expression to suppress
> generate `require` Sexp.

Okay, that is definitely added value.

> No.  Please expand like `(use-package flymake)`.  This
> use-package expression is expanded `(require 'flymake)`.  On the
> other hand, `(leaf flymake)` is expanded `(prog1 'flymake)` which
> just wrap other generated Sexps.

Because I'm using straight the actual expansion is more complicated,
but the require is there.

(progn
  (straight-use-package 'flymake)
  (defvar use-package--warning98
    #'(lambda
(keyword err)
(let
    ((msg
      (format "%s/%s: %s" 'flymake keyword
      (error-message-string err))))
  (display-warning 'use-package msg :error))))
  (condition-case-unless-debug err
      (if
  (not
   (require 'flymake nil t))
  (display-warning 'use-package
   (format "Cannot load %s" 'flymake)
   :error))
    (error
     (funcall use-package--warning98 :catch err))))

> > In particular, if there are no autoloads, you need to explicitly
> > "require" the package in :init, no?
>
> If you need `require` package, you can use explicit `:require`
> keyword in leaf.  But, because now modern packages is well
> configured and maintained autoload comment, we don't needed
> explicit `require` Sexp.  So leaf contribute speeding up Emacs's
> startup time.  This has been reported by users who have migrated
> from use-package to leaf.

I was talking about use-package. I have a lot of requires in my
init.el, but I don't know if they are all necessary. Maybe they are
only needed for packages for which I had to supply :init
specifications, or maybe they are not needed at all.

As for startup time, it is 2s and I use emacsclient. I voluntarily
choose to load everything at start-up, those 2 seconds are a minor
annoyance maybe once a day, which is a lot preferrable to several
minor annoyances when I first open a tex, org or pdf file.

I have no doubt that leaf has a similar option as use-package to never
defer loading. :)

>
> > In usual tree terminology (both in graph theory and in botany), leaves
> > do not have children. So the name does not really convey the meaning
> > that leaves are expected to be nested.
>
> Yes, good point.  This is true.
>
> Since I manage over 200 packages with this package, I needed to
> find the names of the packages as short as possible as I would be
> describing them over and over again.

Sorry, I don't understand.

>
> My favorite features in use-package are :disabled and :when.  As
> a chunk of configuration, these could be disabled on a
> situational basis, contributing to quick init.el management.

Interesting. For me :when is the most disappointing feature. My
typical use-case for conditionally loading a package is the
availability of some program on the system, or having or not sudo
rights. Because the :when keyword applies to loading the package, as
opposed to installing it, I cannot use it in this case.

So I have a couple (when my-bool (use-package ...)) in my init.

> And already leaf is an ELPA package[2] and has a large number of
> users with over 150,000+ downloads from MELPA[3].  In addition,
> there are several packages[3] that depend on leaf.  Changing the
> name of leaf from now on is not practical I think.
>
> (DISCLAIMER:
> use-package is downloaded 1,100,000+ from MELPA[4].  This is
> because it's been distributed by MELPA since 2013 and because
> it's the first package in this field.  leaf has been distributed
> since 2019 and is in the process of rapidly growing its user base.)

It might be the best we have, but counting downloads does not count
individual users. Some users will bootstrap multiple instances of
emacs with use-package or leaf, each resulting in one download.

Also some package managers, such as straight, can completely bypass
melpa (and elpa too? not sure).

And I wouldn't be too surprised if a significant part of leaf's 150k
were already included in the 1.1M of use-package.

It's only tangentially related, but maybe we could suggest that Melpa
report downloads per year, that might already give a better measure of
the number of current users.

Re: Include leaf in Emacs distribution

[Naoya Yamashita]

> Okay, that is definitely added value.

Thanks.

> Because I'm using straight the actual expansion is more complicated,
> but the require is there.

? Yes, use-package is expand `require` Sexp, but leaf is not.

```
(let ((use-package-expand-minimally t))
  (macroexpand-1
   '(use-package flymake)))
;;=> (require 'flymake nil nil)

(let ((leaf-expand-minimally t))
  (macroexpand-1
   '(leaf flymake)))
;;=> (prog1 'flymake)
```

> I was talking about use-package. I have a lot of requires in my
> init.el, but I don't know if they are all necessary. Maybe they are
> only needed for packages for which I had to supply :init
> specifications, or maybe they are not needed at all.
> 
> As for startup time, it is 2s and I use emacsclient. I voluntarily
> choose to load everything at start-up, those 2 seconds are a minor
> annoyance maybe once a day, which is a lot preferrable to several
> minor annoyances when I first open a tex, org or pdf file.
> 
> I have no doubt that leaf has a similar option as use-package to never
> defer loading. :)

leaf always trusts autoload and does not always require it, so
require is only done for packages that explicitly require
it. Therefore, require is only done for packages that explicitly
specify a requirement.  This design was not possible in 2013 when
use-package was created, but few current packages require an
explicit request.

> Interesting. For me :when is the most disappointing feature. My
> typical use-case for conditionally loading a package is the
> availability of some program on the system, or having or not sudo
> rights. Because the :when keyword applies to loading the package, as
> opposed to installing it, I cannot use it in this case.
> 
> So I have a couple (when my-bool (use-package ...)) in my init.

Oh, then you can use leaf's :when keyword.  :when is set more
priority from :ensure, so you can controll :ensure keyword using
:when keyword.

See this example.  leaf generate Sexp what you want.

```
(setq leaf-expand-minimally t)
(setq use-package-expand-minimally t)

(macroexpand-1
 '(use-package flyspell-correct
    :when (executable-find "aspell")
    :ensure t
    :hook org-mode-hook))
;;=> (progn
;;     (use-package-ensure-elpa 'flyspell-correct '(t) 'nil)
;;     (when (executable-find "aspell")
;;       (unless (fboundp 'flyspell-correct)
;;         (autoload #'flyspell-correct "flyspell-correct" nil t))
;;       (add-hook 'org-mode-hook-hook #'flyspell-correct)))

(macroexpand-1
 '(leaf flyspell-correct
    :when (executable-find "aspell")
    :ensure t
    :hook org-mode-hook))
;;=> (prog1 'flyspell-correct
;;     (unless (fboundp 'flyspell-correct-mode)
;;       (autoload #'flyspell-correct-mode "flyspell-correct" nil t))
;;     (when (executable-find "aspell")
;;       (leaf-handler-package flyspell-correct flyspell-correct nil)
;;       (add-hook 'org-mode-hook #'flyspell-correct-mode)))
```

> It might be the best we have, but counting downloads does not count
> individual users. Some users will bootstrap multiple instances of
> emacs with use-package or leaf, each resulting in one download.

It say `download` but download from same IP, count as 1, I
remmember (but no source comment...)

> Also some package managers, such as straight, can completely bypass
> melpa (and elpa too? not sure).

True.

> And I wouldn't be too surprised if a significant part of leaf's 150k
> were already included in the 1.1M of use-package.
> 
> It's only tangentially related, but maybe we could suggest that Melpa
> report downloads per year, that might already give a better measure of
> the number of current users.

There are idea[1] but it is not implemented?

[1]: https://github.com/melpa/melpa/issues/2416

Re: Include leaf in Emacs distribution

[Ergus via Emacs development discussions.]

[-- Attachment #1: Type: text/plain, Size: 5164 bytes --]

I have to say that I have use-packages since ever with no issues; and just very recently I tried leaf and it has indeed a cleaner/simpler implementation some improve in startup time and more coherent syntax. Also extensibility/api looks as well a bit more coherent.

BUT we must find a better alternative than adding two overlapping packages to vanilla. It doubles the code with half benefit.

use-package is indeed the sort of standard but IMO a bit too much code. Before coming to vanilla either leaf or use-package will need some modifications, so maybe we should somehow require use-packages to include the leaf improves (or viceversa) before coming to vanilla. If it breaks backward compatibility with the original packages it is not a problem as they are not in vanilla yet and use-package is not even in elpa... We must priorize functionality and future maintainability over backward compatibility of external code; in this case we can assert it before including any alternative because once inside the backward compatibility requirement will be stronger.



On October 12, 2020 4:10:45 AM GMT+02:00, Naoya Yamashita <conao3@gmail.com> wrote:
>
>> Okay, that is definitely added value.
>
>Thanks.
>
>> Because I'm using straight the actual expansion is more complicated,
>> but the require is there.
>
>? Yes, use-package is expand `require` Sexp, but leaf is not.
>
>```
>(let ((use-package-expand-minimally t))
>  (macroexpand-1
>   '(use-package flymake)))
>;;=> (require 'flymake nil nil)
>
>(let ((leaf-expand-minimally t))
>  (macroexpand-1
>   '(leaf flymake)))
>;;=> (prog1 'flymake)
>```
>
>> I was talking about use-package. I have a lot of requires in my
>> init.el, but I don't know if they are all necessary. Maybe they are
>> only needed for packages for which I had to supply :init
>> specifications, or maybe they are not needed at all.
>> 
>> As for startup time, it is 2s and I use emacsclient. I voluntarily
>> choose to load everything at start-up, those 2 seconds are a minor
>> annoyance maybe once a day, which is a lot preferrable to several
>> minor annoyances when I first open a tex, org or pdf file.
>> 
>> I have no doubt that leaf has a similar option as use-package to
>never
>> defer loading. :)
>
>leaf always trusts autoload and does not always require it, so
>require is only done for packages that explicitly require
>it. Therefore, require is only done for packages that explicitly
>specify a requirement.  This design was not possible in 2013 when
>use-package was created, but few current packages require an
>explicit request.
>
>> Interesting. For me :when is the most disappointing feature. My
>> typical use-case for conditionally loading a package is the
>> availability of some program on the system, or having or not sudo
>> rights. Because the :when keyword applies to loading the package, as
>> opposed to installing it, I cannot use it in this case.
>> 
>> So I have a couple (when my-bool (use-package ...)) in my init.
>
>Oh, then you can use leaf's :when keyword.  :when is set more
>priority from :ensure, so you can controll :ensure keyword using
>:when keyword.
>
>See this example.  leaf generate Sexp what you want.
>
>```
>(setq leaf-expand-minimally t)
>(setq use-package-expand-minimally t)
>
>(macroexpand-1
> '(use-package flyspell-correct
>    :when (executable-find "aspell")
>    :ensure t
>    :hook org-mode-hook))
>;;=> (progn
>;;     (use-package-ensure-elpa 'flyspell-correct '(t) 'nil)
>;;     (when (executable-find "aspell")
>;;       (unless (fboundp 'flyspell-correct)
>;;         (autoload #'flyspell-correct "flyspell-correct" nil t))
>;;       (add-hook 'org-mode-hook-hook #'flyspell-correct)))
>
>(macroexpand-1
> '(leaf flyspell-correct
>    :when (executable-find "aspell")
>    :ensure t
>    :hook org-mode-hook))
>;;=> (prog1 'flyspell-correct
>;;     (unless (fboundp 'flyspell-correct-mode)
>;;       (autoload #'flyspell-correct-mode "flyspell-correct" nil t))
>;;     (when (executable-find "aspell")
>;;       (leaf-handler-package flyspell-correct flyspell-correct nil)
>;;       (add-hook 'org-mode-hook #'flyspell-correct-mode)))
>```
>
>> It might be the best we have, but counting downloads does not count
>> individual users. Some users will bootstrap multiple instances of
>> emacs with use-package or leaf, each resulting in one download.
>
>It say `download` but download from same IP, count as 1, I
>remmember (but no source comment...)
>
>> Also some package managers, such as straight, can completely bypass
>> melpa (and elpa too? not sure).
>
>True.
>
>> And I wouldn't be too surprised if a significant part of leaf's 150k
>> were already included in the 1.1M of use-package.
>> 
>> It's only tangentially related, but maybe we could suggest that Melpa
>> report downloads per year, that might already give a better measure
>of
>> the number of current users.
>
>There are idea[1] but it is not implemented?
>
>[1]: https://github.com/melpa/melpa/issues/2416

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 6455 bytes --]

Re: Include leaf in Emacs distribution

[Stefan Kangas]

Naoya Yamashita <conao3@gmail.com> writes:

> What I envisioned when I started the project was a picture of
> each individual setting mass, each leaf, doing its part to make
> up a whole, a big tree.  Because I envisioned multiple leaves for
> a single package in this way, I came up with the package name
> "leaf" instead of "package".

Thanks, your explanation made it a bit more clear how this is different
from `use-package'.  But from your abstract description, I still have a
hard time understanding the benefits of using your package.  Could you
perhaps show an example of the usage you have in mind here?

IMO, the name "leaf" is not very descriptive at all.  Any Lisp code is
already a tree, so it carries little information about exactly what kind
of "leaf" we are talking about.  Why not try to come up with a more
concrete and descriptive name instead (for example,
`use-configuration')?

Re: Include leaf in Emacs distribution

[Stefan Kangas]

Ergus <spacibba@aol.com> writes:

> I may say that I use use-package but it seems there is not progress
> with the copyright issues there.

Why would you say that there is no progress?  It seems to me that
exactly the opposite is the case.

See: https://github.com/jwiegley/use-package/issues/282

Re: Include leaf in Emacs distribution

[Mingde (Matthew) Zeng]

> Why would you say that there is no progress?  It seems to me that
> exactly the opposite is the case.
>
> See: https://github.com/jwiegley/use-package/issues/282

From what I see the copyright assignment is almost done on the use-package side.

From a pure user's perspective, I very much prefer to use a package named `use-package` instead of `leaf` to manage my emacs packages.

Besides, when choosing a package to use, I personally prefer a matured (in terms of the number of years in development and number of contributors) and a popular (in terms of [m]elpa downloads or Github stars or discussions on forums/reddit) package. These are indications to me that the package is good, useful, and that people trust it. use-package excels in all these places.

Maybe leaf has a better design or has better code quality, I haven't personally read the sourcecode so I have no say here.

Therefore I suggest to wait a bit until the use-package team finalizes the copyright assignment and merge that instead.

Anyways no offence intended toward leaf, it is a cool pakcage and I might try it some day. However I just don't think it would be a really good idea for it to be part of emacs itself.


--
Mingde (Matthew) Zeng

Re: Include leaf in Emacs distribution

[Stefan Kangas]

Naoya Yamashita <conao3@gmail.com> writes:

> I'm author of leaf[1][2] which is one of ELPA package.  I propose
> to add the package in the default Emacs dictribution.
[...]
> Now, leaf wraps the idiom for configuring Emacs packages.  If
> you're using use-package[4], it's not hard to imagine.  The offering
> is pretty much the same but bit different.
>
> Why did I create leaf?  Because the syntax of the use-package was
> a bit confusing and there were copyright issues[5].

Thanks for your work.  FWIW, here are my two cents.

First, the copyright issues with use-package are being worked on, see:
https://github.com/jwiegley/use-package/issues/282

Once that is worked out, we could include both use-package and leaf in
Emacs, only one of them, or both.  It is good that we have two packages
here, since it gives us more options.

I have looked at the leaf package before, but I could never figure out
why I would want to use it instead of use-package.  They are very
similar, and the functionality seems to be mostly overlapping.  I think
that we should perhaps consider why we even have two packages here.
Could the functionality of one be absorbed by the other?  Are the
differences really that important?  But maybe I'm just missing
something.

Personally, I'd rather not see two very similar packages in Emacs unless
there are important differences and sufficiently strong reasons.

One starting point here is that use-package seems to be more widely used
and known.  If this is correct, I guess leaf unfortunately has a bit of
an uphill battle to show some significant improvement over use-package.

Re: Include leaf in Emacs distribution

[Naoya Yamashita]

> Thanks for your work.  FWIW, here are my two cents.
>
> First, the copyright issues with use-package are being worked on, see:
> https://github.com/jwiegley/use-package/issues/282
>
> Once that is worked out, we could include both use-package and leaf in
> Emacs, only one of them, or both.  It is good that we have two packages
> here, since it gives us more options.

Yes I've known that.  You can submit topic after the issue is resolved.

> I have looked at the leaf package before, but I could never figure out
> why I would want to use it instead of use-package.  They are very
> similar, and the functionality seems to be mostly overlapping.  I think
> that we should perhaps consider why we even have two packages here.
> Could the functionality of one be absorbed by the other?  Are the
> differences really that important?  But maybe I'm just missing
> something.
>
> Personally, I'd rather not see two very similar packages in Emacs unless
> there are important differences and sufficiently strong reasons.

It is your choice, Nothing bad.

From my point of view the syntax of use-package is confusing.
For example, :when is naturally designed to evaluate a given
S-expression and is only enabled when non-nil is returned, but
:disabled is not.  That is, (use-package flymake :disabled t) and
(use-package flymake :disabled nil) will be converted to nil,
respectively.  This is unnatural.  Also, :when can be a free
S-expression, but not :disabled.

Other keyword, :mode and :hook specify a cons cell, but :custom
specifies a list.  This can be confusing for newcomers.

Both issue are solved in my leaf.

> One starting point here is that use-package seems to be more widely used
> and known.  If this is correct, I guess leaf unfortunately has a bit of
> an uphill battle to show some significant improvement over use-package.

As I wrote in another email, use-package was created in 2012 and
has been distributed by MELPA since 2013.  The number and
visibility of users is because of its history and because it's
the first package in this field.  And with that many users, it's
hard to solve these problems because the syntax needs to be
changed.

Re: Include leaf in Emacs distribution

[Stefan Kangas]

Naoya Yamashita <conao3@gmail.com> writes:

> From my point of view the syntax of use-package is confusing.
> For example, :when is naturally designed to evaluate a given
> S-expression and is only enabled when non-nil is returned, but
> :disabled is not.  That is, (use-package flymake :disabled t) and
> (use-package flymake :disabled nil) will be converted to nil,
> respectively.  This is unnatural.  Also, :when can be a free
> S-expression, but not :disabled.

I'm not sure I understand.  Are you saying that, in use-package, the
existence of `:disabled' means that the package will not be loaded even
if its value is specified to be nil?

> Other keyword, :mode and :hook specify a cons cell, but :custom
> specifies a list.  This can be confusing for newcomers.

Could you show an example of this?

> Both issue are solved in my 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)?

I believe that the answers to the above questions would help improve
everyone's understanding of the issues involved.

Re: Include leaf in Emacs distribution

[Qiantan Hong]

[-- Attachment #1: Type: text/plain, Size: 200 bytes --]

I think for those syntatic matter, if everyone agree
that some behavior is better, it would be trivial to change
either use-package or leaf or whatever other package
management package to that syntax.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 1858 bytes --]

Re: Include leaf in Emacs distribution

[Caio Henrique]

Stefan Kangas <stefankangas@gmail.com> writes:

> Could you explain why Emacs would want to include one or the other (as
> developers)?

IMO it would help with the "emacs wizard" proposal. For instance, if
there is a "install undo-tree and enable it globally" option on the
wizard, it could generate something like this on the emacs init file:

(use-package undo-tree
  :ensure t
  :diminish undo-tree-mode
  :config (global-undo-tree-mode))

With nongnu elpa, use-package or leaf and the "emacs wizard" we could
provide several use-package or leaf recipes for the newbies making it
easier for them to have what they expect from modern IDEs with recipes
for packages like eglot, company, yasnippet, magit, flymake etc.

Re: Include leaf in Emacs distribution

[Stefan Monnier]

> IMO it would help with the "emacs wizard" proposal. For instance, if
> there is a "install undo-tree and enable it globally" option on the
> wizard, it could generate something like this on the emacs init file:
>
> (use-package undo-tree
>   :ensure t
>   :diminish undo-tree-mode
>   :config (global-undo-tree-mode))

Why not just use

    (global-undo-tree-mode 1)

?

Assuming the `gnu-elpa` package is installed (which I'd hope we could
bundle with Emacs-28), then it should do pretty much the same as your
`use-package` code above, except for the `diminish` which seems
orthogonal (if we think it should be diminished by default, then we
should change undo-tree accordingly).


        Stefan

Re: Include leaf in Emacs distribution

[Thibaut Verron]

Le mar. 13 oct. 2020 à 15:23, Stefan Monnier
<monnier@iro.umontreal.ca> a écrit :
>
> > IMO it would help with the "emacs wizard" proposal. For instance, if
> > there is a "install undo-tree and enable it globally" option on the
> > wizard, it could generate something like this on the emacs init file:
> >
> > (use-package undo-tree
> >   :ensure t
> >   :diminish undo-tree-mode
> >   :config (global-undo-tree-mode))
>
> Why not just use
>
>     (global-undo-tree-mode 1)
>
> ?
>
> Assuming the `gnu-elpa` package is installed (which I'd hope we could
> bundle with Emacs-28), then it should do pretty much the same as your
> `use-package` code above,

What would this gnu-elpa package contain, exactly? All the packages
from GNU Elpa?

Regardless, for the example at point, you can replace undo-tree with a
package from non-GNU Elpa.

> except for the `diminish` which seems
> orthogonal (if we think it should be diminished by default, then we
> should change undo-tree accordingly).

But diminish.el is only available on Melpa (and, I assume, soon on
non-GNU Elpa).

Re: Include leaf in Emacs distribution

[Stefan Monnier]

> What would this gnu-elpa package contain, exactly?

No need for the conditional.  You can look at the package

    https://elpa.gnu.org/packages/gnu-elpa.html

or install it with `M-x package-install`.

> All the packages from GNU Elpa?

Currently, not quite.

>> except for the `diminish` which seems orthogonal (if we think it
>> should be diminished by default, then we should change undo-tree
>> accordingly).
> But diminish.el is only available on Melpa (and, I assume, soon on
> non-GNU Elpa).

I don't think you need this specific package in order to get the
corresponding change in behavior for undo-tree.

What I meant is that if we think that undo-tree should be `diminish`ed
by default, then it means we consider the default behavior of
`undo-tree` to be wrong and we should consider it as a bug to fix in
`undo-tree`.


        Stefan

Re: Include leaf in Emacs distribution

[Thibaut Verron]

Le mar. 13 oct. 2020 à 16:29, Stefan Monnier
<monnier@iro.umontreal.ca> a écrit :
>
> > What would this gnu-elpa package contain, exactly?
>
> No need for the conditional.  You can look at the package
>
>     https://elpa.gnu.org/packages/gnu-elpa.html
>
> or install it with `M-x package-install`.

Oh, thanks!

> >> except for the `diminish` which seems orthogonal (if we think it
> >> should be diminished by default, then we should change undo-tree
> >> accordingly).
> > But diminish.el is only available on Melpa (and, I assume, soon on
> > non-GNU Elpa).
>
> I don't think you need this specific package in order to get the
> corresponding change in behavior for undo-tree.
>
> What I meant is that if we think that undo-tree should be `diminish`ed
> by default, then it means we consider the default behavior of
> `undo-tree` to be wrong and we should consider it as a bug to fix in
> `undo-tree`.

Ah yes, I read it differently.

The way I understand it, some users like to have diminished names on
their mode line, some like the default behaviour, some have something
different...
So to please everybody (and avoid spending as much energy as a small
town in mail traffic), we can provide a "setting block" setting the
diminished name only if the user wants diminished names.

Ideally it would be setting a variable interpreted by diminish-mode,
but even if there is no such mode (I'm not sure), something like

   (with-eval-after-load 'diminish (diminish 'undo-tree-mode))

would work.

Re: Include leaf in Emacs distribution

[Phil Sainty]

On 14/10/20 4:29 am, Thibaut Verron wrote:
> But diminish.el is only available on Melpa (and, I assume,
> soon on non-GNU Elpa).

You could use delight.el which *is* in GNU ELPA:

(delight 'undo-tree-mode nil "undo-tree")

use-package supports delight directly:
https://www.emacswiki.org/emacs/DelightedModes#toc7

The :delight keyword gets a mention in the leaf readme too,
so I suspect it's supported by that too.


-Phil

Re: Include leaf in Emacs distribution

[Caio Henrique]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> IMO it would help with the "emacs wizard" proposal. For instance, if
>> there is a "install undo-tree and enable it globally" option on the
>> wizard, it could generate something like this on the emacs init file:
>>
>> (use-package undo-tree
>>   :ensure t
>>   :diminish undo-tree-mode
>>   :config (global-undo-tree-mode))
>
> Why not just use
>
>     (global-undo-tree-mode 1)
>
> ?
>
> Assuming the `gnu-elpa` package is installed (which I'd hope we could
> bundle with Emacs-28), then it should do pretty much the same as your
> `use-package` code above, except for the `diminish` which seems
> orthogonal (if we think it should be diminished by default, then we
> should change undo-tree accordingly).
>
>
>         Stefan

That was just a simple example from my init file to try to show that
use-package or leaf could help to keep package configurations more
consistent and that it could be used by the code generated by the "emacs
wizard", thus we have reasons to include use-package or leaf on the
Emacs core. So I was not suggesting to add undo-tree or diminish on the
"emacs wizard". 

Imagine that we have a lot of recipes on the "emacs wizard" for several
different packages with more complex declarations, in this case
use-package or leaf can keep things more organized and consistent. (I
know that this is subjective.)

Here are some more examples from my init file:

(use-package ivy
  :straight t
  :diminish ivy-mode
  :defer 0.9
  :config
  (use-package swiper
    :straight t
    :bind (("C-s" . swiper)
           ("C-M-s" . swiper-thing-at-point)))
  (use-package counsel
    :straight t
    :diminish counsel-mode
    :config (counsel-mode))
  (use-package ivy-avy
    :straight t)
  (ivy-mode))

(use-package company
  :straight t
  :commands company-mode
  :bind (:map company-active-map
         ("C-n" . 'company-select-next)
         ("C-p" . 'company-select-previous))
  :config
  (use-package company-quickhelp
    :straight t
    :hook (company-mode . company-quickhelp-local-mode)))

(use-package lsp-mode
  :straight t
  :hook
  ((c++-mode . lsp)
   (c-mode . lsp)
   (js-mode . lsp)
   (python-mode . lsp)))

Re: Include leaf in Emacs distribution

[Naoya Yamashita]

> That was just a simple example from my init file to try to show that
> use-package or leaf could help to keep package configurations more
> consistent and that it could be used by the code generated by the "emacs
> wizard", thus we have reasons to include use-package or leaf on the
> Emacs core. So I was not suggesting to add undo-tree or diminish on the
> "emacs wizard". 

> Imagine that we have a lot of recipes on the "emacs wizard" for several
> different packages with more complex declarations, in this case
> use-package or leaf can keep things more organized and consistent. (I
> know that this is subjective.)

Totally agree.  I believe that using leaf allows for a more
consistent Emacs setup.

Of course, I understand that leaf is just a macro, simply
wrapping bare Elisp, but I think this has the effect of making
the user focus on the essential meaning.  Emacs already has the
same type of Elisp built into it.  It's derived and easy-mmode.
I know how to create major-mode and minor-mode without those
macros, but I think almost all users will use those macros.

That's because they know it's more declarative, easier to
maintain, and more robust to use.  The leaf provides the same
thing for package settings.  With a more parsimonious and
declarative syntax, the user writes the configuration and leaf
converts it into Elisp.

The usefulness of leaf and use-package is demonstrated by the
MELPA DL numbers.  As leaf or use-package include into Emacs,
their bootstrapping code can be omitted and the user's init.el
will be more consistent.

###

There have been numerous points made in the thread so far.

- The first is the problem that the name leaf doesn't indicate its feature
- The second issue is that use-package has a licensing problem.
    (This is an issue that will be resolved by the release of Emacs-28, I believe.)
- Third, the issue of the benefits of leaf and use-package to Emacs users.

Are there any other points of discussion?

Re: Include leaf in Emacs distribution

[John Wiegley]

>>>>> Naoya Yamashita <conao3@gmail.com> writes:

> The usefulness of leaf and use-package is demonstrated by the
> MELPA DL numbers.  As leaf or use-package include into Emacs,
> their bootstrapping code can be omitted and the user's init.el
> will be more consistent.

I believe so as well. I had meant to prepare the patch for including
use-package.el into Emacs last week, but will make time this weekend now that
I'm at my sister's cabin and have some time to myself for a few days.

As Stefan fears, it could lessen the need for package authors to make their
products as configurable as they might be, but I believe on the whole it
allows for more consistency and clarity in users' configuration files, and
sometimes such a feeling alone is worth quite a lot indeed.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Include leaf in Emacs distribution

[Stefan Monnier]

> products as configurable as they might be, but I believe on the whole it
> allows for more consistency and clarity in users' configuration files, and
> sometimes such a feeling alone is worth quite a lot indeed.

I also hope we can use it to make init files "compatible" with flymake.
IOW make it so byte-compiling your init file doesn't result in lots and
lots of "spurious" warnings.


        Stefan

Re: Include leaf in Emacs distribution

[Naoya Yamashita]

> I also hope we can use it to make init files "compatible" with flymake.
> IOW make it so byte-compiling your init file doesn't result in lots and
> lots of "spurious" warnings.

I believe john say same thing, leaf and use-package have the
feature to generate `defvar` and `declare-function` to prevent
warnings in byte compiling.  So my init.el also uses flycheck,
but there are no warnings.  References to undefined
functions/variables are shown as usual, and the warnings are very
useful.

```
(macroexpand-1
 '(leaf server
    :doc "Lisp code for GNU Emacs running as server process"
    :defvar server-temp-file-regexp
    :defun server-running-p
    :config
    (setq server-temp-file-regexp
          (rx-to-string `(or (regexp ,server-temp-file-regexp) ".DS_Store") t))
    (unless (server-running-p)
      (server-start))))
;;=> (prog1 'server
;;     (declare-function server-running-p "server")
;;     (defvar server-temp-file-regexp)
;;     (setq server-temp-file-regexp
;;           (rx-to-string `(or (regexp ,server-temp-file-regexp) ".DS_Store") t))
;;     (unless (server-running-p)
;;       (server-start)))


(let ((byte-compile-current-file "bar"))
  (macroexpand-1
   '(use-package server
      :defines server-temp-file-regexp
      :functions server-running-p
      :config
      (setq server-temp-file-regexp
            (rx-to-string `(or (regexp ,server-temp-file-regexp) ".DS_Store") t))
      (unless (server-running-p)
        (server-start)))))
;;=> (progn
;;     (eval-and-compile
;;       (defvar server-temp-file-regexp)
;;       (declare-function server-running-p "server")
;;       (eval-when-compile
;;         (with-demoted-errors "Cannot load server: %S"
;;           nil
;;           (unless (featurep 'server)
;;             (load "server" nil t)))))
;;     (require 'server nil nil)
;;     (setq server-temp-file-regexp
;;           (rx-to-string `(or (regexp ,server-temp-file-regexp) ".DS_Store") t))
;;     (unless (server-running-p)
;;       (server-start))
;;     t)
```

I've also compared leaf and use-package.

- The leaf has document keywords such as :doc.  The advantage of
  this is that the text is easier to recognize than the comments
  due to the color scheme.  In addition, other packages can use
  the strings specified by this keyword.

- The :defines of use-package becomes a :defvar in the leaf.
  It's very analogous to defvar, considering that defvar prevents
  warnings on variable references.

- A :function of use-package is a :defun in the leaf.  It is a
  function version of :defvar to suppress function warnings.
  There is a possibility of misunderstanding because there're no
  actual `defun`, but it's an acceptable confusion compared to
  the disadvantage of not knowing whether `:defines` are
  variables or functions.

- use-package has an expression that is secretly output only
  during byte-compilation.  In this case, if
  `byte-compile-current-file` is nil, then `:defines` and
  `:functions` will not output any expressions.  This makes
  debugging difficult; leaf does not have this feature. It's
  consistent.

- use-package will add a `t` to the use-package's own return
  value, as shown in this example, to make the overall return
  value to `t`, while sometimes returning a set right-hand side
  value.  This is a confusion, and the leaf solves it; the return
  value returned by the leaf is always a symbol of the first
  argument.

###

Sample init.el I tested.  We (I and john) want to remove this
bootstrap code.

```
;;; init.el --- Sample clean init.el  -*- lexical-binding: t; -*-

;; ~/.debug.emacs.d/leaf-byte-compile/init.el

;; you can run like 'emacs -q -l ~/.debug.emacs.d/leaf-byte-compile/init.el'
(when load-file-name
  (setq user-emacs-directory
        (expand-file-name (file-name-directory load-file-name))))

(eval-when-compile
  (setq user-emacs-directory
        (expand-file-name (file-name-directory default-directory))))

(eval-and-compile
  (prog1 "leaf"
    (custom-set-variables
     '(package-archives '(("org"   . "https://orgmode.org/elpa/")
                          ("melpa" . "https://melpa.org/packages/")
                          ("gnu"   . "https://elpa.gnu.org/packages/"))))
    (package-initialize)
    (unless (package-installed-p 'leaf)
      (package-refresh-contents)
      (package-install 'leaf))))

;; ---

(leaf server
  :doc "Lisp code for GNU Emacs running as server process"
  :defvar server-temp-file-regexp
  :defun server-running-p
  :config
  (setq server-temp-file-regexp
        (rx-to-string `(or (regexp ,server-temp-file-regexp) ".DS_Store") t))
  (unless (server-running-p)
    (server-start)))
```

Warnings in init files (was: Include leaf in Emacs distribution)

[Stefan Monnier]

>  '(leaf server
>     :doc "Lisp code for GNU Emacs running as server process"
>     :defvar server-temp-file-regexp
>     :defun server-running-p
>     :config
>     (setq server-temp-file-regexp
>           (rx-to-string `(or (regexp ,server-temp-file-regexp) ".DS_Store") t))
>     (unless (server-running-p)
>       (server-start))))

That's not the solution I'm looking for since it requires that the user
explicitly silences the warnings using :defvar or :defun (i.e. no real
benefit compared to the "old style" config).

I was thinking of something more like:

    (foo server
     (setq server-temp-file-regexp
           (rx-to-string `(or (regexp ,server-temp-file-regexp) ".DS_Store") t))
     (unless (server-running-p)
       (server-start)))

This should be sufficient (given a sufficiently clever handling of
`foo`) since you can go look inside `server.el` and find that those
functions and vars are indeed defined.

Of course, this is not the best example, since the old-style works just
as well without any cleverness:

    (require 'server)
    (setq server-temp-file-regexp
          (rx-to-string `(or (regexp ,server-temp-file-regexp) ".DS_Store") t))
    (unless (server-running-p)
      (server-start)))

Tho I don't recommend this style since `require` is a bad habit in an
init file (in this case it's acceptable since the package will have to
be loaded at this point anyway).


        Stefan

Re: Include leaf in Emacs distribution

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 5743 bytes --]

Naoya Yamashita <conao3@gmail.com> writes:
Another nice to have would be to rationalize lef/use-package vs the
custom file.

Custom-file: One file that holds all settings.

Leaf/use-package: refactors package-specific settings into
package-specific declarations

It would be nice to be able to look in one place (either
use-package/leaf or custom) rather than having to hunt down some rogue
setting in multiple places.

If leaf/use-package is built in to emacs, one possibility might be to
recommend  custom exclusively for   setting emacs builtin settings
e.g.find-file-hook -- but that "builtin definition" can become tenuous
fast.

>> I also hope we can use it to make init files "compatible" with flymake.
>> IOW make it so byte-compiling your init file doesn't result in lots and
>> lots of "spurious" warnings.
>
> I believe john say same thing, leaf and use-package have the
> feature to generate `defvar` and `declare-function` to prevent
> warnings in byte compiling.  So my init.el also uses flycheck,
> but there are no warnings.  References to undefined
> functions/variables are shown as usual, and the warnings are very
> useful.
>
> ```
> (macroexpand-1
>  '(leaf server
>     :doc "Lisp code for GNU Emacs running as server process"
>     :defvar server-temp-file-regexp
>     :defun server-running-p
>     :config
>     (setq server-temp-file-regexp
>           (rx-to-string `(or (regexp ,server-temp-file-regexp) ".DS_Store") t))
>     (unless (server-running-p)
>       (server-start))))
> ;;=> (prog1 'server
> ;;     (declare-function server-running-p "server")
> ;;     (defvar server-temp-file-regexp)
> ;;     (setq server-temp-file-regexp
> ;;           (rx-to-string `(or (regexp ,server-temp-file-regexp) ".DS_Store") t))
> ;;     (unless (server-running-p)
> ;;       (server-start)))
>
>
> (let ((byte-compile-current-file "bar"))
>   (macroexpand-1
>    '(use-package server
>       :defines server-temp-file-regexp
>       :functions server-running-p
>       :config
>       (setq server-temp-file-regexp
>             (rx-to-string `(or (regexp ,server-temp-file-regexp) ".DS_Store") t))
>       (unless (server-running-p)
>         (server-start)))))
> ;;=> (progn
> ;;     (eval-and-compile
> ;;       (defvar server-temp-file-regexp)
> ;;       (declare-function server-running-p "server")
> ;;       (eval-when-compile
> ;;         (with-demoted-errors "Cannot load server: %S"
> ;;           nil
> ;;           (unless (featurep 'server)
> ;;             (load "server" nil t)))))
> ;;     (require 'server nil nil)
> ;;     (setq server-temp-file-regexp
> ;;           (rx-to-string `(or (regexp ,server-temp-file-regexp) ".DS_Store") t))
> ;;     (unless (server-running-p)
> ;;       (server-start))
> ;;     t)
> ```
>
> I've also compared leaf and use-package.
>
> - The leaf has document keywords such as :doc.  The advantage of
>   this is that the text is easier to recognize than the comments
>   due to the color scheme.  In addition, other packages can use
>   the strings specified by this keyword.
>
> - The :defines of use-package becomes a :defvar in the leaf.
>   It's very analogous to defvar, considering that defvar prevents
>   warnings on variable references.
>
> - A :function of use-package is a :defun in the leaf.  It is a
>   function version of :defvar to suppress function warnings.
>   There is a possibility of misunderstanding because there're no
>   actual `defun`, but it's an acceptable confusion compared to
>   the disadvantage of not knowing whether `:defines` are
>   variables or functions.
>
> - use-package has an expression that is secretly output only
>   during byte-compilation.  In this case, if
>   `byte-compile-current-file` is nil, then `:defines` and
>   `:functions` will not output any expressions.  This makes
>   debugging difficult; leaf does not have this feature. It's
>   consistent.
>
> - use-package will add a `t` to the use-package's own return
>   value, as shown in this example, to make the overall return
>   value to `t`, while sometimes returning a set right-hand side
>   value.  This is a confusion, and the leaf solves it; the return
>   value returned by the leaf is always a symbol of the first
>   argument.
>
> ###
>
> Sample init.el I tested.  We (I and john) want to remove this
> bootstrap code.
>
> ```
> ;;; init.el --- Sample clean init.el  -*- lexical-binding: t; -*-
>
> ;; ~/.debug.emacs.d/leaf-byte-compile/init.el
>
> ;; you can run like 'emacs -q -l ~/.debug.emacs.d/leaf-byte-compile/init.el'
> (when load-file-name
>   (setq user-emacs-directory
>         (expand-file-name (file-name-directory load-file-name))))
>
> (eval-when-compile
>   (setq user-emacs-directory
>         (expand-file-name (file-name-directory default-directory))))
>
> (eval-and-compile
>   (prog1 "leaf"
>     (custom-set-variables
>      '(package-archives '(("org"   . "https://orgmode.org/elpa/")
>                           ("melpa" . "https://melpa.org/packages/")
>                           ("gnu"   . "https://elpa.gnu.org/packages/"))))
>     (package-initialize)
>     (unless (package-installed-p 'leaf)
>       (package-refresh-contents)
>       (package-install 'leaf))))
>
> ;; ---
>
> (leaf server
>   :doc "Lisp code for GNU Emacs running as server process"
>   :defvar server-temp-file-regexp
>   :defun server-running-p
>   :config
>   (setq server-temp-file-regexp
>         (rx-to-string `(or (regexp ,server-temp-file-regexp) ".DS_Store") t))
>   (unless (server-running-p)
>     (server-start)))
> ```
>

-- 

Thanks,

--Raman
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: Include leaf in Emacs distribution

[Stefan Kangas]

Naoya Yamashita <conao3@gmail.com> writes:

> Are there any other points of discussion?

Thanks for summarizing the discussion.

There is a plan in motion to distribute use-package with Emacs 28.1.
IOW, it seems emacs-devel is mostly convinced that it brings useful
features.

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?

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

Re: Include leaf in Emacs distribution

[Naoya Yamashita]

Long time no see, sorry I was very busy recentry.

An important point was made in john's email.  I want to summarize
it, but please point out if it's different than intended.

- Both use-package and leaf are declarative macros, which
  translate into appropriate Lisp code

- The point is made that use-package is large and complex, but
  this is only natural and universal truism if any package
  addresses the issues raised by a large user base for several
  years.

- According to the code count, the results of the rewrite project
  is not significant, and I'm not sure if the amount of reduction
  in such a small project justifies a near-but-not-quite rewrite.

- use-package is fully modular and allows users to add keywords
  easily.

- use-package is used in spacemacs and has proven its modularity
  to be useful.

- The emacs-devel doesn't care about the implementation, it cares
  about the interface.

---

I agree with you overall, with conditions.

For example, the last point about focusing on the interface
rather than the implementation is that I think "adding keywords"
is part of the interface provided to the user, and I think the
leaf provides it in a more intuitive and direct way than the
use-package.

Also, getting back to the DSL of the use-package, I disagreed
with the following points when I created leaf.

- use-package without keywords is expanded to require

- Enabled even if :disabled is set to nil

- That :custom receives a list instead of a dot pair

- Complete a symbol name that has an incomplete :hook.
(Users won't be able to do definition jumps, and also, what
happens if there is a hook that doesn't end in -hook?)

- that :load-path only supports paths relative to .emacs.d

- In :bind, the syntax for binding to a local keymap is not well
  thought out, assigning it to a local keymap is difficult to
  understand, and it is incompatible with Elisp indentation.

These are difficult to solve on the use-package, because there
are literally thousands of users of the use-package, and even the
disruptive changes in use-package-3.0 will have an immeasurable
impact.

What do you think?  Do you think we can fix a thought or some
grammatical discrepancy that was appropriate a long time ago with
a use-package?

(When you say yes, I'm willing to help. The question is, can the
user bear this pain?)

Re: Include leaf in Emacs distribution

[John Wiegley]

>>>>> Naoya Yamashita <conao3@gmail.com> writes:

> Also, getting back to the DSL of the use-package, I disagreed
> with the following points when I created leaf.

> - use-package without keywords is expanded to require

I chose this because in effect `(use-package foo)` is saying "I want to use
the package foo". What do you suggest for the default expansion?

> - Enabled even if :disabled is set to nil

I'm not sure I understand, do you mean it's disabled even when set to nil?
This sounds like an easy bug to fix.

> - That :custom receives a list instead of a dot pair

:custom is a rather late addition, and I'm open to adding a new :customize
that uses dot pairs, while deprecating :custom.

> - Complete a symbol name that has an incomplete :hook.
> (Users won't be able to do definition jumps, and also, what
> happens if there is a hook that doesn't end in -hook?)

If there's a hook that doesn't end in -hook, you just use whatever that hook's
name is. `use-package` will look for a variable with that name, if no `-hook`
variant exists.

> - that :load-path only supports paths relative to .emacs.d

You can use any path in :load-path.

> - In :bind, the syntax for binding to a local keymap is not well thought
> out, assigning it to a local keymap is difficult to understand, and it is
> incompatible with Elisp indentation.

I would like to move in the direction of deprecated :bind and allowing the
user to opt-in to general, perhaps making general the default at version 3.0.
I agree that local keymaps are not very well thought out, since they came late
in the game.

> These are difficult to solve on the use-package, because there are literally
> thousands of users of the use-package, and even the disruptive changes in
> use-package-3.0 will have an immeasurable impact.

> What do you think? Do you think we can fix a thought or some grammatical
> discrepancy that was appropriate a long time ago with a use-package?

I think, based on the comments above, that much of your suggestions can be
dealt with a way that won't break existing users: support a new :customize,
provide an option for opting in to use general instead of bind-key, etc.

I also think we could provide a "front-end" to new keywords that does let
people use defcustom to add new keywords, and those keywords would be injected
into the existing system, say based on a position keyword specified in the
defcustom. What do you think of that?

> (When you say yes, I'm willing to help. The question is, can the user bear
> this pain?)

Let's see what we can do! I'd almost always rather collaborate than compete.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Include leaf in Emacs distribution

[Naoya Yamashita]

> I chose this because in effect `(use-package foo)` is saying "I want to use
> the package foo". What do you suggest for the default expansion?

Yes, while `require` is the best way to load a package, packages
are now automatically managed by package.el (and other package
managers), and I think it is bad manners for users to explicitly
`require` it.

All functions that serve as entry points are properly managed by
the autoload magic comment, and Emacs can reduce Emacs startup
time by loading the package the first time it is needed.

This is especially important when describing the configuration of
Emacs' built-in packages in use-package/leaf.  When I was writing
the configuration in use-package, I had to include the
:no-require keyword in almost every use-package (because Emacs'
package is well autoloaded).

A use-package block with a :bind or :hook is not required, but
this is implicit and inconvenient to be aware of at all times.

In the leaf, it is simply `prog1` (or `progn`, but I use `prog1`
to return the package name as the return value for the leaf; the
return value for use-package varies from situation to situation
and seems to be undocumented).

I also like the :disabled and :when keywords.  I find it very
useful to be able to enable/disable them as "chunks of settings"
depending on the situation.  With that in mind, the first
argument of use-package should not be required by default.  I'd
like to put more free symbols in the first argument.


> I'm not sure I understand, do you mean it's disabled even when set to nil?
> This sounds like an easy bug to fix.

Yes, this point is easy to fix.  I think `:disabled` keyword
should interpret its argument.  It seems odd that conditional
branching keywords such as :if interpret t and nil, but not
:disabled.

(below example shows :disabled in `use-package` is always
"enabled" so every use-package expanded to nil.  But :disabled in
leaf interpret its argument so 2nd example expanded empty prog1,
but 3rd example "disabled" :disabled keyword)

```
(setq leaf-expand-minimally t)
;;=> t

(setq use-package-expand-minimally t)
;;=> t

(list
 (macroexpand-1
  '(use-package ppp :disabled :ensure t))

 (macroexpand-1
  '(use-package ppp :disabled t :ensure t))

 (macroexpand-1
  '(use-package ppp :disabled nil :ensure t)))
;;=> (nil nil nil)

(list
 ;; :disabled should take argument, so this leaf is not valid
 ;; (macroexpand-1
 ;;  '(leaf ppp :disabled :ensure t))

 (macroexpand-1
  '(leaf ppp :disabled t :ensure t))

 (macroexpand-1
  '(leaf ppp :disabled nil :ensure t)))
;;=> ((prog1 'ppp)
;;    (prog1 'ppp (leaf-handler-package ppp ppp nil)))
```


> :custom is a rather late addition, and I'm open to adding a new :customize
> that uses dot pairs, while deprecating :custom.

Good to hear it!


> If there's a hook that doesn't end in -hook, you just use whatever that hook's
> name is. `use-package` will look for a variable with that name, if no `-hook`
> variant exists.

We can't set a hook that isn't a -hook suffix.  leaf doesn't
automatically rewrite a given symbol, and I think it's clearer
and more convenient to do so.

init.el is not only for me, it may also be illustrated in
articles and books.  I don't know how beneficial it would be for
users to be able to omit the -hook (it only 5 charactors!).  I
think it confuses the beginning student. (I was.)


> You can use any path in :load-path.

I haven't known this spec before try it.  It's certainly done,
but I think it's easier to understand if you separate the
keywords.  (in leaf, :load-path don't modify its argument but
load-path* interprets the specified argument to be a path
relative to user-emacs-directory.)

```
(list
 (macroexpand-1
  '(use-package ppp
     :load-path "site-lisp/ppp"))

 (macroexpand-1
  '(use-package ppp
     :load-path "/site-lisp/ppp")))
;;=> ((progn
;;      (eval-and-compile
;;        (add-to-list 'load-path "/home/conao/.emacs.d/site-lisp/ppp"))
;;      (require 'ppp nil nil))
;;
;;    (progn
;;      (eval-and-compile
;;        (add-to-list 'load-path "/site-lisp/ppp"))
;;      (require 'ppp nil nil)))
```

BTW, how does the user specify if a he wants to specify a path
relative to an arbitrary path?

```
(macroexpand-1
 '(use-package ppp
    :load-path (expand-file-name "site-lisp/ppp" my-share-dir)))
;;=> Debugger entered--Lisp error: (void-variable expand-file-name)
;;     symbol-value(expand-file-name)
;;     eval((symbol-value 'expand-file-name))
;;     use-package-normalize-paths(":load-path" expand-file-name t)
```

> I would like to move in the direction of deprecated :bind and allowing the
> user to opt-in to general, perhaps making general the default at version 3.0.

I'm interested in this point, but I cannot understand `general`...?
Is that to add a new keyword called `general`?

> I agree that local keymaps are not very well thought out, since they came late
> in the game.

Yes.  It is small point but I couldn't bear to break the indentation.


> I think, based on the comments above, that much of your suggestions can be
> dealt with a way that won't break existing users: support a new :customize,
> provide an option for opting in to use general instead of bind-key, etc.
> 
> I also think we could provide a "front-end" to new keywords that does let
> people use defcustom to add new keywords, and those keywords would be injected
> into the existing system, say based on a position keyword specified in the
> defcustom. What do you think of that?

Good!  I'm interested in this plan and I want to work on it!


> Let's see what we can do! I'd almost always rather collaborate than compete.

Yes, absolutely!

Re: Include leaf in Emacs distribution

[Pankaj Jangid]

Naoya Yamashita <conao3@gmail.com> writes:

....

>> I think, based on the comments above, that much of your suggestions can be
>> dealt with a way that won't break existing users: support a new :customize,
>> provide an option for opting in to use general instead of bind-key, etc.
>> 
>> I also think we could provide a "front-end" to new keywords that does let
>> people use defcustom to add new keywords, and those keywords would be injected
>> into the existing system, say based on a position keyword specified in the
>> defcustom. What do you think of that?
>
> Good!  I'm interested in this plan and I want to work on it!
>
>
>> Let's see what we can do! I'd almost always rather collaborate than compete.
>
> Yes, absolutely!

I am following this since beginning for the thread. We are such good
people. Good to know about this convergence.

Re: Include leaf in Emacs distribution

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 6416 bytes --]

Naoya Yamashita <conao3@gmail.com> writes:

good point, at some point, it might be worthwhile doing a similar clean
up to built in packages; for example; I was appalled to see how many
things gnus pulls in, it even loads rmail -- though I've not used rmail
in 30 years.>> I chose this because in effect `(use-package foo)` is saying "I want to use
>> the package foo". What do you suggest for the default expansion?
>
> Yes, while `require` is the best way to load a package, packages
> are now automatically managed by package.el (and other package
> managers), and I think it is bad manners for users to explicitly
> `require` it.
>
> All functions that serve as entry points are properly managed by
> the autoload magic comment, and Emacs can reduce Emacs startup
> time by loading the package the first time it is needed.
>
> This is especially important when describing the configuration of
> Emacs' built-in packages in use-package/leaf.  When I was writing
> the configuration in use-package, I had to include the
> :no-require keyword in almost every use-package (because Emacs'
> package is well autoloaded).
>
> A use-package block with a :bind or :hook is not required, but
> this is implicit and inconvenient to be aware of at all times.
>
> In the leaf, it is simply `prog1` (or `progn`, but I use `prog1`
> to return the package name as the return value for the leaf; the
> return value for use-package varies from situation to situation
> and seems to be undocumented).
>
> I also like the :disabled and :when keywords.  I find it very
> useful to be able to enable/disable them as "chunks of settings"
> depending on the situation.  With that in mind, the first
> argument of use-package should not be required by default.  I'd
> like to put more free symbols in the first argument.
>
>
>> I'm not sure I understand, do you mean it's disabled even when set to nil?
>> This sounds like an easy bug to fix.
>
> Yes, this point is easy to fix.  I think `:disabled` keyword
> should interpret its argument.  It seems odd that conditional
> branching keywords such as :if interpret t and nil, but not
> :disabled.
>
> (below example shows :disabled in `use-package` is always
> "enabled" so every use-package expanded to nil.  But :disabled in
> leaf interpret its argument so 2nd example expanded empty prog1,
> but 3rd example "disabled" :disabled keyword)
>
> ```
> (setq leaf-expand-minimally t)
> ;;=> t
>
> (setq use-package-expand-minimally t)
> ;;=> t
>
> (list
>  (macroexpand-1
>   '(use-package ppp :disabled :ensure t))
>
>  (macroexpand-1
>   '(use-package ppp :disabled t :ensure t))
>
>  (macroexpand-1
>   '(use-package ppp :disabled nil :ensure t)))
> ;;=> (nil nil nil)
>
> (list
>  ;; :disabled should take argument, so this leaf is not valid
>  ;; (macroexpand-1
>  ;;  '(leaf ppp :disabled :ensure t))
>
>  (macroexpand-1
>   '(leaf ppp :disabled t :ensure t))
>
>  (macroexpand-1
>   '(leaf ppp :disabled nil :ensure t)))
> ;;=> ((prog1 'ppp)
> ;;    (prog1 'ppp (leaf-handler-package ppp ppp nil)))
> ```
>
>
>> :custom is a rather late addition, and I'm open to adding a new :customize
>> that uses dot pairs, while deprecating :custom.
>
> Good to hear it!
>
>
>> If there's a hook that doesn't end in -hook, you just use whatever that hook's
>> name is. `use-package` will look for a variable with that name, if no `-hook`
>> variant exists.
>
> We can't set a hook that isn't a -hook suffix.  leaf doesn't
> automatically rewrite a given symbol, and I think it's clearer
> and more convenient to do so.
>
> init.el is not only for me, it may also be illustrated in
> articles and books.  I don't know how beneficial it would be for
> users to be able to omit the -hook (it only 5 charactors!).  I
> think it confuses the beginning student. (I was.)
>
>
>> You can use any path in :load-path.
>
> I haven't known this spec before try it.  It's certainly done,
> but I think it's easier to understand if you separate the
> keywords.  (in leaf, :load-path don't modify its argument but
> load-path* interprets the specified argument to be a path
> relative to user-emacs-directory.)
>
> ```
> (list
>  (macroexpand-1
>   '(use-package ppp
>      :load-path "site-lisp/ppp"))
>
>  (macroexpand-1
>   '(use-package ppp
>      :load-path "/site-lisp/ppp")))
> ;;=> ((progn
> ;;      (eval-and-compile
> ;;        (add-to-list 'load-path "/home/conao/.emacs.d/site-lisp/ppp"))
> ;;      (require 'ppp nil nil))
> ;;
> ;;    (progn
> ;;      (eval-and-compile
> ;;        (add-to-list 'load-path "/site-lisp/ppp"))
> ;;      (require 'ppp nil nil)))
> ```
>
> BTW, how does the user specify if a he wants to specify a path
> relative to an arbitrary path?
>
> ```
> (macroexpand-1
>  '(use-package ppp
>     :load-path (expand-file-name "site-lisp/ppp" my-share-dir)))
> ;;=> Debugger entered--Lisp error: (void-variable expand-file-name)
> ;;     symbol-value(expand-file-name)
> ;;     eval((symbol-value 'expand-file-name))
> ;;     use-package-normalize-paths(":load-path" expand-file-name t)
> ```
>
>> I would like to move in the direction of deprecated :bind and allowing the
>> user to opt-in to general, perhaps making general the default at version 3.0.
>
> I'm interested in this point, but I cannot understand `general`...?
> Is that to add a new keyword called `general`?
>
>> I agree that local keymaps are not very well thought out, since they came late
>> in the game.
>
> Yes.  It is small point but I couldn't bear to break the indentation.
>
>
>> I think, based on the comments above, that much of your suggestions can be
>> dealt with a way that won't break existing users: support a new :customize,
>> provide an option for opting in to use general instead of bind-key, etc.
>> 
>> I also think we could provide a "front-end" to new keywords that does let
>> people use defcustom to add new keywords, and those keywords would be injected
>> into the existing system, say based on a position keyword specified in the
>> defcustom. What do you think of that?
>
> Good!  I'm interested in this plan and I want to work on it!
>
>
>> Let's see what we can do! I'd almost always rather collaborate than compete.
>
> Yes, absolutely!
>

-- 

Thanks,

--Raman
7©4 Id: kg:/m/0285kf1  •0Ü8