merge with stable

color: rename '_styles' to '_defaultstyles' for clarity 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.

color: move 'styles' definition on the 'ui' object Same logic as for '_terminfoparams'. The content depends on the config so it should be specific to each 'ui instance.

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.

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.

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.

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.

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.

color: reinvent dictionary move the module lever dictionary declaration to a more standard (and practical indentation)

chg: deduplicate error handling of ui.system() This moves 'onerr' handling from low-level util.system() to higher level, which seems better API separation.

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.

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.

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.

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'.

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.

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.

color: move 'modesetup' into the core module Yet another piece of code moving from the extensions to the module in core!

color: move 'terminfosetup' into the core module Another step closer to have all the logic living in core

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.

wix: include the help for pager Similar (I assume) to 65d2538ac993.

manifest: check 'if x is None' instead of 'if not x' The old code here would end up executing __len__ on a tree manifest to determine if 'not _data' was true or not. This was very expensive on large repos. Since this function just cares about memoization, we can just check 'if _data is None' instead and save a bunch of time.

pager: add support to --patch, --list and --stat options of hg shelve

color: drop the 'colorui' class 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.

color: move 'write-err' logic to the core ui class 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.

ui: extract low level part of 'write_err' in its own method Same as for 'write' and '_write' we needs it available for some of the color logic.

ui: extract buffer write from protect and timed 'write_err' output That subcall to 'self.write' is never doing actual write but only store things in buffers. So we do not need to protect it for exception not to time its execution. This will make it easier to extract a '_write_err' function as we did for 'write'.

color: move 'write' logic to the core ui class 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

ui: extract the low level part of 'write' in a dedicated function We are about to add some extra logic related to color. That logic will need to access the low level layer of ui doing the actual write to a stream. (eg: 'win32print'). We extract this logic into a private method for this purpose.

color: add multiple messages input support to 'win32print' All other function doing writes support any number of input message. For simplicity, we make 'win32print' able to do the same.

color: clarify name of an argument of 'win32print' 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.

color: move the 'colorlabel' call to the core 'ui' class 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.

color: move the 'colorlabel' function in the core module The extract code is relocated in core.

color: extract the label code into its own function We extract the logic into a function. This will allow us to move the logic into the core 'color' module and later call it directly from core.

color: inline the 'showlabel' method 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.

color: move '_colormode' to the core 'ui' class 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.

hgweb: explictly pass basectx in webutil.diffs There's only one case where `basectx` parameter is None (over two usages), so it's probably not worth handling the special case as it makes code-reading harder. Along the way, use ctx.p1() instead of checking for ctx.parents() being empty which should not occur.

serve: mark --stdio and --cmdserver as "(ADVANCED)" flags This will hide them from the default --help output.

help: hide command line options marked as "advanced" Previously, we have keywords like "(DEPRECATED)" and "(EXPERIMENTAL)" to hide command line options in non-verbose help output. However, sometimes an option is neither deprecated nor experimental. It's well-tested and working, but just not designed to average users. This patch adds a keyword "(ADVANCED)" to fit in such use cases. Thanks rom1dep for the suggestion of the word "advanced".

pager: do not try to run an empty pager command If pagercmd is explicitly set to '', the pager process would exit silently and the output would be lost. We'd better disable the pager in such case.

graphlog: restore pager lost at 1cec1d863008

gitweb: add "more" and "less" navigation links in filelog template

context: also return ancestor's line range in blockancestors

context: add a followfirst flag to blockancestors

py3: use pycompat.fsencode() to convert __file__ to bytes __file__ returns unicodes on Python 3. This patch uses pycompat.fsencode() to convert them to bytes.

wireproto: remove unused code Removed an unused line introduced by f3807a135e43.

color: set initial default value for 'colormode' to None 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.

color: minor reversal of two conditional clause for clarity 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).

color: merge two identical 'for' loops The previous changeset made it clear that we are iterating twice on the same items. We gather the two loops into a single one.