Structure for the refactorization of the plugin

[datwaft]

I have been thinking for a while about what would be the best way to structure the plugin, I even have some demos that work but are not exactly what I am looking for.

This structure is based on two very important concepts:

• There must be a way to configure the plugin with a snapshot of the current state.
• There must be a way to generate the statusline based on the configured state.

The first one is because of perfomance. If all the heavy operations happen at only one moment at the very beginning, the performance would become a lot better. The problem with this is if for example the configuration changes, and you want to use this new state, the you would need to again run the configuration function. This can be do automatically with autocommands, so there is not much problem.

The second one is a derivation of the first concept, the configured state and only that status must be used at any point in time to generate the statusline. If there is no configured state at any point in time the statusline must have some way to reflect this to the user.

Based on these concepts, the following steps must be followed when initializing the plugin:

1. Extracting the user configuration
2. Merging the user configuration with the default values
3. Getting all highlight groups that will be used by the statusline.
4. Define those highlight groups.
5. Define all content functions (global functions used by the plugin to render the content of a component).
6. Define all autocommands used by the statusline.

After that a global function that generates the statusline based on that configuration must be declared and used by the plugin.

An example:

vim.opt.statusline = "%!v:lua.__bubbly.render_statusline()"

About the user configuration, it would be ideal to maintain compatiblity with the current way of configurating the plugin, but there must also be ways to configure it in more idiomatic and less problematic ways.