From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Carlo Traverso Newsgroups: gmane.emacs.devel Subject: Re: ediff feature request: diffing line by line Date: Sun, 17 Mar 2002 21:41:59 +0100 (CET) Sender: emacs-devel-admin@gnu.org Message-ID: <20020317204159.1247AB804@cardano.dm.unipi.it> References: <200203171837.NAA06738@sbcs.cs.sunysb.edu> Reply-To: traverso@dm.unipi.it NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1016397790 30461 127.0.0.1 (17 Mar 2002 20:43:10 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 17 Mar 2002 20:43:10 +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 16mhUk-0007vD-00 for ; Sun, 17 Mar 2002 21:43:10 +0100 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16mhYh-00022W-00 for ; Sun, 17 Mar 2002 21:47:15 +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 16mhTl-0005Ok-00; Sun, 17 Mar 2002 15:42:09 -0500 Original-Received: from cardano.dm.unipi.it ([131.114.6.22]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16mhTa-0005OL-00; Sun, 17 Mar 2002 15:41:58 -0500 Original-Received: by cardano.dm.unipi.it (Postfix, from userid 3010) id 1247AB804; Sun, 17 Mar 2002 21:41:59 +0100 (CET) Original-To: kifer@cs.sunysb.edu In-Reply-To: <200203171837.NAA06738@sbcs.cs.sunysb.edu> (kifer@cs.sunysb.edu) 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:1993 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:1993 >>>>> "Michael" == Michael Kifer writes: >>>>> "CT" == Carlo Traverso writes: CT> I had missed ediff-regions-wordwise and CT> ediff-windows-wordwise, that solve a lot of my problems; CT> however these three enhancements would help: CT> 1 - switching from ediff-buffers to ediff-regions-wordwise: a CT> key could be defined to select the current ediff regions in CT> both buffers and enter an ediff-regions-wordwise on them; the CT> same for ediff-windows-wordwise. This is currently possible, CT> but not with one key (this should be extremely easy to CT> implement). Michael> I didn't understand the original problem, but when Alex Michael> Schroeder explained it I also thought about Michael> ediff-regions-wordwise. If I understand you and him Michael> correctly, all that is needed is to be able to Michael> conveniently invoke this function on the currently Michael> highlighted regions. In fact this key already exists Michael> (=), but it asks you to select a region instead of taking Michael> the currently highlighted diffs. I felt that having this Michael> key is not very useful, because one can simply run Michael> ediff-regions-* from command line or from the menu, and Michael> this won't be any more difficult. So, I am thinking of Michael> repurposing this key to run ediff-regions-wordwise on the Michael> selected diff regions. Please, don't. I hate when a key to which I am used changes; there are other unused keys, e.g. + and -, to run ediff-*-wordwise on the current *. CT> 2 - the highlighting scheme should be revised, since entering CT> ediff-regions-wordwise from ediff-buffers removes highlighting CT> from the current word (i.e. the current region in ediff and CT> the current word in ediff-regions-wordwise are highlited in CT> the same color...) ediff-windows-wordwise inside of CT> ediff-buffers is even worse.... (this should be very easy CT> too) Michael> I don't understand. Are you saying that the highlighting Michael> of the current diff is not removed when you invoke Michael> ediff-regions-*? This is a bug, which I noticed recently. Yes, non removing the highlighting makes the highlighting of the new session ineffective. CT> 3 - enhancing ediff-regions-wordwise (ediff-windows-wordwise) CT> allowing to discover and reconcile whitespace "substantial" CT> differences: I consider "substantial" these differences: CT> - additional blank lines - space between words vs no space CT> between words (e.g. "one=1" vs "one = 1" CT> The amount of whitespace (e.g. " " vs " ") or the type CT> (space, tab, newline) is inessential (but two consecutive CT> newlines is not the same as one newline...) Michael> What you are saying is that for word-wise operations the Michael> meaning of ediff-word should be different from line-wise Michael> operations. This makes sense. If somebody comes up with Michael> a better definition, I can incorporate it. Ediff is Michael> using a simple heuristic to determine what should Michael> constitute a word for the purpose of diffing. Take a look Michael> at ediff-forward-word in ediff-diff.el. I found it to Michael> work very well for line-wise diffing, but I don't use Michael> word-wise diffing much and have no opinion about it. If Michael> you can come up with a good (and simple) heuristic for Michael> word-wise diffing, I can incorporate it. I'll look at that. I have also remarked some strange behaviour in ediff-*-wordwise; in particular, if you accept one version of all the differences, then you find a new set of differences; this is mainly due to the handling of whitespace. I'll prepare a report on what I think is wrong (and maybe a patch...). Try for example a file consisting of the line "one two three" and one with the line "one three" (the result is "one twothree") Carlo _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel