Now that the feature no longer lives in the extension, we document it in the
help of the core config. This include the new 'ui.color' option introduced in
the previous changesets.
As a result the color extensions can now be deprecated.
This is a documentation patch only; color is still disabled by default.
This should make it clear the dict is only used for new config. Extensions
should not modify it directly anyway since we have 'extraloader' logic for
loading '_styles' too.
This dictionnary is affected by the content of the config, so we should have
one for each ui config.
We rename the global dict to '_baseterminfoparams' to make the situation
clearer.
We'll carry more and more color specific data on the ui object. This will help
isolating different color configuration from each other. For example repository
config might configure special style that should not affect other ui object.
The first step is to make sure the ui object is available were we will needs it.
This new option control whether or not color will be used. It mirror the behavior
of '--color'. I usually avoid adding new option to '[ui]' as the section is
already filled with many option. However, I feel like 'color' is central enough
to deserves a spot in this '[ui]' section.
For now the option is not documented so it is still marked as experimental. Once
it get documented and official, we should be able to deprecate the color
extensions.
There is more cleanup to do before that documentation is written, but we need
this option early to made them. Having that option will allow for more cleanup
of the initialisation process and proper separation between color
configuration.
Before this changeset, the value was carried by the class to work around
limitation of the extensions initialisation. Now that the initialisation is
cleanly handled in 'dispatch', we can drop this work around.
We now run the color initialisation as part of the standard dispatch. This is
opening the way for multiple cleanups since we now have access to the multiple 'ui'
object and we'll be able to see difference between global and local config. This
cleanup will arrive in later changesets.
As a side effect, the '--color' flag is now working without the extension.
Since we now properly initialize color for each ui idependently, we get a
warning message twice.
If 'ui.plain()' is set we should not colorize. We move that logic into the
function that determine and setup the color mode. As all other code respect
the resulting mode this will be equivalent.
In the current code, the function called to write happens to the 'orig' version
of the method calling 'win32print' (obtained with a 'super' call). However, the
variable could have a better name. That will be useful when we'll stop having
inheritance in play.
Another minor cleanup while reading the code. The two branches of the conditional
have similar complexity so we go for the order that give us the simplest
condition (we drop the negation).
This is another part of moving color implementation into core. before we can
move the advance logic, we need to move the basic definition and building
bricks. This is one more step on that road.
Now that we have the '_style' dictionary in core, we can use the clean and
standard 'extraloader' mechanism to load extension's 'colortable'.
color.loadcolortable
This is small first step to start moving the color infrastructure into core. The
current code of the color extensions is full of strange and debatable things,
we'll clean it up in the process as having things into core help the cleaning.
Moving _style was the simplest sensible move that is possible. It will also help
cleaning up the extension setup process in a later changesets.
