Elm-format: It would be cool to have a --no-color option.

[stoivo]

It would be cool to have a --no-color option.

Useful when you want to parse the output.

[stil4m]

Why would you want to parse the output?

elm-format --validate SOME_PATH

will output JSON. Maybe this is already what you want

[stoivo]

I want to show the output in this PR https://github.com/elm-community/Elm.tmLanguage/pull/25
Now I am replacing it like errors = re.sub('\x1b\[\d{1,2}m', '', errors.strip().

[sentience]

Yes, in editor integrations the ideal would be to run a single command to format, but to receive parseable errors when formatting fails. Perhaps elm-format --report JSON to match elm-make?

[avh4]

Unfortunately elm-format doesn't have very good error handling, and the error messages have diverged farther from elm-make in the next version of Elm.

I believe the ideal thing to do is if elm-format fails, run elm-make and show the syntax errors from elm-make. Would that be workable for editor plugins?

[frou]

Regarding ANSI colouring, rather than a command-line flag to disable it, it's common for isatty(...) to be used to test whether stdout and/or stderr are writing to a terminal. If false (i.e. they're writing to a pipe or file on disk), then colouring should be disabled automatically.

[lassik]

Yes. Would be very nice if elm-format used color only when stderr is a tty :)

There already seems to be a plain renderer in Report.hs

[avh4]

lassik, can you give more details about your use case? Is it the same as stoivo's case of wanting to parse the error messages to display in an IDE?

[lassik]

Thanks for the quick response :) It's for an Emacs command to auto-format code. I don't need to parse the error messages - showing them verbatim is fine.

I added a regexp to remove the ANSI codes like @stoivo but having tty/no-tty adaptive behavior in elm-format would be the standard Unix solution to address a situation like this. Lots of commands have it, e.g. try ls vs ls | cat or git log vs git log | cat

[lassik]

Hello again :) May I inquire about the current status of this issue? We are just working on adding elm-format to Unibeautify and non-ANSI plain text output would be needed there as well (otherwise we'll also use an ad hoc regexp to remove ANSI).

[avh4]

This is low-priority for me, but I guess a PR would be welcome. I think I would want --no-color to be a hidden option for now (not printed in the default help output).

However, I thought elm-compiler had decided not to add a no-color option, so I'm not sure I understand the value of this if plugins will still have to handle elm-compiler's output?

[lassik]

Once again, thanks for the quick response! I respect that you have a lot on your plate.

Does elm-format call elm-compiler internally? If elm-format is standalone, then we don't need to call the compiler for mere formatting. (Formatting is often done by a different plugin than compiling, as it is in our case. If elm-compiler doesn't have a no-color option then you're right that the same problem would indeed manifest itself when doing editor integration for the compiler, but fortunately we are only making formatters so we don't need to handle that duty :)

The value is simply to have the output appear legible in places that don't handle ANSI color (editor windows, log files, pipes, etc... very few places can actually handle ANSI without extra effort). Few other formatters use ANSI color, and the ones that do disable it when output is not to a terminal. At a glance, elm-compiler seems to have at least some option to turn off colors.

The no-color thing usually doesn't need its own command line option. Instead, programs call isatty() to check whether the output is going to a terminal (enable color) or a file/pipe (disable color). In Haskell, this seems to be done via queryTerminal in System.Posix.Terminal. Would it be possible to do this by using queryTerminal to choose between the plain renderer and the ansi renderer?

If it's not trivial I can try to do a PR, but I have little experience with Haskell projects.