Re: Removing assumption of unsigned long pixel values for colours

[Eli Zaretskii]

> From: Alex Gramiak <address@hidden>
> Date: Sat, 04 May 2019 12:08:34 -0600
> 
> I've attached a WIP patch (for illustrative purposes) creating a new
> union, emacs_color, that removes the single type limitation for the
> internal representation of colours. This approach is intended to be used
> with a new backend that I'm working on which uses a quadruple of
> normalized double values for each colour rather than a single pixel
> value. Using a union would avoid having to frequently convert between
> the two representations.

Can you describe the goal, in terms of the advantages of such a
representation, and the limitations of the existing representation
that it attempts to resolve?  I think whether we want to make this
change depends on what will we gain from the changes.

Thanks.

> * prepare_face_for_display takes in an XGCValues, which assumes unsigned
>   long colour values. On non-X systems that create their own XGCValues,
>   they can just be redefined, but on X that won't work. That means a new
>   struct has to also be defined on X and then copied into an XGCValues
>   in x_create_gc.
> 
> * The colors member of struct image was changed to use the new union,
>   but XFreeColors expects an array of unsigned long pixels. It looks
>   like the colors array is only used when COLOR_TABLE_SUPPORT is
>   defined, so perhaps it could just used unsigned long unconditionally.

The main reason that we use unsigned integers for colors is that this
is how various color systems handle colors.  It isn't an arbitrary
design decision.  By using a different representation we introduce an
extra level of complexity, so it's important to know what will that
gain us.

> Question: In realize_gui_face, why is a defaulted underline colour set
> to 0 when defaulted overline/strike-through colours are set to the
> foreground colour? The comment above the underline case mentions that
> it's the same as the foreground colour, so should it be explicitly set
> there as well?

realize_gui_face just sets a flag, the implementation should be in the
*term.c back-ends.  When that flag is set, the color of the underline
should be disregarded and taken from the current foreground color. On
MS-Windows, the underline changes its color according to the
foreground color of the text it underlines.  Don't you see the same on X?