Attempt to switch from term
to termcolor
#41
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As discussed in slog-rs/slog#267 it appears that the
term
crate is unmaintained.This is a draft for switching to term color:
Advantages:
termcolor::Write
extendsstd::io::Write
(and has unified stderr/stdout times) so we don't have to use the nasty enumtermcolor
has no custom error type. It just usesstd::io::Error
In general this seems to clean things up significantly. However, it has the following caveats:
Disadvantages/Limitations:
termcolor
has no counterpart tosuports_bold
. We can't ask "do you support bold?". We can only ask "do you support colors?"Potential Alternatives:
I think it's good to think about potential alternatives. One alternative is updating to a more modern version of
term
(like term 0.7)Here are some other crates listed on the issue:
termcolor
(this PR) definitely seems to have less features thanterm
does.I think
crossterm
looks extremely promising.I don't think we should go with
yansi
because windows support seems second-class.