Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sun, 06 Nov 2016 20:10:53 +0100] rev 31114
color: pass 'ui' to 'win32print'
Same logic as before,'win32print' relies on some data we will move on the 'ui'
object soon, we update the API beforehand for clarity.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 25 Feb 2017 15:00:51 +0100] rev 31113
color: move the dict with terminfo parameters on the ui object
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.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 25 Feb 2017 15:00:44 +0100] rev 31112
color: add ui to effect rendering
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.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 25 Feb 2017 18:34:01 +0100] rev 31111
color: initialize color for the localrepo ui
The 'ui' object dedicated to a 'localrepo' is independent from the one available
in dispatch (and 'uisetup'). In addition, it is created from the 'baseui'
(apparently for good reason). As a result, we need to run the color setup on
it after the local repository config is read.
This was overlooked when the rest of the initialization changed but did not
had impact yet because all setup is still global. We fix it before it is too
late.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 25 Feb 2017 19:44:23 +0100] rev 31110
color: add a 'ui.color' option to control color behavior
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.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 28 Feb 2017 11:42:07 +0100] rev 31109
color: reinvent dictionary
move the module lever dictionary declaration to a more standard (and practical
indentation)
Yuya Nishihara <yuya@tcha.org> [Sun, 19 Feb 2017 01:16:45 +0900] rev 31108
chg: deduplicate error handling of ui.system()
This moves 'onerr' handling from low-level util.system() to higher level,
which seems better API separation.
Yuya Nishihara <yuya@tcha.org> [Sun, 19 Feb 2017 01:00:10 +0900] rev 31107
chg: refactor ui.system() to be partly overridden
Since
fd598149112b changed the signature of ui.system(), chgui.system()
should have been updated. This patch factors out the util.system() call
so that chg can override how a shell command is executed.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 21 Feb 2017 18:22:07 +0100] rev 31106
color: have the 'ui' object carry the '_colormode' directly
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.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 21 Feb 2017 18:20:12 +0100] rev 31105
color: move triggering of the initialisation logic in core
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.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 21 Feb 2017 18:09:21 +0100] rev 31104
color: add the definition of '--color' in core
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'.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 21 Feb 2017 17:51:43 +0100] rev 31103
color: handle 'ui.plain()' directly in mode setup
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.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 21 Feb 2017 17:50:04 +0100] rev 31102
color: move git-subrepo support into the subrepo module
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.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 22 Dec 2016 14:30:46 +0100] rev 31101
color: move 'modesetup' into the core module
Yet another piece of code moving from the extensions to the module in core!
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 22 Dec 2016 14:17:52 +0100] rev 31100
color: move 'terminfosetup' into the core module
Another step closer to have all the logic living in core
Matt Harbison <matt_harbison@yahoo.com> [Sat, 25 Feb 2017 21:13:59 -0500] rev 31099
subrepo: run the repo decoders when archiving
The decoders were already run by default for the main repo, so this seemed like
an oversight.
The extdiff extension has been using 'archive' since
68822b7cdd01 to support -S,
and a colleague noticed that after diffing, making changes, and closing it, the
line endings were wrong for the diff-tool modified files in the subrepository.
(Files in the parent repo were correct, with the same .hgeol settings.) The
editor (Visual Studio in this case) reloads the file, but doesn't notice the EOL
change. It still adds new lines with the original EOL setting, and the file
ends up inconsistent.
Without this change, the first file `cat`d in the test prints '\r (esc)' EOL,
but the second doesn't on Windows or Linux.