From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: kifer@cs.sunysb.edu (Michael Kifer) Newsgroups: gmane.emacs.devel Subject: Re: ediff feature request: diffing line by line Date: Sun, 17 Mar 2002 13:37:55 -0500 Sender: emacs-devel-admin@gnu.org Message-ID: <200203171837.NAA06738@sbcs.cs.sunysb.edu> References: <20020317162646.D1CCAB804@cardano.dm.unipi.it> NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1016390589 26836 127.0.0.1 (17 Mar 2002 18:43:09 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 17 Mar 2002 18:43:09 +0000 (UTC) Cc: schwab@suse.de, keichwa@gmx.net, alex@gnu.org, emacs-devel@gnu.org Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16mfcb-0006yk-00 for ; Sun, 17 Mar 2002 19:43:09 +0100 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16mfgW-0001BR-00 for ; Sun, 17 Mar 2002 19:47:12 +0100 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16mfbk-0002G5-00; Sun, 17 Mar 2002 13:42:16 -0500 Original-Received: from sbcs.cs.sunysb.edu ([130.245.1.15]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16mfaw-0002ED-00; Sun, 17 Mar 2002 13:41:26 -0500 Original-Received: from sbkifer (sbkifer [130.245.1.35]) by sbcs.cs.sunysb.edu (8.9.3/8.9.3) with SMTP id NAA06738; Sun, 17 Mar 2002 13:37:53 -0500 (EST) Original-To: traverso@dm.unipi.it In-Reply-To: "Carlo Traverso" of Sun, 17 Mar 2002 17:26:46 +0100 <20020317162646.D1CCAB804@cardano.dm.unipi.it> Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:1988 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:1988 >>>>> "CT" == Carlo Traverso 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