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

Parse formatting tags directly in user input and process data structures from there on. #2106

Open
patrick96 opened this issue May 16, 2020 · 0 comments
Labels
Epic refactor Issues about refactoring code or polybar concepts

Comments

@patrick96
Copy link
Member

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:

It might be a good idea to store the output string in a more structured way and could greatly simplify the manipulation of these strings.

and by me in this comment:

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.

@patrick96 patrick96 added refactor Issues about refactoring code or polybar concepts Epic labels May 16, 2020
@patrick96 patrick96 mentioned this issue Dec 15, 2020
12 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Epic refactor Issues about refactoring code or polybar concepts
Projects
None yet
Development

No branches or pull requests

1 participant