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
{{ message }}
This repository has been archived by the owner on Sep 20, 2023. It is now read-only.
Recently, I've been thinking of changing the format in which components are defined, which would obviously be a breaking change, though I plan to deprecate the current format first before removing it outright in order to give people a chance to switch.
Before, the component table had the left, mid and right tables inside of it and each of those tables had an 'active' table and an 'inactive' table inside of them. The new format would instead have the 'active' table and 'inactive' table directly inside the component table, with a variable amount of sections for the active and inactive statusline. So you're not limited to the 3 sections (left, mid and right) but instead can have 4 or even more sections. Another benefit is that it allows grouping active and inactive statusline elements together. Here's what it'd look like in code:
components= {
-- active statuslineactive= {
-- left section
{
-- first component
{
-- insert component code here
},
-- second component
{
-- insert component code here
}
},
-- mid section
{
-- insert code for section components here-- similarly to what was shown above in the code for the left section
},
-- right section
{
-- insert code for section components here-- similarly to what was shown above in the code for the left section
}
},
-- inactive statuslineinactive= {
-- insert sections and section components here-- similarly to what was shown above in the code for the active statusline
}
}
I feel like this change to the component table layout will make configuration simpler and more organized, while also adding flexibility. But I'm not 100% sure if I should implement it yet since this is going to be a breaking change. So I'd like other opinions on it if possible.
The text was updated successfully, but these errors were encountered:
I prefer this over the old system. However, I think you should, for a time(a month or 2 IMO), support both syntaxes to allow people to switch over their configs to the new system. And even then, maybe branch off the old config system into a old-syntax branch or something like that to allow people to keep using it, even if it's unsupported. I think that this would be a good change, as the syntax seems a lot simpler than the old system. So +1 from me on this.
However, I think you should, for a time(a month or 2 IMO), support both syntaxes to allow people to switch over their configs to the new system.
I do plan to do that
And even then, maybe branch off the old config system into a old-syntax branch or something like that to allow people to keep using it, even if it's unsupported.
Recently, I've been thinking of changing the format in which components are defined, which would obviously be a breaking change, though I plan to deprecate the current format first before removing it outright in order to give people a chance to switch.
Before, the component table had the left, mid and right tables inside of it and each of those tables had an 'active' table and an 'inactive' table inside of them. The new format would instead have the 'active' table and 'inactive' table directly inside the component table, with a variable amount of sections for the active and inactive statusline. So you're not limited to the 3 sections (left, mid and right) but instead can have 4 or even more sections. Another benefit is that it allows grouping active and inactive statusline elements together. Here's what it'd look like in code:
I feel like this change to the component table layout will make configuration simpler and more organized, while also adding flexibility. But I'm not 100% sure if I should implement it yet since this is going to be a breaking change. So I'd like other opinions on it if possible.
The text was updated successfully, but these errors were encountered: