-
Notifications
You must be signed in to change notification settings - Fork 35
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 color options, print support for windows #18
base: master
Are you sure you want to change the base?
Conversation
Appears travis is failing on nightly due to a dep or sub dep not being able to compile? |
Hi there, thanks for the contribution. Travis is failing because Clippy seems to be borked on the latest Nightly again, nothing to worry about. If it compiles again and we find that we missed some lint, we'll just push the fix afterwards. This looks good from a quick glance, but I'll get to reviewing later today. |
any updates here? Is it possible to restart the CI build? |
Hey, thanks again for the PR. Sorry for taking so long to get back to you. I have two concerns with this patch. I don't think we should introduce term as a dependency and I would like to avoid un-deprecating print_diff. IMO the library should focus on computing the difference and not pretty-printing the results. Maybe we should just make it really simple and do word_diff if |
Hm, I can understand the concern the concern about additional dependencies. Whithout knowing the details of this PR .. what if the additional dependency was behind some kind of feature flag? |
I'm not sure why consumers of this library can't just depend on |
In that case, this crate should simply print Having it produce silly result on Windows by default, or it produce different result based on platforms would hurt consumers of this crate in different ways. |
I can see that there are edge cases where you'd want the print output to be exactly the same across platforms, but would this really be such a big pain on consumers to implement their on printing code if they have such requirements? Maybe I'm just underestimating the use case for having consistent output on all platforms.
Considering that colorful output (only for some consumers unfortunately) has been the default for some time, would you consider an optional |
It may not be a big pain to implement that, but it may give downstream tools and their users false expectation if they don't check behavior on different platform carefully. For example, a developer on Windows may think this crate would reliably produce text-based diff, so that users can use commandline tools to consume its output, however it is not true on other platforms. This can happen vice versa. It would just make people confusing. I think
A reliable behavior should be the default, I think. Wouldn't it be fine to just implement the coloring in the commandline tool, but leave the lib part generate text result? Alternatively, you can probably add an optional default feature with term dependency to generate reliable colored result on all platforms, so that it keeps the original default behavior while still allows users to remove that dependency. |
This PR was made to address issues in -> #15
First rust contribution so I'll preface to say if things seem messed up/wrong let me know and I'll try my best to fix them!