[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ediff highlighting bug fix

From: Simon Liddington
Subject: ediff highlighting bug fix
Date: Mon, 2 Jul 2001 13:55:25 +0100 (BST)

In GNU Emacs 20.7.1 (sparc-sun-solaris2.7, Motif)
 of Thu Jun 21 2001 on tigger
configured using `configure  -v --prefix=/export/home1/sl/local --with-x 

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

ediff sometimes highlights diffs incorrectly. Hitting Ctrl-l
(ediff-recenter) repeatedly gives random different results.

I traced the problem and found that the priority for the overlay was
becoming very large and then negative. This was due to two things.

1) ediff-highest-priority was adding together all the overlay priorities
for the diff region not just giving a max value.

2) ediff-highlight-diff-in-one-buffer moved the overlay before computing
the new highest priority and so was including the previous highest
priority in its highest priority calculation.

This basically meant that the highest priority at least doubled each
time, eventually becoming negative due to overflow.

Below is a changelog entry for the attached patch and below that a
past bug report about the same thing.

Simon Liddington

2001-07-02  Simon Liddington  <sjl@zepler.org>

        * ediff-init.el (ediff-highest-priority): Returns 1 + max of all
        overlay priorities not 1 + sum of all overlay priorities.

        * ediff-init.el (ediff-highlight-diff-in-one-buffer): Move current
        overlay after calculating priority for new diff region so that
        highest priority does not keep increasing (except when
        redisplaying same diff).

Previous bug report:

>From: Randy Gobbel (gobbel@andrew.cmu.edu)
 Subject: Ediff highlighting broken in emacs 20.3 (overlay bug?)
 Newsgroups: gnu.emacs.bug
 Date: 1998/09/26

This bug report will be sent to the Free Software Foundation,
 not to your local site managers!!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

In GNU Emacs 20.3.2 (i386-debian-linux-gnu, X toolkit)
 of Tue Sep  1 1998 on raven
configured using `configure  i386-debian-linux-gnu --prefix=/usr 
--sharedstatedir=/var/lib --libexecdir=/usr/lib --localstatedir=/var/lib 
--infodir=/usr/info --with-pop=yes --with-x=yes --with-x-toolkit=yes'

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

In the last couple of versions of emacs (perhaps 20.x versions), ediff
highlighting behaves erratically.  Sometimes diff regions are displayed with a
white (i.e., default) background and brick-red or purple text, rather than
with a green, cyan, or yellow background and brick-red or black text.
Repeatedly typing ^L, which calls ediff-recenter, produces random results,
with any possible combination of broken or correct highlighting in one or both
windows.  I traced this in the elisp debugger to where it calls into
move-overlay, leading me to believe that the problem is the result of a bug in
the overlay code.  As far as I know there have not been any changes in ediff
that could have caused this problem.


| Simon Liddington                 | Tel (home): +44 23 8023 7935     |
| sjl@zepler.org                   | Tel (work): +44 23 8068 3521     |

Attachment: ediff-init.el.patch
Description: Text document

reply via email to

[Prev in Thread] Current Thread [Next in Thread]