Mon, 10 Apr 2017 23:34:43 +0200 upgrade: introduce a 'formatvariant' class
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 10 Apr 2017 23:34:43 +0200] rev 32030
upgrade: introduce a 'formatvariant' class The 'deficiency' type has multiple specificities. We create a dedicated class to host them. More logic will be added incrementally in future changesets.
Mon, 17 Apr 2017 13:07:31 +0200 upgrade: implement '__hash__' on 'improvement' class
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 17 Apr 2017 13:07:31 +0200] rev 32029
upgrade: implement '__hash__' on 'improvement' class The pythonomicon request its implementation.
Mon, 17 Apr 2017 13:07:22 +0200 upgrade: implement '__ne__' on 'improvement' class
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 17 Apr 2017 13:07:22 +0200] rev 32028
upgrade: implement '__ne__' on 'improvement' class The pythonomicon request its implementation.
Sun, 16 Apr 2017 02:34:08 +0200 color: also enable by default on windows
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sun, 16 Apr 2017 02:34:08 +0200] rev 32027
color: also enable by default on windows I've not found anything related to color + windows on the bug tracker. So I'm suggesting we get bolder and turn it on for windows too in the release candidate. We can always backout this changeset if we find serious issue on windows.
Sun, 16 Apr 2017 02:32:51 +0200 color: turn on by default (but for windows)
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sun, 16 Apr 2017 02:32:51 +0200] rev 32026
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.
Sun, 16 Apr 2017 02:48:06 +0200 pager: stop using the color extension in tests
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sun, 16 Apr 2017 02:48:06 +0200] rev 32025
pager: stop using the color extension in tests The feature is in core so let us use the core config knob directly.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -6 +6 +10 +30 +100 +300 +1000 +3000 +10000 tip