Can config.theme.features be inherited?

[feasgal]

This comment (admittedly an older one), seems to indicate that MkDocs configuration inheritance can be used for theme features. But I'm having a problem with the 'alternative syntax' that inheritance requires.

Specifically, when I change the syntax of all the config.theme.features from list to key:value pairs (e.g., change - announce.dismiss to announce.dismiss: {} etc.), a bunch of the features stop working at all. For example, content.code.copy, content.code.select, navigation.tracking, and navigation.top are among those that stop working, but navigation.tabs, navigation.tabs.sticky, navigation.footer, navigation.path, navigation.sections, all still work.

Mysteriously (to me), the left-hand nav draws on top of the footer and no longer has a scroll wheel, and while the search field is still present in the header, nothing happens when I type text in it.

I feel like I'm missing something here. Or are the config.theme.features required to be in list syntax and therefore cannot work with config inheritance?

Thanks in advance for any help.

[squidfunk]

Thanks for asking. Short answer: no.

First of all, configuration inheritance is implemented by MkDocs (using the INHERIT keyword). Although the plugins settings support a dictionary syntax and a list syntax, it doesn't mean that this is generally supported for all collections. It's specifically implemented for the plugins setting, and has a major downside: you can only use one instance of a plugin.

If you use INHERIT, the configuration is merged using mergedeep. mergedeep allows for several merge strategies. MkDocs uses the default, which is REPLACE and probably the safest solution, which replaces all keys and lists. ADDITIVE would merge list items, which might lead to unexpected behavior. You can only specify a global strategy and MkDocs decided to go for REPLACE.

We'll be evaluating how to share configuration as part of the projects plugin that we're currently developing.