No-op non-windows enable_ansi_support function about rust-ansi-term HOT 9 OPEN

I'd prefer to have the no-op enable_ansi_support function and call that at startup; calling it implicitly from fmt seems entirely too magic, and as @daboross noted, you might not be writing to the console.

from rust-ansi-term.

I think it would be even better to have the library call the enable_ansi_support() function automagically if it's on Windows. That way there's no separate initialization code that the developer should remember to call and that can, consequently, get out of sync / forgotten / etc, and the "enabling" process is completely hidden from the user of the library, shrinking the API surface and decreasing complexity.

from rust-ansi-term.

@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 paint method, which is otherwise very cheap - literally just a stack value construction?

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.

from rust-ansi-term.

@daboross I think it should not be in paint. After all, that method doesn't actually do anything. It should be in a place of which the performance is comparable to the performance of locking. It could be in the <ANSIString as Display>::fmt() method itself, for example.

from rust-ansi-term.

@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 paint. It seems a bit 'magic' still.

from rust-ansi-term.

@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.

from rust-ansi-term.

This is not implemented yet?

from rust-ansi-term.

I wanted enable_ansi_support without the rest of ansi_term, so I've included the no-op function and published it as a separate crate (repository).

from rust-ansi-term.

+1 that enable_ansi_support should be a no-op on any OS that is not windows.

from rust-ansi-term.