cross-platform support + no-color-fallback

[colin-kiegel]

Not all terminals support ANSI escape characters (e.g. on windows).

It would be nice, if
(a) this would also work on windows
(b) color codes are surpressed when the current terminal does not support them

I would like to switch to the format of git diff --word-diff, which is also readable without colors

The quick [-red-]{+brown+} fox jumps over the lazy dog

This should be solved in the underlying difference crate, see johannhof/difference.rs#15.

Note: The discussion below got a little side-tracked... ^^

[fflorent]

FWIW, for PR #9, I checked how the output renders on Windows 10 (using cargo test).

It works pretty well (using a classic cmd window)

[colin-kiegel]

great, thanks for the info.

[fflorent]

Erf, bad news: https://superuser.com/a/1105718/134164

That's a new feature in Windows 10. Probably not supported in Windows 8 and 7, except if the user use compatible terminals.

[turboladen]

I dunno if this is the same issue or not but I'm on OSX (iTerm2) and the fancy arrows don't render for me (either?). I tried with a number of different fonts, to no avail; here's output from v0.3.2:

[colin-kiegel]

ok, thanks for the info. Could you check which of these render in your terminal?

$ echo "+ ⭬ ⭢ ⭲ ⮞ ⏵ ⯈ ▶"

PS: Is iTerm2 the standard OSX terminal? If not, what is the result in the standard terminal?

[fflorent]

@colin-kiegel same issue here.

$ echo "+ ⭬ ⭢ ⭲ ⮞ ⏵ ⯈ ▶"

the first and the last ones are the only ones to be well displayed on my terminal.

Florent

[turboladen]

Here's what I get:

PS: Is iTerm2 the standard terminal?

No, it's not, but I'd wager it's quite common for developers on OSX to use. Looks like the default Terminal app on OSX renders the same though:

[colin-kiegel]

ah, ok. Good to know.

It's probably safest if we stick to something like https://en.wikipedia.org/wiki/Windows_Glyph_List_4 or even < / >. We could still make those bold to make it more visible.

Just to know our alternatives better - could someone of you check again, which of these work?

$ echo "→➤⮞❱❯❭"

[turboladen]

Most of those work for me:

[fflorent]

Same here:

[colin-kiegel]

Ok, I'm asking a broader audience to double check the glyphs that worked for both of you
+ > → ❭ ❯ ❱ ▶ ➤

[turboladen]

Sweet! Thanks for being so responsive!

…

On Aug 31, 2017, at 2:46 PM, Colin Kiegel ***@***.***> wrote: Ok, I'm asking a broader audience <https://users.rust-lang.org/t/mega-assert-eq-with-colorful-diff-drop-in-replacement/10101/21> to double check the glyphs that worked for both of you + > → ❭ ❯ ❱ ▶ ➤ — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAIqukMCaGpY1LUmEOkC-m408_HRLnKGks5sdymsgaJpZM4MqMzl>.

[colin-kiegel]

I switched to ◀ / ▶ glyphs - fingers crossed. ;-)

[Marwes]

+ > → ❭ ❯ ❱ ▶ ➤ does not work well for me :/.

Windows 10 with Git Bash.

[turboladen]

iTerm2

Font: 12pt Fira Mono font

It renders for me, although if I'm picky, with my typical settings the spacing is kinda funky:

---

Terminal

Font: Menlo 11pt (default, IIRC)
All default settings

Looks better here although still slightly a little smushed...

---

For my part, it'd be nice if spacing was better, but if it was like this in the first place I probably wouldn't have bothered commenting.

[colin-kiegel]

@turboladen ok, it's plain < and > now. :-)

[turboladen]

Works for me! Thanks!

…

On Sep 2, 2017, at 3:56 AM, Colin Kiegel ***@***.***> wrote: @turboladen <https://github.com/turboladen> ok, it's plain < and > now. :-) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAIquvFKMZ2icYjZuqLEIaRC2k4ujBdXks5seTR3gaJpZM4MqMzl>.

[Michael-F-Bryan]

At work I have to work on a windows machine and every now and then I notice that the colouring is buggy on my terminal (Powershell). It looks almost like at the end of a coloured section it'll forget to revert back to the default colour, meaning from then onwards my terminal's text will be green or red.

I'd probably be better off reporting that to the colour library you use under the hood, just thought I'd let you know that colour support for non-unix can be a bit dodgy sometimes.

[colin-kiegel]

@Michael-F-Bryan: Thx. Can you still reproduce this? If so, please report a minimal example - ideally as an independent ticket, mentioning this one. :-)

[Screwtapello]

There's another situation where ANSI colours generally aren't available: when the compiler output is piped into an editor or IDE. Much like the Rust compiler's warnings are still useful when colour is disabled, it would be nice if this crate's output was just as useful without colour output.

Are you familiar with how Python's unit test framework formats failed assertions?

  Some(
      Foo {
-         lorem: "Hello World!",
?                         -
+         lorem: "Hello Wrold!",
?                        +
          ipsum: 42,
          dolor: Ok(
-             "hey"
+             "hey ho!"
?                 ++++
          )
      }
  )

Being familiar with classic diff -u output, I immediately recognised the leading - and + characters on the lines that differed, and once I'd figured that out, it was pretty obvious what the ? lines were pointing out. Colour would be an improvement, but it's still perfectly legible without.

[colin-kiegel]

closing in favour of a new ticket #31