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
Looking at this again, and man this is a difficult problem.
I think the most elegant way to solve this (and also the most time-consuming) is to stop using lemonbar formatting tags internally (at least in string form). So instead of passing a large formatting string from the controller to the parser and renderer, we pass an array of formatting elements. This array is basically the formatting string represented using C++ data structures, so each element is either just plain text or describes a formatting tag.
Formatting tags are parsed when text is read from labels, formats, ramps, tokens, etc. From then on out we never deal with formatting tags as pure strings anymore.
I think that can solve this issue without breaking too many configs. The configs that will still break are the ones that literally write something like 97%%{O100} in one of their labels or as part of the script output. I think this is acceptable even without a major release.
I think this is something we should aim for.
However, I think it would be difficult to implement at the moment, because we would have to add the parsing code to every module individually (in all modules that use tokens).
We would first need to implement something like #1752, where we would generalize how a module produces output and have a single place where this happens.
Having such a data structure to represent tags would help us implement #531 and #1704 more easily.
The text was updated successfully, but these errors were encountered:
This is to make note of some major refactoring we may need to do in the future.
The main idea was already mentioned by Lomadriel in this comment:
and by me in this comment:
I think this is something we should aim for.
However, I think it would be difficult to implement at the moment, because we would have to add the parsing code to every module individually (in all modules that use tokens).
We would first need to implement something like #1752, where we would generalize how a module produces output and have a single place where this happens.
Having such a data structure to represent tags would help us implement #531 and #1704 more easily.
The text was updated successfully, but these errors were encountered: