Tue, 28 Mar 2017 07:54:00 -0700 rcutil: do not cache rccomponents
Jun Wu <quark@fb.com> [Tue, 28 Mar 2017 07:54:00 -0700] rev 31692
rcutil: do not cache rccomponents The function is only called once except for "hg debugconfig", where it is called twice. So there is no need to cache it. Caching it will cause issues with chgserver. Instead of dropping the cache in chgserver, it seems cleaner to just avoid the cache.
Sat, 25 Mar 2017 19:17:11 -0400 ui: rerun color.setup() once the pager has spawned to honor 'color.pagermode'
Matt Harbison <matt_harbison@yahoo.com> [Sat, 25 Mar 2017 19:17:11 -0400] rev 31691
ui: rerun color.setup() once the pager has spawned to honor 'color.pagermode' Otherwise, ui.pageractive is False when color is setup in dispatch.py (without --pager=on), and this config option is ignored.
Sat, 25 Mar 2017 21:12:00 -0400 ui: defer setting pager related properties until the pager has spawned
Matt Harbison <matt_harbison@yahoo.com> [Sat, 25 Mar 2017 21:12:00 -0400] rev 31690
ui: defer setting pager related properties until the pager has spawned When --pager=on is given, dispatch.py spawns a pager before setting up color. If the pager failed to launch, ui.pageractive was left set to True, so color configured itself based on 'color.pagermode'. A typical MSYS setting would be 'color.mode=auto, color.pagermode=ansi'. In the failure case, this would print a warning, disable the pager, and then print the raw ANSI codes to the terminal. Care needs to be taken, because it appears that leaving ui.pageractive=True was the only thing that prevented an attempt at running the pager again from inside the command. This results in a double warning message, so pager is simply disabled on failure. The ui config settings didn't need to be moved to fix this, but it seemed like the right thing to do for consistency.
Sat, 25 Mar 2017 13:50:17 -0400 color: stop mutating the default effects map
Matt Harbison <matt_harbison@yahoo.com> [Sat, 25 Mar 2017 13:50:17 -0400] rev 31689
color: stop mutating the default effects map A future change will make color.setup() callable a second time when the pager is spawned, in order to honor the 'color.pagermode' setting. The problem was that when 'color.mode=auto' was resolved to 'win32' in the first pass, the default ANSI effects were overwritten, making it impossible to honor 'pagermode=ansi'. Also, the two separate maps didn't have the same keys. The symmetric difference is 'dim' and 'italic' (from ANSI), and 'bold_background' (from win32). Thus, the update left entries that didn't belong for the current mode. This bled through `hg debugcolor`, where the unsupported ANSI keys were listed in 'win32' mode. As an added bonus, this now correctly enables color with MSYS `less` for a command like this, where pager is forced on: $ hg log --config color.pagermode=ansi --pager=yes --color=auto Previously, the output was corrupted. The raw output, as seen through the ANSI blind `more.com` was: <-[-1;6mchangeset: 34840:3580d1197af9<-[-1m ... which MSYS `less -FRX` rendered as: 1;6mchangeset: 34840:3580d1197af91m ... (The two '<-' instances were actually an arrow character that TortoiseHg warned couldn't be encoded, and notepad++ translated to a single '?'.) Returning an empty map for 'ui._colormode == None' seems better that defaulting to '_effects' (since some keys are mode dependent), and is better than None, which blows up `hg debugcolor --color=never`.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -4 +4 +10 +30 +100 +300 +1000 +3000 +10000 tip