Re: req-package

[Alexander Shukaev]

>>   :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'.
>
> I think this should not try to require recentf.  IOW it should only
> execute that code if/when recentf if enabled.  So you can still disable
> all of recentf by commenting out the (req-package recentf).

True.  It should behave similarly to the default `:config' which
simply translates to `eval-after-load' without `require'-ing anything.
BUT it should still build the graph in the similar way as `:require'
does in order to force evaluation of `(req-package recentf ...)'
BEFORE the current one (`(req-package evil ...)' in this case), so
that the default `:config' from `(req-package recentf ...)' is
definitely executed BEFORE the `:config recentf' from `(req-package
evil ...)'.  Note that the code under either default `:config' from
`(req-package recentf ...)' or from `:config recentf' from
`(req-package evil ...)' will really execute only when `recentf' is
really loaded (by autoload, manually, or whatever) thanks to
`eval-after-load' behind `:config'.  By the way, `(req-package recentf
...)' on its own without `:demand' (and that's the encouraged practice
to avoid `:demand', which is really `(require 'recentf)') does not
load `recentf'; and therefore, does not have to be touched at all even
if one does not want to use `recentf' anymore (i.e. you don't have to
comment it).