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!