Re: [PATCH 5/7] diff.c: refactor internal representation for coloring moved code

2018-04-06 Thread Jonathan Tan
On Fri, 6 Apr 2018 14:28:40 -0700 Stefan Beller wrote: > Now that I redid it another way[1], I have the impression that this was the > right approach, because it allows for a short > if (o->color_moved) > condition. If we treat white spaces separately, then we'd have to >

Re: [PATCH 5/7] diff.c: refactor internal representation for coloring moved code

2018-04-06 Thread Stefan Beller
On Mon, Apr 2, 2018 at 4:51 PM, Jonathan Tan wrote: > On Mon, 2 Apr 2018 15:48:52 -0700 > Stefan Beller wrote: > >> At the time the move coloring was implemented we thought an enum of modes >> is the best to configure this feature. However as we

Re: [PATCH 5/7] diff.c: refactor internal representation for coloring moved code

2018-04-03 Thread Ævar Arnfjörð Bjarmason
On Tue, Apr 03 2018, Stefan Beller wrote: > On Tue, Apr 3, 2018 at 12:39 PM, Ævar Arnfjörð Bjarmason > wrote: >> >> On Mon, Apr 02 2018, Stefan Beller wrote: >> >>> At the time the move coloring was implemented we thought an enum of modes >>> is the best to configure this

Re: [PATCH 5/7] diff.c: refactor internal representation for coloring moved code

2018-04-03 Thread Stefan Beller
On Tue, Apr 3, 2018 at 12:39 PM, Ævar Arnfjörð Bjarmason wrote: > > On Mon, Apr 02 2018, Stefan Beller wrote: > >> At the time the move coloring was implemented we thought an enum of modes >> is the best to configure this feature. However as we want to tack on new >> features,

Re: [PATCH 5/7] diff.c: refactor internal representation for coloring moved code

2018-04-03 Thread Ævar Arnfjörð Bjarmason
On Mon, Apr 02 2018, Stefan Beller wrote: > At the time the move coloring was implemented we thought an enum of modes > is the best to configure this feature. However as we want to tack on new > features, the enum would grow exponentially. > > Refactor the code such that features are enabled

Re: [PATCH 5/7] diff.c: refactor internal representation for coloring moved code

2018-04-03 Thread Stefan Beller
On Mon, Apr 2, 2018 at 4:51 PM, Jonathan Tan wrote: > On Mon, 2 Apr 2018 15:48:52 -0700 > Stefan Beller wrote: > >> At the time the move coloring was implemented we thought an enum of modes >> is the best to configure this feature. However as we

Re: [PATCH 5/7] diff.c: refactor internal representation for coloring moved code

2018-04-02 Thread Jonathan Tan
On Mon, 2 Apr 2018 15:48:52 -0700 Stefan Beller wrote: > At the time the move coloring was implemented we thought an enum of modes > is the best to configure this feature. However as we want to tack on new > features, the enum would grow exponentially. > > Refactor the

[PATCH 5/7] diff.c: refactor internal representation for coloring moved code

2018-04-02 Thread Stefan Beller
At the time the move coloring was implemented we thought an enum of modes is the best to configure this feature. However as we want to tack on new features, the enum would grow exponentially. Refactor the code such that features are enabled via bits. Currently we can * activate the move