help-gnu-emacs
[Top][All Lists]
Advanced

[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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]