unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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


  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).