[m-rev.] for review: Conditionally enable color diagnostics by default.

[Peter Wang]

On Tue, 25 Jun 2024 15:50:13 +1000 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> On 2024-06-25 11:22 +10:00 AEST, "Peter Wang" <novalazy at gmail.com> wrote:
> > Do we need config_default_color_diagnostics?
> 
> Julien's original email about this has the reason for them.
> 

All right. I generally dislike when packagers fiddle with defaults.

> > mmake always redirects output to .err files; by default the .err files
> > will contain uncolored output. If you want colored output in those files,
> > you will need to explicitly ask for it. I think this is fine, but maybe
> > there are differing opinions.
> 
> Given than your diff, in its current form, will turn colors OFF by default
> for anyone using mmake, you bet my opinion is different. How does it look
> when one day you announce "color are enabled by default", and then
> a day or two later silently switch them off by default for a subset of our users?
> 

There are other options.

- mmake could test for a tty when it is first invoked, and pass that
  information down to mmc.

- mmc could skip the tty check if it is invoked by mmake (by checking
  for the MMAKE env var).

- mmc could have an option, e.g. --log-output FILE, that causes error
  messages to be written to a file instead of standard error. Mmake
  would call mmc using that that option instead of redirecting stderr.

> The way to do it would be to
> 
> - change write_error_spec.m to NOT write out diagnostic lines directly,
>   but simply return them as lines, and make the writing out step separate.
>   This would be relatively easy; almost all the complexity is in the first step,
>   and thus would be unaffected.
> 
> - Then you could either (a) invoke the first step twice, once with colors on,
>   and once with colors off, and then (b) write one to the .err file and the other
>   to stderr. (We could even improve on the current system, which prints up to
>   a fixed number of lines from the .err file without any regard for whether this
>   cuts a diagnostics in half, simply by returning a list of diagnostics, each of which
>   is one or more lines. This benefit may make the above change worthwhile,
>   even though I don't think color issues do that.L)

The problem is when tasks are performed in a separate process.
We'd have to return a Mercury list from a subprocess back to the main
process, most likely doing something similar to serialising a Mercury
term to a file and reading it back.

> My position is
> 
> - color should be turned on by default for all invocations,
>   because even if a diagnostic goes to a file, a human will probably look at it;
> 
> - if you want diagnostics to be processed by a tool that does not know
>   about color escape sequences, then either generate those diagnostics
>   with the --no-color-diagnostics flag or its envvar equivalent, or filter out
>   those escape sequences.
> 
> I think that position is considerably simpler and more understandable
> than yours. Anyone arranging for machine processing of diagnostics
> is already taking an explicit step to command this; requiring the addition
> of an option seems to me to be just a small imposition.

All right then.

Peter