comparison tests/test-mq.t @ 32026:57042e91521a

color: turn on by default (but for windows) Color support is all in core for a couple of months. I've browsed the bug tracker without finding any blocker bug. So I'm moving forward and enable color on by default before '4.2-rc'. In the worse case, having it on in the release candidate will help us to find blocker bug and we can turn it off for the final release. I remember people talking about issue with Windows during the freeze so I'm keeping it off by default on that OS. We could do various cleaning of the color used and the label issued. However the label are probably already in our backward compatibility envelope since the color extensions has been around since for ever and I do not think the color choice themself should be considered BC. So I think we should rather gives color to all user sooner than later. A couple of test needs to be updated to avoid having color related control code spoil the tested output.
author Pierre-Yves David <pierre-yves.david@ens-lyon.org>
date Sun, 16 Apr 2017 02:32:51 +0200
parents 5fbf1da938a6
children 75be14993fda
comparison
equal deleted inserted replaced
32025:d323d9e0d7b4 32026:57042e91521a
363 now at: test2.patch 363 now at: test2.patch
364 364
365 365
366 setting columns & formatted tests truncating (issue1912) 366 setting columns & formatted tests truncating (issue1912)
367 367
368 $ COLUMNS=4 hg qseries --config ui.formatted=true 368 $ COLUMNS=4 hg qseries --config ui.formatted=true --color=no
369 test.patch 369 test.patch
370 test2.patch 370 test2.patch
371 $ COLUMNS=20 hg qseries --config ui.formatted=true -vs 371 $ COLUMNS=20 hg qseries --config ui.formatted=true -vs --color=no
372 0 A test.patch: f... 372 0 A test.patch: f...
373 1 A test2.patch: 373 1 A test2.patch:
374 $ hg qpop 374 $ hg qpop
375 popping test2.patch 375 popping test2.patch
376 now at: test.patch 376 now at: test.patch