From: kifer@cs.sunysb.edu (Michael Kifer)
Cc: schwab@suse.de, keichwa@gmx.net, alex@gnu.org, emacs-devel@gnu.org
Subject: Re: ediff feature request: diffing line by line
Date: Sun, 17 Mar 2002 13:37:55 -0500 [thread overview]
Message-ID: <200203171837.NAA06738@sbcs.cs.sunysb.edu> (raw)
In-Reply-To: "Carlo Traverso" of Sun, 17 Mar 2002 17:26:46 +0100 <20020317162646.D1CCAB804@cardano.dm.unipi.it>
>>>>> "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 = 1"
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 can
incorporate it.
--michael
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel
next prev parent reply other threads:[~2002-03-17 18:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-16 13:54 ediff feature request: diffing line by line Karl Eichwalder
2002-03-16 16:27 ` Carlo Traverso
2002-03-16 17:43 ` Michael Kifer
2002-03-16 23:04 ` Alex Schroeder
2002-03-17 4:04 ` Karl Eichwalder
2002-03-17 15:40 ` Andreas Schwab
2002-03-17 16:26 ` Carlo Traverso
2002-03-17 18:37 ` Michael Kifer [this message]
2002-03-17 20:41 ` Carlo Traverso
2002-03-17 19:20 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200203171837.NAA06738@sbcs.cs.sunysb.edu \
--to=kifer@cs.sunysb.edu \
--cc=alex@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=keichwa@gmx.net \
--cc=schwab@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).