obscure Emacs redisplay bug

[rudalics@gmx.at]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 5538 bytes --]

Let me tell you about an obscure bug that garbles a few lines of text
during Emacs redisplay.  The "original" text can be restored by typing
C-l or by moving the cursor over it, that's why I relate the bug to
redisplay.  Unfortunately, it's non-trivial to reproduce the bug.  I've
been using Emacs 21.2 on Debian Linux and 21.2/21.3 on Windows ME and a
window displaying the following stretch of code:


------------------------- top of window -------------------
(defun foo ()
  "A
silly
function called foo."
  (and
   (or (not nil)
       t
       (not (not t)))
   t
   (or nil
       t
       t)))

(defun bar ()
  "Another
silly
function called bar."
  (and
   (or (not nil)
       t
       (not t))
   (not t)
   (or (not nil)
       t
       t)))




I now clone the code's buffer, vertically split the window, and display
the indirect buffer in the right window.  In addition I use a number of
overlays, namely:

(1) Invisibility overlays represented by an ellipsis

(2) An "ECHO" overlay displaying text in some face

(3) "MATCH" overlays displaying text in another face

(4) A "CURRENT" overlay displaying text in a third face

I shall indicate start and end of ECHO with square brackets, and start
and end of CURRENT with angle brackets.  `point' is invariantly before
the first character of CURRENT.  I won't bother to indicate MATCH
overlays: They span every single occurrence of `nil' in the right
window.  My right window now appears as follows:


------------------------- top of window -------------------
  (and
   (or (not nil)
       t
       (not (not t)))
   t
   (or <nil>
       t
       t)))
]
(defun bar ()
...
function called bar."
  (and
   (or (not nil)
       t
       (not t))
   (not t)
   (or (not nil)
       t
       t)))




Hence ECHO starts somewhere at or before `window-start' and CURRENT is
on the second visible `nil'.  The first two lines of the documentation
string of `bar' have been replaced by an ellipsis.  `selected-window' is
the left window which simply displays the numbers of the lines of
occurrences of `nil' in the right window.  I now move in the left window
down by one line which implicitly causes a recentering of the right
window and a relocation of ECHO and CURRENT:


------------------------- top of window -------------------
       t)))

[(defun bar ()
...
function called bar."
  (and
   (or (not <nil>)
       t
       (not t))
   (not t)
   (or (not nil)
       t
       t)))
]



Thus ECHO now spans the entire code of `bar' and CURRENT the first
occurrence of `nil' in `bar'.  Finally, I move in the left window up by
one line which should restore the previous state of the right window:


------------------------- top of window -------------------
  (and
   (or (not nil)
       t
       (not (not t)))
   t
   (or <nil>
       t
       t)))
]
(defun bar ()
...
       t called bar." 
  (and
   (or (not nil)
       t
       (not t))
   (not t)
   (or (not nil)
       t
       t)))




However, the last line of the documentation string of `bar' originally
reading

function called bar."

has been replaced by a line reading

       t called bar."

where all characters preceding `called' are decorated with the ECHO
overlay face.

Switching to the right window now implicitly removes all overlays.  The
incriminated line, however, is not restored.  As mentioned above, I can
restore the original text by simply moving over it.  Moving by one
character restores one character of the original text.  C-l will also
restore the original text but this seems less indicative to me since on
a "suitably" centered window the bug wouldn't have shown up in the first
place.

Obviously the bug may be traced back to some sillyness I wrote myself.
However, I was not able to reproduce it when I replaced one single
character of any of the identical lines of `foo' or `bar', namely the
two lines

   (or (not nil)
       t

and the two lines reading

       t
       t)))

with a different character.  I conjecture that the combined effects of
changing the window start of an indirect buffer with invisibility and
other overlays vex some redisplay routine based on the comparison of
identical pieces of text.

Variants of the bug with two or more obscured lines exist.  Common to
all of them is:

(1) The ECHO overlay gets relocated to some position nearer to
    `point-min' and near the top of the window it appears.

(2) An invisibility overlay precedes the obscured lines.

(3) Two instances of identic text blocks comprising at least two lines
    exist.  Only text appearing in these blocks obscurs other text.

(4) Obscuring text appears at precisely the same window position
    occupied by identic text before redisplay.

The indirect buffer is never modified.  Switching on/off font-locking
has no impact on the outcome.

The scenario sketched above could only describe the symptoms of the bug.
Please tell me if you want to reproduce them with my code.  Be warned:
It's some 7000 elisp lines long.

In GNU Emacs 21.3.1 (i386-mingw-windows98.3000)
 of 2004-03-10 on NYAUMO
configured using `configure --with-gcc (3.2)'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: dea
  locale-coding-system: iso-latin-1
  default-enable-multibyte-characters: t

-- 
DSL Komplett von GMX +++ Supergünstig und stressfrei einsteigen!
AKTION "Kein Einrichtungspreis" nutzen: http://www.gmx.net/de/go/dsl