Closed Zuchos closed 7 years ago
One more thing: Wouldn't things like \u001B[31m
be displayed literally in, for example, Jenkins logs? It would make compilation errors actually harder to read :) Maybe this whole feature should be configurable by env variable, sth like running sbt -Dclippy.colors=false test
in CI.
It would be nice if it detected automatically if colors should be displayed, or if they were opt-in like they are with the scala 2.12 repl. I agree that escape characters in ci logs would not be wanted and opt-out doesn't feel like the right default there. I know the scalac devs have been kicking around ideas to determine if they should enable colors automatically. Maybe you could detect if you are running in an interactive shell?
I believe the escape codes also mess up emacs shell output. I am not an emacs user myself but a couple of devs at my company who use clippy are and I would hate to mess up my messages for them.
@ShaneDelmore @Zuchos maybe coloring should be disabled by default, when enabling would require adding sth like
com.softwaremill.clippy.ClippySettings
clippyColors := true
wdyt?
@Zuchos Worth checking: https://github.com/lihaoyi/fansi, a "library for dealing with fancy colored Ansi strings easily, safely and efficiently". I'm thinking of using it here for coloring code in all errors, which will be a separate PR after you complete this one.
Or probably I'm going to need this :) http://www.lihaoyi.com/upickle-pprint/pprint/
@Zuchos @adamw @ShaneDelmore I added some updates to this PR. Now colors are disabled by default and can be enabled by adding scalacOptions += "-P:clippy:colors=true"
compiler flag (can be set globally in ~/.sbt/0.13/clippy.sbt
).
@adamw README and use page updated.
0.3.5 released
When no advice was applied to TypeMissmatchError clippy will make a console friendly diff on found and required types.