Naoya Yamashita 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 ♈ Id: kg:/m/0285kf1 🦮