[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: req-package
From: |
Alexander Shukaev |
Subject: |
Re: req-package |
Date: |
Fri, 14 Aug 2015 16:40:16 +0200 |
>> 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?
- Re: req-package, (continued)
- Re: req-package, Stefan Monnier, 2015/08/11
- Re: req-package, Edward Knyshov, 2015/08/13
- Re: req-package, Alexander Shukaev, 2015/08/13
- Re: req-package, Edward Knyshov, 2015/08/13
- Re: req-package, Alexander Shukaev, 2015/08/13
- Re: req-package, Edward Knyshov, 2015/08/13
- Message not available
- Re: req-package, Stefan Monnier, 2015/08/13
- Re: req-package, Edward Knyshov, 2015/08/14
- Re: req-package, Edward Knyshov, 2015/08/14
- Message not available
- Re: req-package, Stefan Monnier, 2015/08/14
- Re: req-package,
Alexander Shukaev <=
- Re: req-package, Edward Knyshov, 2015/08/14
- Re: req-package, Alexander Shukaev, 2015/08/14
- Re: req-package, John Wiegley, 2015/08/15
- Re: req-package, Alexander Shukaev, 2015/08/15
- Re: req-package, John Wiegley, 2015/08/15
- Re: req-package, Les Harris, 2015/08/16
- Message not available
- Re: req-package, Rusi, 2015/08/16
- Re: req-package, Edward Knyshov, 2015/08/16
- Re: req-package, John Wiegley, 2015/08/17
- Message not available
- Re: req-package, Rusi, 2015/08/16