-
Notifications
You must be signed in to change notification settings - Fork 47
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
Store custom ASCII-art in theme's toml file #255
Comments
Good idea :) I'm trying to think of a safe way to implement this. Can we assume that in the presence of a newline, that the "path" contains embedded art, and we may proceed with passing that string for rendering directly? EDIT: As long as |
Well an issue that could potentially arise, if escape characters are ever considered when parsing new lines and stuff, is that the ascii art string could potentially contain |
The way we store builtin ASCII art is through a vector of strings, see this as an example. I'm wondering if it is sufficient to split (the input ASCII art) by Is this what you mean?
A downside of this is that colors will not work, unless we add support for a user-friendly color templating engine, as I don't see myself getting behind the idea of allowing the use of the long and horrendous ANSI escape codes. Consider the following ASCII art for an example of such a templating engine:
I don't know of such an engine, but if you do, please let me know. If one doesn't exist, then I suggest the use of regular expressions. |
I don't know of any templaying function but I like the idea of
Using double brackets to avoid the possibility of it occuring within the ASCII art Regular expressions would definitely work with this.
This is what I'd be concerned about as |
I wrote a regular expression that handles this pretty well I think, at least for the couple test runs I made (with pen and paper). I'll post it tomorrow.
Agreed.
I agree to a certain extent, but I feel like this clutters up the templating syntax. I'd say that this becomes a question of probability, which I think is somewhat low. By the way, I truly appreciate your feedback. You've been very helpful. ❤️ |
I'm happy to see this program get developed :) I really like it and am using it as a replacement for neofetch for Powershell due to speed so I'm always happy to help |
In formal language theory, the regular expression would be:
let set = RegexSet::new(&[
r"(\{[rgbcmyBWn-]\})*",
r".*",
]).unwrap(); So for a given input of:
Our regular expression should have no problem validating it, but the regular The crate that implements this templating scheme should save the macchina would send the If you have any suggestions, I'd love to hear them. Colors:
Special characters:
|
I really like this however this does lose some functionality such as hexcode colours, is there a way to implement this? let set = RegexSet::new(&[
r"(\{[rgbcmyBWn-]\})*",
r"(\{#[0-9A-Fa-f]{6}\})*",
r".*",
]).unwrap(); This would catch all hexadecimal numbers, new-line tokens, reset tokens or predefined colour tokens. Could this possibly work? Edit: this would catch all of the characters stated above as well as: |
I don't see why it wouldn't work, we can definitely have this. I suppose the crate should expose as much functionality as possible. |
I'm struggling to make it work, but I'll keep you posted if I make any progress on this. If I take too long, I'm happy to accept a PR if you're up for the task. 👍 |
I'd give it a try for sure |
I'd expand the RegexSet to match for |
I discovered that
Note that both special characters and colors are optional, it's also more efficient if we combine the color and special character set, e.g.
That's one way to do it, I tried a similar but slightly different approach, i.e. extract the token, store as key, extract text, store as value. While documenting my approach, I've realized I've made a huge mistake in my code.
I appreciate you sharing your thought patterns, it will definitely help us document the steps we take to make this happen. |
I didn't realise this! Whilst parsing it with regex, we are essentially tokenizing it into
let ascii: Vec<&str> = vec![
" {b}_.-{r}=-._{w} .-,{n}"
" {g}.' {y} \"-.,'{#abcdef} / "
]
// then through some parsing this becomes
let coloured_ascii: Vec<Span> = vec![
Spans::from(vec![
Span::styled("_.-", *BLUE),
Span::styled("=-._", *RED),
Span::styled(" .-,", *WHITE),
]),
Spans::from(vec![
Span::styled(".' ", *GREEN),
Span::styled(" \"-..'", *YELLOW),
Span::styled(" /", Style::default().fg(Color::Rgb(0xab, 0xcd, 0xef))
])
] I'm not sure on how efficient this would be but it would work. In theory it would be O(n) where n is the length of the ASCII in characters as we will end up looping over each character twice at a minimum Edit: I'm not a rust expert so forgive me if my 'code' is slightly off x) |
Exactly.
This is the idea I was hoping to achieve.
Looking much better than ANSI already.
Yeah, the example you linked translates to the above snippet very well.
So O(2n)?
Code is perfect :) |
Yep and it allows for hexadecimal colours trivially which I like!
Yep it should be - I'm going to say around
Good to know! |
Currently, the only way I can see (in the docs) to use custom ascii art is through a path but could a multiline toml variable not be added that holds the ascii? Sort of like:
This way, the whole theme can be stored within the toml file.
It's also worth asking: could custom themes have multiple ASCII arts for different operating systems? I'd love to see a lot more flexibility with themes as long as it doesn't downgrade performance.
The text was updated successfully, but these errors were encountered: