Re: Include leaf in Emacs distribution

[T.V Raman]

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