As mentioned in the title, the two functions
configuration-layer/package-used-p and cfgl-package-used-p have
inconsistent behavior with respect to certain packages.
In particular, if a package is disabled through a :toggle keyword
whose form evaluates to nil, configuration-layer/package-used-p will
return t for that package while cfgl-package-used-p will return
nil.
cfgl-package-used-p's behavior seems more correct to me---these
functions are used frequently in Spacemacs to figure out whether some
other layer is going to configure that package and cause it to, for
example, be responsible for implementing some key bindings. In which
case, the :toggle evaluating to nil should cause the code to assume
that the package in question is not used, for this purpose.
In any case, it seems like configuration-layer/package-used-p should
be a very thin wrapper around cfgl-package-used-p and not implement
any of its own logic. @smile13241324, do you agree with this idea?
As mentioned in the title, the two functions
configuration-layer/package-used-p
andcfgl-package-used-p
have inconsistent behavior with respect to certain packages.In particular, if a package is disabled through a
:toggle
keyword whose form evaluates to nil,configuration-layer/package-used-p
will return t for that package whilecfgl-package-used-p
will return nil.cfgl-package-used-p
's behavior seems more correct to me---these functions are used frequently in Spacemacs to figure out whether some other layer is going to configure that package and cause it to, for example, be responsible for implementing some key bindings. In which case, the:toggle
evaluating to nil should cause the code to assume that the package in question is not used, for this purpose.In any case, it seems like
configuration-layer/package-used-p
should be a very thin wrapper aroundcfgl-package-used-p
and not implement any of its own logic. @smile13241324, do you agree with this idea?