Re: req-package

[Edward Knyshov]

It's a good idea Alexander. It sounds good.
I'm not sure about pull requesting to use package, because its author
wanted to keep use package simple, last time I talked to him.
That's why req-package was created. But I will really consider adding this
improvement to req-package.
Could you, please, create an issue at http://github.com/edvorg/req-package ?

Edward.

On Fri, Aug 14, 2015 at 5:40 PM Alexander Shukaev <haroogan@gmail.com>
wrote:

> >> In this case you should remove dependency from evil config.
> >
> > But if you remove the ":require recentf" the code will still fail
> > since (evil-make-overriding-map recentf-dialog-mode-map 'motion) will
> > signal an error if recentf is not loaded.
>
> Exactly, and that's what I wanted to point out as design flaw, but I
> see one good solution which I believe could improve `req-package' even
> further.
>
> Why not do the following:
>
> (req-package evil
>   :config
>   ;; Here we configure only `evil' itself, e.g.:
>   (let ((keymap evil-emacs-state-map))
>     (setcdr keymap nil)
>     (define-key keymap (read-kbd-macro evil-toggle-key)
> #'evil-exit-emacs-state))
>   (setq-default evil-ex-commands nil)
>   (evil-ex-define-cmd "w[rite]" #'evil-write)
>   :config recentf
>   ;; Here we configure what is related to `recentf' (plus `evil' of
> course).
>   ;; It's kind of `:require recentf' (in a sense that it should also
> manage dependencies as
>   ;; `:require recentf' does), but it also includes corresponding
> configuration as well.  The benefit is
>   ;; that if `recentf' is not available, then this code is simply
> disabled/ignored (similar to how
>   ;; `with-eval-after-load' functions).  This is more general and
> flexible approach then `:require'.
>   (evil-make-overriding-map recentf-dialog-mode-map 'motion)
>   (evil-set-initial-state 'recentf-dialog-mode 'motion)
>   (evil-ex-define-cmd "rfm[enu]" #'recentf-open-files)
>   :config help
>   ;; Again the same concept as with `recentf'.
>   (let ((keymap evil-emacs-state-map))
>     (define-key keymap (kbd "C-?") #'help))
>   (evil-ex-define-cmd "h[elp]" #'help)
>   :config (my minibuffer)
>   ;; Again the same concept as with `recentf', but now two packages
> are prerequisites.
>   (my-add-hook 'minibuffer-setup-hook #'evil-insert-state))
>
> Furthermore, those `:config' forms should execute exactly in the order
> they appear in the code.  Why is it important?  Consider
> `(setq-default evil-ex-commands nil)', this erases all of the default
> Evil's ex-commands, then we add our own `(evil-ex-define-cmd "w[rite]"
> #'evil-write)'.  However, later on, if `recentf' is present, then
> `(evil-ex-define-cmd "rfm[enu]" #'recentf-open-files)' should run and
> it should definitely run after `(setq-default evil-ex-commands nil)'.
> By the way, the same applies to how `evil-emacs-state-map' is managed
> (first reset and then gradually repopulated).
>
> To conclude, I think the above approach is next-level evolution step
> for `req-package' and possibly can be pull-requested to `use-package'
> at some point.  Edward, do you see the potential here to extend
> `req-package' accordingly?
>