-
Notifications
You must be signed in to change notification settings - Fork 78
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
No-op non-windows enable_ansi_support function #30
Comments
I think it would be even better to have the library call the |
@H2CO3 Where in the library would this be located - and how would the library make it obvious it's doing a semi-expensive and environment affecting operation then? There'd have to be some sort of global Once to ensure that it doesn't happen twice, and locking to support that... Would you want this to happen inside the I think it makes sense to have some 'prep' code - it can be performed by whatever library or application plans on using color codes - most likely a logging library of one sort or another. |
@daboross I think it should not be in |
@H2CO3 Ah ok, that's reasonable. I'd still be a bit hesitant, since someone could be formatting to a string for later storage or printing from another program, but that'd be better than in |
@daboross I guess at this point it's really a matter of points of view :) In this particular case I would prefer the "magic" (ie. hiding the complexity) because it's not a particularly performance-sensitive issue. In other situations, I sometimes prefer being explicit too. In any case, it would be good to make the library platform-independent and, if a function has to be called sometimes, then provide an empty implementation for those OSes that don't need it. |
I'd prefer to have the no-op |
This is not implemented yet? |
I wanted |
+1 that |
Hi!
This looks like an awesome crate to use for colours. One question though: could a non-windows version of
enable_ansi_support
be added to the crate?Ideally I'd rather not have my CLI applications having any OS-specific code - it would be nice if I could just stick
ansi_term::enable_ansi_support()
at the top of mymain()
function, and know that it'll do whatever's needed for the current OS.It could just be literally
#[cfg(not(windows))] fn enable_ansi_support() -> Result<(), u64> { Ok(()) }
. If you'd be willing to add this, I can also submit a PR.The text was updated successfully, but these errors were encountered: