Provide an option for Pastel to disable color (methods would be no-ops).
keithrbennett opened this issue · 3 comments
(I have not yet started working with this gem, so I apologize in advance if this feature already exists.)
Colored output is very helpful when output to a terminal, but when output to a block device (e.g. by redirecting stdout on the command line to a file), it can be a big problem. It would be great if Pastel instances had enabled and enabled= methods, or some other way to enable and disable production of the ANSI escape (color) sequences. Then, the developer could test the stream to see what kind of device it is, and set the enabled attribute accordingly, e.g.
pastel.enabled = $stdout.tty?For cases where you would want to disable ANSI sequences in files (always, in my opinion), this would eliminate the need to do the test everywhere a pastel method is called.
This would also enable use of the same code using Pastel calls for building console messages and log messages, with two separate Pastel instances with different enabled settings.
Hi Keith, thanks for giving the library a consideration!
As things stand pastel automatically detects the ability to color strings relying on tty-color dependency. In there you will find that it automatically detects device as printable - see. However, if you are not satisfied with the auto detection, then you can enforce your own rules by specifying the enabled option - see. Do you think this is enough for your use case?
I would appreciate help with documentation because people asked about it before and I am not sure if this feature is well described. Thoughts?
Yes, that's perfect.
The tty-color test doesn't help me because I need to disable color even if the terminal supports color, but when output is redirected; but it turns out I can disable redirection in the way that is most intuitive (thank you!). I've issued a pull request for some text in the readme explaining this. I think it's important and useful enough to warrant mention in the usage section; that text points to the enabled section for the detail.
By the way, was the inclusion of the .ruby_version file in the repo intentional?
Yes it was intentional, but thank you for pointing it out that contributors may not necessarily appreciate to be forced to use a particular ruby version.