[m-rev.] for review: colour in error messages

[Julien Fischer]

On Wed, 24 Apr 2024, Zoltan Somogyi wrote:

>>> 3. Should we support something beyond 8-bit color (such as that 45)?
>>> I have no idea how widespread the support for 24 bit rgb is in terminals
>>> (as opposed to actual display devices).
>>>
>>> If so, what should the option names be?
>>
>> I would not worry about it initially.
>
> I am not worrying.

In case it wasn't clear that comment was referring to supporting beyond
8-bit color, not the option names.

>>> 5. At the moment, the diff supports two colours, intended for correct
>>> and incorrect code respectively. In error messsages of the form
>>> "expected x, got y", the intention is that x would be in the correct colour,
>>> and the y in the incorrect colour.
>>>
>>> Should we have a separate logical colour for "this may be caused by"
>>> messages?
>>
>> I think so.  More generally, we probably need to go thorugh the expected
>> outputs in tests/invalid and tests/warnings and work out where colour
>> could be useful.
>
> Agreed, but actually I would first prefer to go through typecheck_errors.m
> and see where I can eliminate unnecessary differences first. That module
> evolved somewhat haphazardly, so there are mechanisms to be helpful
> to the programmer that are implemented only for one kind of error, but not
> other, closely related kinds.

...

>>> 6. The bike-shed question: it is clear that option names should have
>>> two versions, one with "color" and one with "colour", but which spelling
>>> we should use internally? The american version is slightly less likely to cause
>>> a line to be too long, but graph_colour.m and set_of_var.m use brit spelling.
>>
>> Based on a grep of the compiler source code (and a review of your diff),
>> I think that's already been "decided": colour.
>
> Actually, when I wrote the code, I used "color" throughout, because that is what came
> naturally. I only changed to brit spelling at the end, to match the rest of the compiler.
> The switch is trivial, a simple global search and replace, so I think this "decision" is
> *far* from set it stone.

I don't particuarly care which is used.

Julien.