GNU bug report logs - #17388
24.4.50; REGRESSION: Ediff - 1) wrong face, 2) incorrect diffing

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 17388 <at> debbugs.gnu.org, kifer <at> cs.stonybrook.edu, monnier <at> iro.umontreal.ca
Subject: bug#17388: 24.4.50; REGRESSION: Ediff - 1) wrong face, 2) incorrect diffing
Date: Sat, 03 May 2014 19:42:12 +0300

> Date: Sat, 3 May 2014 07:01:13 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: monnier <at> iro.umontreal.ca, 17388 <at> debbugs.gnu.org, kifer <at> cs.stonybrook.edu
> 
> > > There should be EITHER, (a) as previously, NO fine diffs shown for
> > > other than the current diff OR (b) CORRECT (helpful) fine diffs
> > > shown for the non-current diffs.
> > 
> > Ediff's "fine diffs" are word-granular.  That is, Ediff breaks each
> > line into "words", then passes the result to the Diff program for
> > comparisoon, and reflects the results with different faces.  AFAIR,
> > this has always been that way.
> 
> OK, so you are saying that Emacs has silently changed to (b) from (a),
> and the way it does fine diffs corresponds to what is shown.

Yes.  But Stefan now changed it back.

Therefore, I was talking only about the 2nd part of your report, which
complains that the fine diffs are incorrect.

> > > > I see both of these problematic highlightings on GNU/Linux builds from
> > > > both the trunk (bzr 117042) and the emacs-24 branch (bzr 117049).
> > 
> > I can confirm that too, but (a) I don't think the 2nd issue
> > constitutes a "problem" (see above), and (b) it is definitely not a
> > "REGRESSION", because older Emacsen behaved the same wrt fine diffs
> > inside a line.
> 
> It is a change in behavior wrt older Emacsen, which do not show fine
> diffs within the non-current diffs.

Again, that part is now gone; Emacs behaves like before: it shows fine
diffs only in the current hnunk.

> But more importantly, "REGRESSION" in the subject line is for the bug
> report, and #1 is the more serious part: removing diff highlighting
> from part of a diff gives the impression that that unhighlighted text
> is not different.

#1 is solved; do you agree that #2 is not a bug, but the intended
behavior that was always there?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.