[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ediff feature request: diffing line by line

From: Michael Kifer
Subject: Re: ediff feature request: diffing line by line
Date: Sun, 17 Mar 2002 13:37:55 -0500

>>>>> "CT" == Carlo Traverso <of Sun, 17 Mar 2002 17:26:46 +0100> writes:

    CT> I had missed ediff-regions-wordwise and ediff-windows-wordwise, that
    CT> solve a lot of my problems; however these three enhancements would
    CT> help:

    CT> 1 - switching from ediff-buffers to ediff-regions-wordwise: a key
    CT> could be defined to select the current ediff regions in both
    CT> buffers and enter an ediff-regions-wordwise on them; the same for
    CT> ediff-windows-wordwise. This is currently possible, but not with one
    CT> key (this should be extremely easy to implement).

I didn't understand the original problem, but when Alex Schroeder explained
it I also thought about ediff-regions-wordwise. If I understand you and him
correctly, all that is needed is to be able to conveniently invoke this
function on the currently highlighted regions.
In fact this key already exists (=), but it asks you to select a region
instead of taking the currently highlighted diffs. 
I felt that having this key is not very useful, because one can simply run
ediff-regions-* from command line or from the menu, and this won't be any
more difficult. So, I am thinking of repurposing this key to run
ediff-regions-wordwise on the selected diff regions.

    CT> 2 - the highlighting scheme should be revised, since entering
    CT> ediff-regions-wordwise from ediff-buffers removes highlighting from
    CT> the current word (i.e. the current region in ediff and the current
    CT> word in ediff-regions-wordwise are highlited in the same color...)
    CT> ediff-windows-wordwise inside of ediff-buffers is even worse....
    CT> (this should be very easy too)

I don't understand. Are you saying that the highlighting of the current
diff is not removed when you invoke ediff-regions-*? This is a bug, which I
noticed recently.

    CT> 3 - enhancing ediff-regions-wordwise (ediff-windows-wordwise) allowing
    CT> to discover and reconcile whitespace "substantial" differences: I
    CT> consider "substantial" these differences:

    CT> - additional blank lines
    CT> - space between words vs no space between words (e.g. "one=1" vs "one = 

    CT> The amount of whitespace (e.g. "  " vs " ") or the type (space, tab,
    CT> newline) is inessential (but two consecutive newlines is not the same
    CT> as one newline...)

What you are saying is that for word-wise operations the meaning of
ediff-word should be different from line-wise operations. This makes sense.
If somebody comes up with a better definition, I can incorporate it.
Ediff is using a simple heuristic to determine what should constitute a word
for the purpose of diffing. Take a look at ediff-forward-word in ediff-diff.el.
I found it to work very well for line-wise diffing, but I don't use
word-wise diffing much and have no opinion about it.
If you can come up with a good (and simple) heuristic for word-wise diffing, I 
incorporate it.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]