color-words: change algorithm to allow for 0-character word boundaries
commit2e5d2003b28820f88296e47a79eb440ca0295000
authorJohannes Schindelin <johannes.schindelin@gmx.de>
Sat, 17 Jan 2009 16:29:44 +0000 (17 17:29 +0100)
committerJunio C Hamano <gitster@pobox.com>
Sat, 17 Jan 2009 18:42:41 +0000 (17 10:42 -0800)
tree41d9fb5db61645fd6ab8dc03a98230642c9db416
parent23c1575f747393f9847874fd1ed72a44557459d1
color-words: change algorithm to allow for 0-character word boundaries

Up until now, the color-words code assumed that word boundaries are
identical to white space characters.

Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).

This code was ugly, for a number of reasons:

- it was impossible to introduce 0-character word boundaries,

- we had to print everything word by word, and

- the code needed extra special handling of newlines in the removed part.

Fix all of these issues by processing the text such that

- we build word lists, separated by newlines,

- we remember the original offsets for every word, and

- after calling libxdiff on the wordlists, we parse the hunk headers, and
  find the corresponding offsets, and then

- we print the removed/added parts in one go.

The pre and post samples in the test were provided by Santi BĂ©jar.

Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low.  In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff.c
t/t4034-diff-words.sh [new file with mode: 0755]