[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#17388: 24.4.50; REGRESSION: Ediff - 1) wrong face, 2) incorrect diff
From: |
Drew Adams |
Subject: |
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.
- bug#17388: 24.4.50; REGRESSION: Ediff - 1) wrong face, 2) incorrect diffing, Drew Adams, 2014/05/02
- bug#17388: 24.4.50; REGRESSION: Ediff - 1) wrong face, 2) incorrect diffing, Stephen Berman, 2014/05/02
- bug#17388: 24.4.50; REGRESSION: Ediff - 1) wrong face, 2) incorrect diffing, Stefan Monnier, 2014/05/02
- bug#17388: 24.4.50; REGRESSION: Ediff - 1) wrong face, 2) incorrect diffing, Drew Adams, 2014/05/02
- bug#17388: 24.4.50; REGRESSION: Ediff - 1) wrong face, 2) incorrect diffing, Eli Zaretskii, 2014/05/03
- bug#17388: 24.4.50; REGRESSION: Ediff - 1) wrong face, 2) incorrect diffing, Drew Adams, 2014/05/03
- bug#17388: 24.4.50; REGRESSION: Ediff - 1) wrong face, 2) incorrect diffing, Eli Zaretskii, 2014/05/03
- bug#17388: 24.4.50; REGRESSION: Ediff - 1) wrong face, 2) incorrect diffing,
Drew Adams <=
- Message not available
- bug#17388: 24.4.50; REGRESSION: Ediff - 1) wrong face, 2) incorrect diffing, Michael Kifer, 2014/05/03
- bug#17388: 24.4.50; REGRESSION: Ediff - 1) wrong face, 2) incorrect diffing, Drew Adams, 2014/05/03
- bug#17388: 24.4.50; REGRESSION: Ediff - 1) wrong face, 2) incorrect diffing, Stefan Monnier, 2014/05/03
- bug#17388: 24.4.50; REGRESSION: Ediff - 1) wrong face, 2) incorrect diffing, Drew Adams, 2014/05/04