Split out terminfo

[Stebalien]

We might want to split the terminfo module out into its own crate.

[emberian]

That probably makes sense. Then, the term crate would be responsible only for the Terminal trait and such, right?

[Stebalien]

I was actually planning on splitting out the TermInfo struct but leaving the TerminfoTerminal code in term. I'm also planning on getting rid of the Terminal trait and doing the same thing as File in stdlib (that way we can get rid of the boxed term trait).

[emberian]

That sounds so much better. All these new(...ish) Rust patterns are much nicer than my naive bumblings ~two years ago.

[jimblandy]

I'm also planning on getting rid of the Terminal trait and doing the same thing as File in stdlib (that way we can get rid of the boxed term trait).

@Stebalien: I know it was a while ago that you wrote this comment, but:

Were you thinking about making term::stdout not choose between TerminfoTerminal and WinConsole dynamically? If I understand which aspect of File's implementation you're referring to, that just chooses one subdirectory at compile time to provide a definition for sys::fs::File. Or did you have a plan for retaining the dynamic behavior other than using a trait object?

[Stebalien]

On windows, we'd have to use an enum (as we can have both Terminfo terminals and WinConsole terminals). On linux, it would choose between terminfo and ANSI (when we can't find terminfo information but we know the terminal is an ANSI terminal). Unfortunately, my free time has dropped to 0 so this repo is now in "patches welcome" mode (I'll review patches but won't be doing much in terms of implementing new features).

[derekdreery]

I don't think there's anything wrong with a Terminal trait, especially when impl Trait lands in stable.

[jimblandy]

I believe a function that returns impl Trait has to return one specific type that implements that trait; it can't decide dynamically which of several such types to return. So it wouldn't help here.

[derekdreery]

I see, on windows.