address@hidden: Re: Redraw problem with overlapping frames]

[Richard Stallman]

[I sent this message several weeks ago but did not get a response.]

Can someone please debug this, and ack?

------- Start of forwarded message -------
X-Spam-Status: No, score=-0.0 required=5.0 tests=SPF_HELO_PASS,SPF_PASS,
        UNPARSEABLE_RELAY autolearn=failed version=3.1.0
To: address@hidden
From: David Kastrup <address@hidden>
Date: Wed, 30 May 2007 16:13:08 +0200
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Re: Redraw problem with overlapping frames

David Kastrup <address@hidden> writes:

> Please write in English if possible, because the Emacs maintainers
> usually do not have translators to read other languages for them.
>
> Your bug report will be posted to the address@hidden mailing list.
>
> Please describe exactly what actions triggered the bug
> and the precise symptoms of the bug:
>
> When I have overlapping frames and issue a command in the lower frame
> that will cause the minibuffer to be extended in size (here:
> emacs-version), then after the resize, there is redraw cruft in the
> lower frame (which disappears once the minibuffer is shrunk again).
> One can't consistently trigger this, and the probability of getting
> this behavior is much lower when compared to versions from the
> beginning of the year.  I would not recommend trying to fix this in
> EMACS_22_BASE as the effect lasts only temporarily (until the
> minibuffer gets shrunk again).  For Emacs 23, however, one might want
> to see how it is triggered.
>
> I have only ever seen this effect with overlapping Emacs frames from
> the same session: overlapping frames from other applications possibly
> don't trigger it (no guarantees, though).  I include a screenshot.

Uh, no guarantees...  It turns out that when I place something like a
shell window partially obscuring an Emacs frame with, say, a shell
buffer running some compilation, then I get lots of display cruft in
the Emacs frame.  The cruft occurs in
a) the top line partially obscured by the obscuring window
b) below the bottom line partially obscured

It would appear that scrolling does copy the material in the partially
obscured cases, but fails to clear the partial lines before
resp. after moving the displayed material at top resp. bottom.

- -- 
David Kastrup



_______________________________________________
emacs-pretest-bug mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
------- End of forwarded message -------