[dak@gnu.org: Re: Redraw problem with overlapping frames]

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

[dak@gnu.org: Re: Redraw problem with overlapping frames]

[Richard Stallman]

[I sent this message three times 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: emacs-pretest-bug@gnu.org
From: David Kastrup <dak@gnu.org>
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 <dak@gnu.org> 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@gnu.org 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@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
------- End of forwarded message -------

Re: [dak@gnu.org: Re: Redraw problem with overlapping frames]

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

> Can someone please debug this, and ack?

Like I said in an earlier message, I haven't been able to reproduce
this at all.  Maybe a more detailed recipe and more information would
help.

> From: David Kastrup <dak@gnu.org>
> Subject: Re: Redraw problem with overlapping frames
> To: emacs-pretest-bug@gnu.org
>
> David Kastrup <dak@gnu.org> 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@gnu.org 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@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
> ----------
>
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: [dak@gnu.org: Re: Redraw problem with overlapping frames]

[David Kastrup]

[-- Attachment #1: Type: text/plain, Size: 1972 bytes --]

Chong Yidong <cyd@stupidchicken.com> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> Can someone please debug this, and ack?
>
> Like I said in an earlier message, I haven't been able to reproduce
> this at all.  Maybe a more detailed recipe and more information would
> help.
>
>> From: David Kastrup <dak@gnu.org>
>> Subject: Re: Redraw problem with overlapping frames
>> To: emacs-pretest-bug@gnu.org
>>
>> David Kastrup <dak@gnu.org> writes:
>>
>>
>> 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 append an illustration of a window configuration and a command in a
shell window that shows this effect for me.  I recompiled with the
newest sources.

It may be important (no idea) that I compiled
--without-toolkit-scroll-bars.

The effect has been visible for months, also on emacs-multitty.

In GNU Emacs 22.1.50.4 (i686-pc-linux-gnu, GTK+ Version 2.10.11)
 of 2007-08-14 on lisa
Windowing system distributor `The X.Org Foundation', version 11.0.70200000
configured using `configure  '--prefix=/usr/local/emacs-21' '--without-toolkit-scroll-bars''

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: Message

Minor modes in effect:
  mml-mode: t
  shell-dirtrack-mode: t
  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
  abbrev-mode: t


-- 
David Kastrup

[-- Attachment #2: Screenshot-emacs@lola.quinscape.zz.png --]
[-- Type: image/png, Size: 22269 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: [dak@gnu.org: Re: Redraw problem with overlapping frames]

[Chong Yidong]

David Kastrup <dak@gnu.org> writes:

> I append an illustration of a window configuration and a command in a
> shell window that shows this effect for me.

You didn't append the command.

Re: [dak@gnu.org: Re: Redraw problem with overlapping frames]

[David Kastrup]

Chong Yidong <cyd@stupidchicken.com> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> I append an illustration of a window configuration and a command in a
>> shell window that shows this effect for me.
>
> You didn't append the command.

It is in the screen shot, after the shell prompt.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [dak@gnu.org: Re: Redraw problem with overlapping frames]

[Chong Yidong]

David Kastrup <dak@gnu.org> writes:

> Chong Yidong <cyd@stupidchicken.com> writes:
>
>> David Kastrup <dak@gnu.org> writes:
>>
>>> I append an illustration of a window configuration and a command in a
>>> shell window that shows this effect for me.
>>
>> You didn't append the command.
>
> It is in the screen shot, after the shell prompt.

I am still unable to reproduce this bug.  Could you give a detailed
and precise recipe?  Also, what window manager are you using?

Re: [dak@gnu.org: Re: Redraw problem with overlapping frames]

[David Kastrup]

Chong Yidong <cyd@stupidchicken.com> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Chong Yidong <cyd@stupidchicken.com> writes:
>>
>>> David Kastrup <dak@gnu.org> writes:
>>>
>>>> I append an illustration of a window configuration and a command in a
>>>> shell window that shows this effect for me.
>>>
>>> You didn't append the command.
>>
>> It is in the screen shot, after the shell prompt.
>
> I am still unable to reproduce this bug.  Could you give a detailed
> and precise recipe?  Also, what window manager are you using?

It is Metacity, standard GNOME setup on Ubuntu.  However, you might be
onto something: my computer at home, with identical Ubuntu version and
identically configured Emacs does not show this effect.

So it might be the X server or display drivers.  Some sort of ATI
thingy.  No idea what alternatives I could try.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [dak@gnu.org: Re: Redraw problem with overlapping frames]

[Jan Djärv]

David Kastrup skrev:
> Chong Yidong <cyd@stupidchicken.com> writes:
> 
>> David Kastrup <dak@gnu.org> writes:
>>
>>> Chong Yidong <cyd@stupidchicken.com> writes:
>>>
>>>> David Kastrup <dak@gnu.org> writes:
>>>>
>>>>> I append an illustration of a window configuration and a command in a
>>>>> shell window that shows this effect for me.
>>>> You didn't append the command.
>>> It is in the screen shot, after the shell prompt.
>> I am still unable to reproduce this bug.  Could you give a detailed
>> and precise recipe?  Also, what window manager are you using?
> 
> It is Metacity, standard GNOME setup on Ubuntu.  However, you might be
> onto something: my computer at home, with identical Ubuntu version and
> identically configured Emacs does not show this effect.
> 
> So it might be the X server or display drivers.  Some sort of ATI
> thingy.  No idea what alternatives I could try.

What X display driver are you using?  If it is the ATI one, you can try the 
generic vesa driver.  Or the other way around.  There is also the radeon 
driver, but it doesn't support all cards (man radeon).

	Jan D.

Re: [dak@gnu.org: Re: Redraw problem with overlapping frames]

[David Kastrup]

Jan Djärv <jan.h.d@swipnet.se> writes:

> David Kastrup skrev:
>> Chong Yidong <cyd@stupidchicken.com> writes:
>>
>>> David Kastrup <dak@gnu.org> writes:
>>>
>>>> Chong Yidong <cyd@stupidchicken.com> writes:
>>>>
>>>>> David Kastrup <dak@gnu.org> writes:
>>>>>
>>>>>> I append an illustration of a window configuration and a command in a
>>>>>> shell window that shows this effect for me.
>>>>> You didn't append the command.
>>>> It is in the screen shot, after the shell prompt.
>>> I am still unable to reproduce this bug.  Could you give a detailed
>>> and precise recipe?  Also, what window manager are you using?
>>
>> It is Metacity, standard GNOME setup on Ubuntu.  However, you might be
>> onto something: my computer at home, with identical Ubuntu version and
>> identically configured Emacs does not show this effect.
>>
>> So it might be the X server or display drivers.  Some sort of ATI
>> thingy.  No idea what alternatives I could try.
>
> What X display driver are you using?  If it is the ATI one, you can
> try the generic vesa driver.  Or the other way around.  There is also
> the radeon driver, but it doesn't support all cards (man radeon).

name of display:    :0.0
version number:    11.0
vendor string:    The X.Org Foundation
vendor release number:    70200000
X.Org version: 7.2.0
maximum request size:  16777212 bytes
motion buffer size:  256
bitmap unit, bit order, padding:    32, LSBFirst, 32
image byte order:    LSBFirst
number of supported pixmap formats:    7
supported pixmap formats:
    depth 1, bits_per_pixel 1, scanline_pad 32
    depth 4, bits_per_pixel 8, scanline_pad 32
    depth 8, bits_per_pixel 8, scanline_pad 32
    depth 15, bits_per_pixel 16, scanline_pad 32
    depth 16, bits_per_pixel 16, scanline_pad 32
    depth 24, bits_per_pixel 32, scanline_pad 32
    depth 32, bits_per_pixel 32, scanline_pad 32
keycode range:    minimum 8, maximum 255
focus:  window 0x2b60be1, revert to Parent
number of extensions:    33
    ATIFGLEXTENSION
    ATIFGLRXDRI

[...]

screen #0:
  dimensions:    1680x1050 pixels (331x212 millimeters)
  resolution:    129x126 dots per inch
  depths (7):    24, 1, 4, 8, 15, 16, 32
  root window id:    0x79
  depth of root window:    24 planes
  number of colormaps:    minimum 1, maximum 1
  default colormap:    0x20
  default number of colormap cells:    256
  preallocated pixels:    black 0, white 16777215
  options:    backing-store NO, save-unders NO

display: :0.0  screen: 0
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: ATI Mobility Radeon X1400
OpenGL version string: 2.0.6458 (8.36.5)

I have not much success with other drivers.  Indeed, not even with the
driver after that (it refused to suspend).

-- 
David Kastrup

Re: [dak@gnu.org: Re: Redraw problem with overlapping frames]

[Glenn Morris]

David Kastrup wrote:

> OpenGL vendor string: ATI Technologies Inc.
> OpenGL renderer string: ATI Mobility Radeon X1400
> OpenGL version string: 2.0.6458 (8.36.5)
>
> I have not much success with other drivers.  Indeed, not even with the
> driver after that (it refused to suspend).

I was able to reproduce the effect in your image, using the command
you gave. In detail:

 emacs -q --no-site-file -f make-frame ~/.emacs
 arrange two frames side by side with a vertical offset of a few
 lines, overlapping a bit in the middle.
 put .emacs in the frame lower down the screen
 run M-x shell in the other frame
 run in shell:
 for ((i=0;;i++)); do
  printf "%d " $i
 done
 click in the .emacs frame to focus it (I use focus follows mouse).

Immediately the line in the shell frame just above the top of the
other frame is corrupt.

I am also using the ATI driver (for a mobility radeon x600). I could
never reproduce the effect with the Xorg radeon or vesa drivers. It
happens every time with the ATI driver. I can try an nvidia system
tomorrow. The ATI driver has a lot of options, maybe there is one that
will ameliorate this effect.

Re: [dak@gnu.org: Re: Redraw problem with overlapping frames]

[Glenn Morris]

Glenn Morris wrote:

> I was able to reproduce the effect in your image, using the command

PS I was using Window Maker under Debian testing, so it's not the WM
it seems.

Re: [dak@gnu.org: Re: Redraw problem with overlapping frames]

[Barry Fishman]

David Kastrup <dak@gnu.org> writes:
>> David Kastrup skrev:
>>> It is Metacity, standard GNOME setup on Ubuntu.  However, you might be
>>> onto something: my computer at home, with identical Ubuntu version and
>>> identically configured Emacs does not show this effect.
>>>
>>> So it might be the X server or display drivers.  Some sort of ATI
>>> thingy.  No idea what alternatives I could try.
> ...
> screen #0:
>   dimensions:    1680x1050 pixels (331x212 millimeters)
>   resolution:    129x126 dots per inch
>   depths (7):    24, 1, 4, 8, 15, 16, 32
>   root window id:    0x79
> ...
> display: :0.0  screen: 0
> OpenGL vendor string: ATI Technologies Inc.
> OpenGL renderer string: ATI Mobility Radeon X1400
> OpenGL version string: 2.0.6458 (8.36.5)
>
> I have not much success with other drivers.  Indeed, not even with the
> driver after that (it refused to suspend).

I have this problem under debian etch and SuSE.  It seems to be do
to a combination of the ATI Proprietary drivers and a 1680x1050
display resolution.  I does not happen when I use a 1280x1024 monitor.

It also happens when I don't have emacs running.  Overlapped urxvt and
mlterm (but not xterm windows) will show the effect when they are the
bottom of two overlapping windows and are scrolled.

I think is a problem (among many others) with the ATI proprietary
drivers.
-- 
Barry Fishman

Re: [dak@gnu.org: Re: Redraw problem with overlapping frames]

[Richard Stallman]

    It is Metacity, standard GNOME setup on Ubuntu.  However, you might be
    onto something: my computer at home, with identical Ubuntu version and
    identically configured Emacs does not show this effect.

    So it might be the X server or display drivers.  Some sort of ATI
    thingy.  No idea what alternatives I could try.

I think that means it is probably not an Emacs bug, and there is
probably nothing we need to do.

Re: [dak@gnu.org: Re: Redraw problem with overlapping frames]

[Richard Stallman]

Perhaps you can tell David some commands to type so as to get
more information.

Re: [dak@gnu.org: Re: Redraw problem with overlapping frames]

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> Perhaps you can tell David some commands to type so as to get
> more information.

I'll try extracting some X server information.  It might be a bug in
the X server, or a special combination of "save under" or similar
capabilities.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

[dak@gnu.org: Re: Redraw problem with overlapping frames]

[Richard Stallman]

[I sent this message twice 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: emacs-pretest-bug@gnu.org
From: David Kastrup <dak@gnu.org>
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 <dak@gnu.org> 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@gnu.org 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@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
------- End of forwarded message -------

[dak@gnu.org: Re: Redraw problem with overlapping frames]

[Richard Stallman]

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