[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
--with-x-toolkit=motif'
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.
Enjoy,
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.
-Randy
-----------------------------------------------------------------------
| Simon Liddington | Tel (home): +44 23 8023 7935 |
| sjl@zepler.org | Tel (work): +44 23 8068 3521 |
-----------------------------------------------------------------------
ediff-init.el.patch
Description: Text document
- ediff highlighting bug fix,
Simon Liddington <=