You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
As mentioned in the title, the two functions
configuration-layer/package-used-p
andcfgl-package-used-p
haveinconsistent behavior with respect to certain packages.
In particular, if a package is disabled through a
:toggle
keywordwhose form evaluates to nil,
configuration-layer/package-used-p
willreturn t for that package while
cfgl-package-used-p
will returnnil.
cfgl-package-used-p
's behavior seems more correct to me---thesefunctions 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 assumethat the package in question is not used, for this purpose.
In any case, it seems like
configuration-layer/package-used-p
shouldbe a very thin wrapper around
cfgl-package-used-p
and not implementany of its own logic. @smile13241324, do you agree with this idea?
The text was updated successfully, but these errors were encountered: