Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Re #4091: Pre-Windows 10, default --color=never #4106

Merged
merged 1 commit into from
Jun 24, 2018

Conversation

mpilgrem
Copy link
Member

Implements --color=never as default on Windows before Windows 10, if emulation would be required to support ANSI colour codes.

Also bumps the lts-11 resolver in stack.yaml to lts-11.14, in order to benefit from ansi-terminal-0.8.0.4.

defaultColorWhen, exported by new module Stack.DefaultColorWhen, establishes the default. That module differs, pending on whether the operating system is Windows or non-Windows (see the conditional in package.yaml).

globalOptsFromMonoid in module Stack.Options.GlobalParser is modified so that the default is an argument rather than a given.

A beneficial side-effect of defaultColorWhen on Windows is that it enables ANSI on ANSI-capable native terminals. This allows some existing code in module Main to be removed.

Note: Documentation fixes for https://docs.haskellstack.org/en/stable/ should target the "stable" branch, not master.

Tested on Windows 10 and some limited testing on Windows 7.

Please include the following checklist in your PR:

  • Any changes that could be relevant to users have been recorded in the ChangeLog.md
  • The documentation has been updated, if necessary.

Please also shortly describe how you tested your change. Bonus points for added tests!

@dbaynard
Copy link
Contributor

From a first glance, this looks great. Thank you! It should be fairly quick to review — I'm just searching for a windows reviewer.

I suspect we may be better off adding ansi-terminal as an extra-dep, rather than bumping the resolver version, but that'd be a fairly straightforward change.

Copy link
Contributor

@snoyberg snoyberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the fix here. I've reviewed the code and added some comments, but I haven't been able to test it on a Windows machine.

if h == iNVALID_HANDLE_VALUE || h == nullHANDLE
then return ColorNever -- Invalid handle or no handle
else do
tryMode <- try (getConsoleMode h) :: IO (Either SomeException DWORD)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd recommend using tryAny here: it will make the type signature unnecessary, and be more explicit about using a function that doesn't catch async exceptions.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or did you mean to catch only a ConsoleException from below?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've now moved away from duplicating ansi-terminal's use of the exception mechanism for this small extract.

then return ColorAuto -- VT processing already enabled
else do
let mode' = mode .|. eNABLE_VIRTUAL_TERMINAL_PROCESSING
trySetMode <- try (setConsoleMode h mode') :: IO (Either SomeException ())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As above.

throwIfFalse action = do
succeeded <- action
if not succeeded
then getLastError >>= throw . ConsoleException
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please use throwIO instead of throw. The former is resistant to later refactorings that would cause a bottom value to hide inside something lazy.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As above.

stack.yaml Outdated
@@ -1,4 +1,4 @@
resolver: lts-11.6
resolver: lts-11.14
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it strictly necessary to bump the LTS version here? I tend to avoid such updates in unrelated patches.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now use an extra-dep instead. (ansi-terminal-0.8.0.4 brings the mintty fix to its hSupportsANSI.)

@mpilgrem
Copy link
Member Author

Before turning to the results of the review, an update on testing: I have tested on Windows 7 and 10, both in a native terminal and in a mintty terminal (Cygwin) (the test being stack new test; introduce a small bug in the code; stack build, with bug reporting). It works as expected (ie no colour code corruption of output in a Windows 7 native terminal; colour in all other circumstances).

Implements `--color=never` as default on Windows before Windows 10, if emulation would be required to support ANSI colour codes.

Also updates `stack.yaml`, in order to benefit from `ansi-terminal-0.8.0.4`.

`defaultColorWhen`, exported by new module `Stack.DefaultColorWhen`, establshes the default. That module differs, pending on whether the operating system is Windows or non-Windows (see the conditional in `package.yaml`).

`globalOptsFromMonoid` in module `Stack.Options.GlobalParser` is modified so that the default is an argument rather than a given.

A beneficial side-effect of `defaultColorWhen` on Windows is that it enables ANSI on ANSI-capable native terminals. This allows some existing code in module `Main` to be removed.
@mpilgrem
Copy link
Member Author

I think my further changes are responsive to all the requested changes.

Copy link
Contributor

@snoyberg snoyberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants