Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 12 Apr 2017 16:34:05 +0200] rev 32031
upgrade: move descriptions and selection logic in individual classes
Our goal here is to get top level definition for all the format variants. Having
them defined outside of the function enabled other users of that logic.
They are two keys components of a format variant:
1) the name and various descriptions of its effect,
2) the code that checks if the repo is using this variant and if the config
enables it.
That second items make us pick a class-based approach, since different variants
requires different code (even if in practice, many can reuse the same logic).
Each variants define its own class that is then used like a singleton. The
class-based approach also clarify the definitions part a bit since each are
simple assignment in an indented block.
The 'fromdefault' and 'fromconfig' are respectively replaced by a class
attribute and a method to be called at the one place where "fromconfig"
matters.
Overall, they are many viable approach for this, but this is the one I picked.
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.
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.
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.
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.
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.
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.