Stefan Beller <sbeller@xxxxxxxxxx> writes: > I think once this option is given, all we have to do is pay attention to > this option in diff.c#moved_entry_cmp/next_byte, which is best built > on top of Peffs recent fixes origin/jk/diff-color-moved-fix. > Would that be of interest for people? Two things and a half. * I was hoping that the next_byte() and string_hash() thing, once they are cleaned up, will eventually be shared with the xdiff/ code at the lower layer, which needs to do pretty much the same in order to implement various whitespace ignoring options. I am not sure how well the approach taken by the WIP patch meshes with the needs of the lower layer. * I agree that -w that applies only one or the other and not both may sometimes produce a better/readable result, but the more important part is how the user can tell when to exercise the option. Would it be realistic to expect them to try -w in different combinations and see which looks the best? What if we have a patch that touch two files, one looks better with -w only for coloring moved and the other looks better with -w for both? * As moved-lines display is mostly a presentation thing, I wonder if it makes sense to always match loosely wrt whitespace differences. It is tempting because if it is true, we do not have to worry about the second issue above. Thanks.
