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

Inlined colors #150

Open
eugenesvk opened this issue Jul 30, 2023 · 2 comments
Open

Inlined colors #150

eugenesvk opened this issue Jul 30, 2023 · 2 comments

Comments

@eugenesvk
Copy link

Would it be possible to support a more dense inline style of coloring similar to this python function
print_color("Command {c.b}{name}{c.d} {c.r}not found{c.d}")
where c.b would be blue and c.d would reset to default, ideally with customizable styles so you could have c.bb for blue bold instead of having to do {}, name.blue().bold();

@hwittenborn
Copy link
Member

hwittenborn commented Aug 1, 2023

I don't think this a bad idea. The approach I'd like to do is having a module with macros mapping to format!(), println!(), and all of those that are in the stdlib. Then you'd be able to do things like this (it wouldn't have to be exactly like this though):

use colored::inline;

// This could also be `colored::println!`, as an example for other options.
inline::println!("Command {c.b}{name}{c.d} {c.r}not found{c.d}");

By making it a macro it could still check at compile time that everything is correctly implemented, and since the stdlib formatting macros don't support . syntax the macros could also allow normal formatting syntax, and only check for the custom specified colors.

What do you think?

@eugenesvk
Copy link
Author

eugenesvk commented Aug 1, 2023

// This could also be colored::println!, as an example for other options.

I like colored::println! better than the inline::println!, though would alias such a frequently used function to use colored::println as pc; similar to use std::println as p;

inline::println!("Command {c.b}{name}{c.d} {c.r}not found{c.d}");

Regarding the main syntax, the c.b notation comes from me stuffing color abbreviation as class properties, but since this would be a custom macro, it's much more flexible and can be made not to interfere with the default {} variable expansion of println!, correct?

Is it flexible enough to have

  • user-defined prefix/suffix

in some first initialization call to the macro (or a global var or something? procedural macros should have access to this?)?
For example, ideally I'd like to have very visually light markers like (not suitable for the library's defaults as people don't have easy access to such symbol set up)

‹b›blue ‹r›red ‹×›style reset ‹_r›no fg, red background
‹r_b›red fg default bg bold

  • user-defined color abbreviations

‹zy›user-defined fg + bg

  • composable colors

like ‹fg bg styles› (‹1 1 1; 255 255 255; b› for rgb foreground/background and bold for style) for inline color values instead of being a predefined set of c.b properties?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants