[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: |
Eli Zaretskii |
Subject: |
bug#17388: 24.4.50; REGRESSION: Ediff - 1) wrong face, 2) incorrect diffing |
Date: |
Sat, 03 May 2014 09:48:27 +0300 |
> Date: Fri, 2 May 2014 20:11:54 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 17388-done@debbugs.gnu.org, Michael Kifer <kifer@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.
The Ediff manual says:
`ediff-forward-word-function'
This variable controls how fine differences are computed. The
value must be a Lisp function that determines how the current
difference region should be split into words.
Fine differences are computed by first splitting the current
difference region into words and then passing the result to
`ediff-diff-program'. For the default forward word function
(which is `ediff-forward-word'), a word is a string consisting of
letters, `-', or `_'; a string of punctuation symbols; a string of
digits, or a string consisting of symbols that are neither space,
nor a letter.
This default behavior is controlled by four variables:
`ediff-word-1', ..., `ediff-word-4'. See the on-line
documentation for these variables and for the function
`ediff-forward-word' for an explanation of how to modify these
variables.
I think what you describe in your item #2 is exactly the above
behavior. (The problem described under #1 is now fixed by Stefan.)
> Stephen Berman's confirmation indicates that Cygwin `diff' is
> irrelevant:
>
> > 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.
- 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 <=
- 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, 2014/05/03
- 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