New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Substitute :require' with
:config' to separate dependency-related configurations
#18
Comments
What if we introduced |
That's also a possibility. I had a thought on the back of my mind that Also don't forget that |
Any more thoughts on this? I'm struggling to understand how I can reliably set up my init files to load combinations of packages and configure them in the right way, e.g.
|
Currently I just load some framework-like packages without deferring and then load other packages. It looks like this: (req-package cider
:require (key-chord guide-key)
:config
(key-chord-define-global "09" 'cider-jack-in-clojurescript)
(guide-key-related-config)) What we plan to do here is per dependency config sections like: (req-package key-chord
:defer t)
(req-package guide-key
:defer t)
(req-package cider
:config key-chord
(key-chord-define-global "09" 'cider-jack-in-clojurescript)
:config guide-key
(guide-key-related-config)) So all branches will behave independently |
Makes sense - looking forward to it! |
:require' with
:config' to separete dependency-related configurations:require' with
:config' to separate dependency-related configurations
(req-package banana)
(req-package cucumber)
(req-package mango
:require banana
:config (printf "%s" (+ mango banana)))
(req-package mango
:require cucumber
:config (printf "%s" (+ mango cucumber))) |
Do I understand correctly that
and
are equivalent? |
Correct. I just decided to go with first option, because it was easier in implementation and arguments parsing. |
I see. Thank you for the effort, good job! |
You're welcome!
2016年12月9日(金) 5:17 Alexander Shukaev <notifications@github.com>:
… I see. Thank you for the effort, good job!
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#18 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABbhyx4aL8TgmE2VIguy1D6NXJS0tHMKks5rGIH7gaJpZM4FrxiE>
.
|
A lot of it is just blind guess/trying and relying upon autoloading from other req-package calls, but everything seems to be loading now. Originally had tried to use the functionality documented in emacsorphanage/req-package#18 for more closely specifying each individual section but couldn't get this to work (e.g. it worked for the subword aspect but not for shm, etc.).
This issue is a follow-up to the req-package discussion. Currently, the
:require
keyword is too strict as it will forcereq-package
to fail if at least one package listed after the:require
keyword is not available. As a result, the whole configuration, even those parts which have nothing to do with the absent package, will inevitably fail, what makesreq-package
quite rigid. For instance:Now, if
recentf
is not available, then all of the code under the:config
keyword fails.The idea is to improve granularity and flexibility of control over dependency-related configurations by slightly extending the existing interface of the
:config
keyword in a natural way. Here is a fairly complex commented example to demonstrate the idea:By the way, those
:config ...
forms should execute exactly in the order they appear in thereq-package
macro. Why is it important? Consider(setq-default evil-ex-commands nil)
. It erases all of the default Evil ex-commands (set in theevil-maps
subpackage). After that, we add our own ex-command:(evil-ex-define-cmd "w[rite]" #'evil-write)
. However, later on, ifrecentf
is available, then(evil-ex-define-cmd "rfm[enu]" #'recentf-open-files)
should run and obviously we want it to definitely run after(setq-default evil-ex-commands nil)
. Note that the same concept applies to howevil-emacs-state-map
is managed (first reset and then gradually repopulated). Hence, the situation can occur quite often, and the deterministic control of dependency-related configurations execution order is vital.Please, note that the benefits (dependency tracking, automatic downloading, etc.) of the original
:require
keyword should still apply to the new:config ...
extension. However, it should definitely NOT do(require '...)
behind the scenes. Instead,:config ...
should behave similarly to the default:config
, which simply translates toeval-after-load
withoutrequire
-ing anything, and at the same time, it should still build the dependency 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 example), so that the default:config
from(req-package recentf ...)
is definitely executed BEFORE: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 whenrecentf
is truly loaded (by autoload, manually, or whatever) thanks toeval-after-load
behind:config
.Finally,
(req-package recentf ...)
on its own without:demand
(and that's the encouraged practice to avoid:demand
, which is the same as(require 'recentf)
) does not loadrecentf
; and therefore, does not have to be touched at all if one does not want to userecentf
anymore (i.e. one does not have to comment or erase it, but should rather only ensure thatrecentf
is not loaded anywhere).The text was updated successfully, but these errors were encountered: