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

Previous Next

Full log

Message #34 received at 17388 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Drew Adams <drew.adams <at> oracle.com>
Cc: 17388 <at> debbugs.gnu.org, kifer <at> cs.stonybrook.edu, monnier <at> iro.umontreal.ca
Subject: RE: bug#17388: 24.4.50;	REGRESSION: Ediff - 1) wrong face, 2)
 incorrect diffing
Date: Sat, 3 May 2014 13:56:13 -0700 (PDT)

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

He did?  I thought he fixed only #1: the use of face `default'.
I didn't think that he also got rid of the new fine-diffing for
non-current diffs.  If he did, then both #1 and #2 should presumably
be fixed.

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

If Stefan got rid of the change to fine-diffing for non-current diffs
then it doesn't matter whether that fine-diffing was inaccurate.

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

OK, if you say so.  Great.  I didn't notice that in the patch he sent.

> > 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?

#2 was that non-current diffs were being fine-diffed, and that
fine-diffing was inaccurate.  It was explained to me that fine-diffing
is inaccurate in this way generally.  IOW, this has nothing to do with
the fact that they were now applied to non-current diffs.

If fine-diffing is inaccurate in general (call it word-diffing or
whatever, if that helps), then so be it.  I am OK with #1 being fixed.

I am OK with #2 also being reverted to not showing fine diffs for
non-current.  I am OK also with fine diffs being shown for non-current
(given that #1 is fixed, so they are not shown with face `default').

I understand now that the inaccuracy of fine diffs that I pointed out
is apparently general and not something new for only non-current fine
diffing.

Previous Next

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