How to fall back on std::io::stderr() if term::stderr() fails?

[matthiasbeyer]

Is there a way to fall back to plain std::io::stderr() when term::stderr() fails building the terminal object?

If not, then this is a feature request.

[Stebalien]

Not currently but I'd like to provide this functionality eventually. However, I don't want to just "not color". Instead, I'd like to provide a tiered API where the user can construct a low level terminal directly if they need fine control or a higher level "colored output" object if they just want "smart coloring".

[matthiasbeyer]

This is a blocker for some of my things. I would really like to have the option "Either term::stderr() or std::io::stderr() if the former fails" - even if this means without color - no problem for me!

[Stebalien]

You can do what rust and cargo do for now.

On February 24, 2016 8:34:54 AM EST, Matthias Beyer notifications@github.com wrote:

This is a blocker for some of my things. I would really like to have the option "Either term::stderr() or std::io::stderr() if the former fails" - even if this means without color - no problem for me!

---

Reply to this email directly or view it on GitHub: https://github.com/Stebalien/term/issues/57#issuecomment-188257290

Steven Allen

[matthiasbeyer]

What do they do?

[Stebalien]

They have enums that abstract over Stdout and a Terminal. That is, something like:

enum Output {
    Terminal(StdoutTerminal),
    Stdout(Stdout),
}
impl Output {
    fn new() -> Output {
        if let Ok(term) = term::stdout() {
            if term.supports_color() {
                return Output::Terminal(term);
            }
        }
        return Output::Stdout(std::io::stdout());
    }
    fn print_error(&mut self, msg: &str) -> io::Result<()> {
        match *self {
            Terminal(ref term) => { /* ... */ },
            Stdout(ref out) => { /* ... */ },
        }
    }
}

This is obviously not a very good solution (which is why I'm leaving this issue open).

[matthiasbeyer]

Any progress here?

---

Edit: I ask because I need support for this in https://github.com/matthiasbeyer/imag/pull/212 and https://github.com/matthiasbeyer/imag/pull/213

[Stebalien]

Sorry, I'm kind of swamped with school work at the moment (trying to finish a masters thesis) and doing this right is non-trivial. Basically, I've been re-writing term to,

1. Have a global interface (configured globally) like std::io's stdout. No more passing around a Terminal object. IMO, this is almost always what users want.
2. Never color the wrong text. This is currently a big problem on Windows and a lesser problem on unix.
3. Reduce the number of places where things can go wrong. Currently, we can know that something won't work up-front but don't report this to the user till they try to use the feature.
4. Proper, reliable buffering. Line, full (print on flush), and no buffering.
5. Pluggable and configurable. Users need to be able to drop in their own terminal endpoints. This is especially useful for testing.
6. Just do the right thing. (this is the feature you're looking for).

Unfortunately, it took me a while to realize that a global interface was the right one so I still have quite a bit of work to do.

[matthiasbeyer]

Sorry, I'm kind of swamped with school work at the moment (trying to finish a masters thesis)

Hey, no problem! :smile: I can fully understand that, I'm working on my bachelors thesis at the moment.

Have a global interface [...] IMO, this is almost always what users want.

Sounds good, yes. The other points sound good as well.

---

I just wanted to ping you whether you are still working on this or whether this is abandoned. Awesome to hear/read that you want progress as well! Thank you a lot! I didn't want to annoy or push you, just a simple "anyone alive here"-ping :+1: