Re: PATCH: true colour support

[Oliver Kiddle <okiddle@xxxxxxxxxxx>]

Sebastian Gniazdowski wrote:
> I'm grepping the patches and cannot find any snippet that decides
> whether to use 24-bit escape sequences or zsh/nearcolor module. How
> it's decided?

The following section of new documentation (in mod_nearcolor.yo) is
intended to cover this:

+In order to use the tt(zsh/nearcolor) module, it only needs to be
+loaded. Thereafter, whenever a colour is specified using a hex triplet,
+it will be compared against each of the available colours and the
+closest will be selected.

On loading, zsh/nearcolor registers a hook function for GETCOLORATTR.
After parsing a hex triplet, match_colour() calls:
  colour = runhookdef(GETCOLORATTR, &color) - 1.
runhookdef() returns 0 if there is no registered handler for the hook
The following line in match_colour() is:
  if (colour < 0) { /* no hook function added, try true color (24-bit) */

> You've also written: "No true colour escapes will ever be generated if
> you don't specify colours as hex triples anyway. And even if they are,
> they should be ignored.".This sounds like: if true-color/near-color
> was not enabled, ignore hex-triplet. But I think there is no switch
> (e.g. an option) to enable true-color support?

You don't need to do anything to enable true colour. It is the
default when you specify colours as a hex triplet. With the text
you quoted, I was trying to justify this decision by pointing out
that there are no backward compatibility concerns - any existing
setup that only uses the old forms - %F{blue}, %K{123} etc - will
work exactly as before (no true color escape codes are ever generated).

But before introducing colours specified as hex triplets in their
configuration, users may want to take care to either load zsh/nearcolor
or use a terminal that supports true colour.

Feel free to suggest improvements to the documentation.

Oliver