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 is the last bits we needed to move out of the extensions. 'hgext/color.py'
now only contains logic to changes the default color behavior to 'auto'.
However, more cleanups are on the way and we need to document the new config
directly in core.
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.
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.
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 we want to be able to move the initialisation in core, we need core to be
aware of that '--color' flag at all time. So we now have the definition in core. That flag
is currently unprocessed without the extensions (will be fixed soon). In
addition the default value for this flag in core is 'never'. Enabling the
extensions change that default value to 'auto'.
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.
Now that all ui instance carry a '_colormode' attribute, we can access and
comply to it directly in the subrepo code. The actual implementation could
probably be a bit smarter, but we stick close to the current one for the sake
of simplicity.
Now that all logics formally bared by 'colorui' have been moved to the main ui
class, that class is empty and can be dropped. As a nice side effect we can get
rid of the baroque Initialization associated to it.
There was much rejoicing.
This is similar to what we needed for 'write', we move the logic from the
extension to the core class. Beside the dispatch to 'win32print', we just apply
label to the argument.
One more step, the support for writing color is not directly in core. No
behavior change for the default case ('_colormode' = None).
Here are the details of what we have to change to the core method:
* apply to 'self.label' to input in the buffered case
* dispatch to 'win32print' when applicable
* apply to 'self.label' to input when applicable
This bring us closer to supporting color in core natively. Core already have a
'label' method that was a no-op. We update its to call the new 'colorlabel'
function. Behavior is unchanged when colormode = None.
This function is quite simple and only have one call site… located a handful of line
under the definition. We inline the function for the sake of simplicity. One of
the motivation to do that now is that it reduce the amount of new method we
will have to add to the core 'ui' class for color support.
Having all 'ui' objects aware of 'color' allows us to update the core code to
handle color. The mode will stay 'None' in the default case so that will not
introduce any changes.
This should not introduce any behavior changes when using the color extension.
In practive, the colormode will be setup at early at run time to the proper
value (from config and environment).
We do this change as this gets us closer of a state were we can have all the
mechanisms associated to color in core with the feature disabled by default.
No logic change is introduced. The previous code were using a 'dict.update' with
a complex generator. That was a bit confusing to read and not so compact.
Instead we now use an explicit loop and conditional for the sake of clarity.
This also allow for more simplification coming in the next changeset.
We won't use terminfo when curse failed to load. Before this change, we were
doing an indirect test, relying on the fact some variable ('_terminfo_params')
would be empty if curses failed to load. We update the code to be more explicit
and directly checks if we managed to load the curse module.
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.
Using 'global' is usually a bad sign. Here it is used so that one can empty the
content of a dict at the global scope. We '_style.clear()' and drop the global.
Using 'global' is usually a bad sign. Here it is used so that one can empty the
content of a dict at the global scope. We '_terminfo_params.clear()' and
drop the global.
The 'hg debugcolor' command gains a '--style' flag to display all the configured
labels and their styles. This have many benefits:
* discovering documented label,
* checking consistency between label's style,
* showing the actual style of a label.
The previous ordering were provided by the set. The new output is more stable
and rational. In addition we have some logic to keep the '_background' version
together to help readability.
We are about to introduce a second mode for 'hg debugcolor' that would list the
known label and their configuration, so we split the code related to color and
effect out of the main function.
Before this change, running 'debugcolor' would destroy all color style for the
rest of the process life. We now properly backup and restore the variable
content. Using a global variable is sketchy in general and could probably be
removed. However, this is a quest for another adventure.
If terminfo mode is in effect, and an effect is used which is missing from
the terminfo database, simply silently ignore the request, leaving the
output unaffected rather than causing a crash.
If the entry in the terminfo database for your terminal is missing some
attributes, it should be possible to create them on the fly without
resorting to just making them a color. This change allows you to have
[color]
terminfo.<effect> = <code>
where <effect> might be something like "dim" or "bold", and <code> is the
escape sequence that would otherwise have come from a call to tigetstr().
If an escape character is needed, use "\E". Any such settings will
override attributes that are present in the terminfo database.
