Redraw problem with overlapping frames

[David Kastrup]

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 emacs-pretest-bug@... 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.





In GNU Emacs 23.0.51.5 (i686-pc-linux-gnu, GTK+ Version 2.10.11, multi-tty)
 of 2007-05-25 on lisa
Windowing system distributor `The X.Org Foundation', version 11.0.70200000
configured using `configure  '--prefix=/usr/local/emacs-21' '--with-gtk' '--without-toolkit-scroll-bars' 'CFLAGS=-g -O2 -fno-crossjumping''

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: en_US.UTF-8
  locale-coding-system: utf-8
  default-enable-multibyte-characters: t

Major mode: PDFTeX

Minor modes in effect:
  TeX-PDF-mode: t
  server-mode: t
  desktop-save-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  line-number-mode: t

Recent input:
<return> n <return> SPC SPC E q <return> SPC n n q
g q y M-x e m a c s - v e r <tab> <return> <S-print>
M-x e m a c s <f12> - v e r <tab> <return> <C-print>
M-x e m a c s - v e r <tab> <return>

Recent messages:
GNU Emacs 23.0.51.5 (i686-pc-linux-gnu, GTK+ Version 2.10.11, multi-tty) of 2007-05-25 on lisa [3 times]

Loading emacsbug...done

--
David Kastrup

_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@...
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

[David Kastrup]

David Kastrup <dak@...> 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 emacs-pretest-bug@... 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
emacs-pretest-bug@...
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

[Chong Yidong]

David Kastrup <dak@...> writes:

>> 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.

I haven't been able to reproduce this at all.



_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@...
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug