suppress ansi output for all terminal commands when ansi terminal not available.

[bsutton]

We already have some code that suppresses ansi output when running on a none ansi device.

We need to review the terminal library to see if we can do further suppression so that the code 'mostly' works when on non-ansi devices.

With methods like write we could try to track row movements and if the row has moved since the last write then we add a newline before doing the next output.
The problem with this idea is that we would possible need to 'intercept' calls to print so we know when it has changed the row.

things to ponder.

[passsy]

Can't we trust stdin.supportsAnsiEscapes?

[bsutton]

It's known to be unreliable. I now have what appears to be a mostly reliable technique. Ansi.isSupported is the call users should make. This issue was about what happens if the user still makes ANSI calls even when we report that ANSI isn't working. My thought was that we try to output the text as cleanly as possible without any of the ANSI codes. This will have some odd results of they are outputting cursor positioning commands. The other options are we throw an exception or suppressed all output made via calls to Terminal but I'm not a fan of either of these options. Thoughts?

…

On Tue, 1 Jun 2021, 6:34 pm Pascal Welsch, ***@***.***> wrote: Can't we trust stdin.supportsAnsiEscapes? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#147 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAG32OHR35JTOZ2USL5YA4DTQSLQBANCNFSM45Z3FFEA> .

[passsy]

I don't like the idea of green(String) automatically detecting if ansi is supported and eventually apply the ansi color code. That could cause hard to detect bugs.
But dcli could offer alternative methods of doing just that. i.e. eventuallyGreen(String).

Similarly, ask could return the default value if stdin isn't available.

Another option could be a stdout filter, removing all ansi escape sequences. This could become a great interceptor api allowing filtering of different logging levels beyond --verbose.

[bsutton]

Have a read of #149

Methods like 'green(String)' are already suppressing colour output if ansi is not supported. If you look at $149 the improvements on whether ansi is supported have actually had what is (in my opinion) an undesirable outcome.

I'm not certain I'm keen on the idea of a stdout filter, i'm not even certain how we would implement it (may be a guarded zone).

I do like your idea for the ask function as the ask function is a problem in unit tests and having some mode that auto returns the default seems rather useful.