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
Having to configure a block directly inside the main config file is fine when the block is never reused, but in scenarios where the same block configuration is reused in several config files one has to copy the same block definition for each usage, which results in duplication and makes updating the configs more annoying.
I suggest allowing the specification of a block in a separate toml file similar to how themes and icons are handled. One could then have a definition in the main config file like
Finding and parsing this file could be done like it is for themes and icons (search for a file if no predefined block with the specified name exists), using the existing util::find_file function, checking predefined locations (e.g. blocks instead of themes or icons), and util::deserialize_toml_file if a matching file is found.
The content of block_defined_in_separate_file.toml would then be the configuration of a single block, e.g.:
block = "focused_window"format = " $title |"
This alone would already be really useful (and I managed to implement an experimental version in a few lines despite being unfamiliar with the codebase). It would be even better if options specified at the point of inclusion of the separate config file would override the corresponding options in the separate file. This seems harder to implement, since it would probably require significant changes to how block parsing works.
One additional issue to consider is recursive block configuration. In my quick implementation recursion is supported (not supporting it would have been more effort), which I generally consider useful, but if the files are set up in a way which leads to infinite recursion, there is no logic for detecting that and failing safely yet.
The text was updated successfully, but these errors were encountered:
Having to configure a block directly inside the main config file is fine when the block is never reused, but in scenarios where the same block configuration is reused in several config files one has to copy the same block definition for each usage, which results in duplication and makes updating the configs more annoying.
I suggest allowing the specification of a block in a separate toml file similar to how themes and icons are handled. One could then have a definition in the main config file like
Finding and parsing this file could be done like it is for themes and icons (search for a file if no predefined block with the specified name exists), using the existing
util::find_file
function, checking predefined locations (e.g.blocks
instead ofthemes
oricons
), andutil::deserialize_toml_file
if a matching file is found.The content of
block_defined_in_separate_file.toml
would then be the configuration of a single block, e.g.:This alone would already be really useful (and I managed to implement an experimental version in a few lines despite being unfamiliar with the codebase). It would be even better if options specified at the point of inclusion of the separate config file would override the corresponding options in the separate file. This seems harder to implement, since it would probably require significant changes to how block parsing works.
One additional issue to consider is recursive block configuration. In my quick implementation recursion is supported (not supporting it would have been more effort), which I generally consider useful, but if the files are set up in a way which leads to infinite recursion, there is no logic for detecting that and failing safely yet.
The text was updated successfully, but these errors were encountered: