Skip to content
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

Allow using block definitions from separate files #2098

Open
danielrainer opened this issue Nov 7, 2024 · 0 comments
Open

Allow using block definitions from separate files #2098

danielrainer opened this issue Nov 7, 2024 · 0 comments

Comments

@danielrainer
Copy link
Contributor

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

[[block]]
block = "block_defined_in_separate_file.toml"

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant