unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Naoya Yamashita <conao3@gmail.com>
To: johnw@gnu.org
Cc: caiohcs0@gmail.com, emacs-devel@gnu.org, stefankangas@gmail.com,
	monnier@iro.umontreal.ca
Subject: Re: Include leaf in Emacs distribution
Date: Fri, 20 Nov 2020 20:04:23 +0900 (JST)	[thread overview]
Message-ID: <20201120.200423.2057312234973243191.conao3@gmail.com> (raw)
In-Reply-To: <m27dqk3jfv.fsf@newartisans.com>


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



  reply	other threads:[~2020-11-20 11:04 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-08  1:37 Include leaf in Emacs distribution Naoya Yamashita
2020-10-08  9:00 ` Ergus
2020-10-08  9:22   ` Naoya Yamashita
2020-10-10 10:11     ` Eli Zaretskii
2020-10-11  5:24       ` Richard Stallman
2020-10-11  8:39         ` Naoya Yamashita
2020-10-11  9:52           ` Thibaut Verron
2020-10-11 16:50             ` Naoya Yamashita
2020-10-11 17:12               ` Thibaut Verron
2020-10-12  2:10                 ` Naoya Yamashita
2020-10-12 20:23                   ` Ergus via Emacs development discussions.
2020-10-11 17:02           ` Stefan Kangas
2020-10-11 16:51   ` Stefan Kangas
2020-10-12 20:53     ` Mingde (Matthew) Zeng
2020-10-11 17:22 ` Stefan Kangas
2020-10-12  1:35   ` Naoya Yamashita
2020-10-12 22:13     ` Stefan Kangas
2020-10-12 22:19       ` Qiantan Hong
2020-10-12 22:39       ` Caio Henrique
2020-10-13 13:23         ` Stefan Monnier
2020-10-13 14:14           ` Thibaut Verron
2020-10-13 14:29             ` Stefan Monnier
2020-10-13 15:29               ` Thibaut Verron
2020-10-18  9:32                 ` Phil Sainty
2020-10-13 15:25           ` Caio Henrique
2020-10-23  2:37             ` Naoya Yamashita
2020-10-23  3:41               ` John Wiegley
2020-10-23 14:33                 ` Stefan Monnier
2020-10-23 15:53                   ` Naoya Yamashita
2020-10-23 16:46                     ` Warnings in init files (was: Include leaf in Emacs distribution) Stefan Monnier
2020-10-23 18:11                     ` Include leaf in Emacs distribution T.V Raman
2020-10-23 18:41               ` Stefan Kangas
2020-10-23 20:04                 ` John Wiegley
2020-11-16  5:29                   ` Naoya Yamashita
2020-11-17  0:39                     ` John Wiegley
2020-11-20 11:04                       ` Naoya Yamashita [this message]
2020-11-20 11:29                         ` Pankaj Jangid
2020-11-20 15:44                         ` T.V Raman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201120.200423.2057312234973243191.conao3@gmail.com \
    --to=conao3@gmail.com \
    --cc=caiohcs0@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=johnw@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=stefankangas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).