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 > have implications such

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 want to tack on new >> features, the enum would g

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 feature. However as we

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, the enum would grow

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 via

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 want to tack on new >> features, the enum would g

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 code such that features