Enable output colorization on Windows by default (#1051)

* Enable output colorization on Windows following after #1045

* doc updates

docs/src/miller-on-windows.md

@@ -38,8 +38,6 @@ To use Miller from within MSYS2/Cygwin, also make sure `mlr.exe` is within the `
 
 ## Differences
 
-[Output Colorization](output-colorization.md) doesn't work on Windows, outside of MSYS2.
-
 The Windows-support code within Miller makes effort to support Linux/Unix/MacOS-like command-line syntax including single-quoting of expressions for `mlr put` and `mlr filter` -- and in the examples above, this often works. However, there are still some cases where more complex expressions aren't successfully parsed from the Windows prompt, even though they are from MSYS2:
 
 ![pix/miller-windows-complex.png](pix/miller-windows-complex.png)

docs/src/miller-on-windows.md.in

@@ -22,8 +22,6 @@ To use Miller from within MSYS2/Cygwin, also make sure `mlr.exe` is within the `
 
 ## Differences
 
-[Output Colorization](output-colorization.md) doesn't work on Windows, outside of MSYS2.
-
 The Windows-support code within Miller makes effort to support Linux/Unix/MacOS-like command-line syntax including single-quoting of expressions for `mlr put` and `mlr filter` -- and in the examples above, this often works. However, there are still some cases where more complex expressions aren't successfully parsed from the Windows prompt, even though they are from MSYS2:
 
 ![pix/miller-windows-complex.png](pix/miller-windows-complex.png)

docs/src/output-colorization.md

@@ -43,8 +43,7 @@ described below:
 
 ## Mechanisms for colorization
 
-* Miller uses ANSI escape sequences only. This does not work on Windows except on Cygwin.
-* Requires `TERM` environment variable to be set to non-empty string.
+* Miller uses ANSI escape sequences only.
 * Doesn't try to check to see whether the terminal is capable of 256-color ANSI vs 16-color ANSI. Note that if colors are in the range 0..15 then 16-color ANSI escapes are used, so this is in the user's control.
 
 ## How you can control colorization
@@ -54,11 +53,13 @@ described below:
     * `export MLR_NO_COLOR=true` means Miller won't color even when it normally would.
     * `export MLR_ALWAYS_COLOR=true` means Miller will color even when it normally would not. For example, you might want to use this when piping `mlr` output to `less -r`.
     * Command-line flags `--no-color` or `-M`, `--always-color` or `-C`.
+    * On Windows, replace `export` with `set`
 
 * Color choices can be specified by using environment variables or command-line flags, with values 0..255:
 
     * `export MLR_KEY_COLOR=208`
     * `export MLR_VALUE_COLOR=33`
+    * On Windows, replace `export` with `set`
     * Likewise for `MLR_PASS_COLOR`, `MLR_FAIL_COLOR`, `MLR_HELP_COLOR`, `MLR_REPL_PS1_COLOR`, and `MLR_REPL_PS2_COLOR`.
     * Command-line flags `--key-color 208`, `--value-color 33`, etc., and likewise for `--pass-color`, `--fail-color`, `--repl-ps1-color`, `--repl-ps2-color`, and `--help-color`.
     * This is particularly useful if your terminal's background color clashes with current settings.

docs/src/output-colorization.md.in

@@ -27,8 +27,7 @@ described below:
 
 ## Mechanisms for colorization
 
-* Miller uses ANSI escape sequences only. This does not work on Windows except on Cygwin.
-* Requires `TERM` environment variable to be set to non-empty string.
+* Miller uses ANSI escape sequences only.
 * Doesn't try to check to see whether the terminal is capable of 256-color ANSI vs 16-color ANSI. Note that if colors are in the range 0..15 then 16-color ANSI escapes are used, so this is in the user's control.
 
 ## How you can control colorization
@@ -38,11 +37,13 @@ described below:
     * `export MLR_NO_COLOR=true` means Miller won't color even when it normally would.
     * `export MLR_ALWAYS_COLOR=true` means Miller will color even when it normally would not. For example, you might want to use this when piping `mlr` output to `less -r`.
     * Command-line flags `--no-color` or `-M`, `--always-color` or `-C`.
+    * On Windows, replace `export` with `set`
 
 * Color choices can be specified by using environment variables or command-line flags, with values 0..255:
 
     * `export MLR_KEY_COLOR=208`
     * `export MLR_VALUE_COLOR=33`
+    * On Windows, replace `export` with `set`
     * Likewise for `MLR_PASS_COLOR`, `MLR_FAIL_COLOR`, `MLR_HELP_COLOR`, `MLR_REPL_PS1_COLOR`, and `MLR_REPL_PS2_COLOR`.
     * Command-line flags `--key-color 208`, `--value-color 33`, etc., and likewise for `--pass-color`, `--fail-color`, `--repl-ps1-color`, `--repl-ps2-color`, and `--help-color`.
     * This is particularly useful if your terminal's background color clashes with current settings.

docs/src/reference-dsl-higher-order-functions.md

@@ -782,7 +782,7 @@ From other languages it's easy to accidentally write
 <b>mlr -n put 'end { print select([1,2,3,4,5], func (e) { e >= 3 })}'</b>
 </pre>
 <pre class="pre-non-highlight-in-pair">
-mlr: select: selector function returned non-boolean "(absent)".
+mlr: select: function returned non-boolean "(absent)".
 </pre>
 
 instead of

docs/src/reference-main-env-vars.md

@@ -19,6 +19,6 @@ Quick links:
 The following environment variables affect how Miller works:
 
 * `MLRRC`: see [Customization](customization.md).
-* `MLR_NO_COLOR`, `MLR_ALWAYS_COLOR`, `MLR_KEY_COLOR`, `MLR_VALUE_COLOR`, `MLR_PASS_COLOR`, `MLR_FAIL_COLOR`, `MLR_REPL_PS1_COLOR`, `MLR_REPL_PS2_COLOR`, `MLR_HELP_COLOR`, `TERM`, * `MSYSTEM`: see [Output Colorization](output-colorization.md).
+* `MLR_NO_COLOR`, `MLR_ALWAYS_COLOR`, `MLR_KEY_COLOR`, `MLR_VALUE_COLOR`, `MLR_PASS_COLOR`, `MLR_FAIL_COLOR`, `MLR_REPL_PS1_COLOR`, `MLR_REPL_PS2_COLOR`, `MLR_HELP_COLOR`: see [Output Colorization](output-colorization.md).
 * `MLR_REPL_PS1`, `MLR_REPL_PS2`: see [REPL](repl.md).
 

docs/src/reference-main-env-vars.md.in

@@ -3,6 +3,6 @@
 The following environment variables affect how Miller works:
 
 * `MLRRC`: see [Customization](customization.md).
-* `MLR_NO_COLOR`, `MLR_ALWAYS_COLOR`, `MLR_KEY_COLOR`, `MLR_VALUE_COLOR`, `MLR_PASS_COLOR`, `MLR_FAIL_COLOR`, `MLR_REPL_PS1_COLOR`, `MLR_REPL_PS2_COLOR`, `MLR_HELP_COLOR`, `TERM`, * `MSYSTEM`: see [Output Colorization](output-colorization.md).
+* `MLR_NO_COLOR`, `MLR_ALWAYS_COLOR`, `MLR_KEY_COLOR`, `MLR_VALUE_COLOR`, `MLR_PASS_COLOR`, `MLR_FAIL_COLOR`, `MLR_REPL_PS1_COLOR`, `MLR_REPL_PS2_COLOR`, `MLR_HELP_COLOR`: see [Output Colorization](output-colorization.md).
 * `MLR_REPL_PS1`, `MLR_REPL_PS2`: see [REPL](repl.md).
 

docs/src/reference-main-then-chaining.md

@@ -53,3 +53,5 @@ sys     0m1.259s
 There are two reasons to use then-chaining: one is for performance, although I don't expect this to be a win in all cases.  Using then-chaining avoids redundant string-parsing and string-formatting at each pipeline step: instead input records are parsed once, they are fed through each pipeline stage in memory, and then output records are formatted once.
 
 The other reason to use then-chaining is for simplicity: you don't have re-type formatting flags (e.g. `--csv --fs tab`) at every pipeline stage.
+
+As of Miller 6.3.0, `+` is an alias for `then`.

internal/pkg/colorizer/colorizer.go

@@ -247,10 +247,6 @@ func makeColorStringFromEnv(envName string) (string, bool) {
 }
 
 func getStdoutIsATTY() bool {
-	// Don't try ANSI color on Windows (except Cygwin)
-	if os.Getenv("TERM") == "" {
-		return false
-	}
 	if isatty.IsTerminal(os.Stdout.Fd()) {
 		return true
 	}

internal/pkg/platform/terminal_notwindows.go

@@ -1,8 +1,7 @@
-
 //go:build !windows
 // +build !windows
 
 package platform
 
 func EnableAnsiEscapeSequences() {
-}
+}

internal/pkg/platform/terminal_windows.go

@@ -1,4 +1,3 @@
-
 //go:build windows
 // +build windows
 
@@ -13,4 +12,4 @@ import (
 func EnableAnsiEscapeSequences() {
 	sequences.EnableVirtualTerminalProcessing(syscall.Stdout, true)
 	sequences.EnableVirtualTerminalProcessing(syscall.Stderr, true)
-}
+}