Not sure if this is a feature or part of design, but whereas a line diff will treat a new line character (\n at least) as a potential difference, word diff will not. Indeed it's not a word, and I can see the inherent abstract consistency of this treatment. But it may come to mind providing control over what characters delimit words and what characters don't, for word diff. Anyway please don't break the API, the default should behave as it does now..
Having said that, the problem is more severe than new line handling, e.g. any non-word delimiter such as a space character, is just swallowed during the word diff process, and does not show as a difference in the word diff result. I think this aspect should be reconsidered for improvement (while keeping default behavior as is).
Not sure if this is a feature or part of design, but whereas a line diff will treat a new line character (
\nat least) as a potential difference, word diff will not. Indeed it's not a word, and I can see the inherent abstract consistency of this treatment. But it may come to mind providing control over what characters delimit words and what characters don't, for word diff. Anyway please don't break the API, the default should behave as it does now..Having said that, the problem is more severe than new line handling, e.g. any non-word delimiter such as a space character, is just swallowed during the word diff process, and does not show as a difference in the word diff result. I think this aspect should be reconsidered for improvement (while keeping default behavior as is).