all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* [dak@gnu.org: Re: Redraw problem with overlapping frames]
@ 2007-08-14  0:28 Richard Stallman
  2007-08-14 13:47 ` Chong Yidong
  0 siblings, 1 reply; 18+ messages in thread
From: Richard Stallman @ 2007-08-14  0:28 UTC (permalink / raw)
  To: emacs-devel

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

^ permalink raw reply	[flat|nested] 18+ messages in thread
* [dak@gnu.org: Re: Redraw problem with overlapping frames]
@ 2007-07-30 20:48 Richard Stallman
  0 siblings, 0 replies; 18+ messages in thread
From: Richard Stallman @ 2007-07-30 20:48 UTC (permalink / raw)
  To: emacs-devel

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

^ permalink raw reply	[flat|nested] 18+ messages in thread
* [dak@gnu.org: Re: Redraw problem with overlapping frames]
@ 2007-07-23 18:06 Richard Stallman
  0 siblings, 0 replies; 18+ messages in thread
From: Richard Stallman @ 2007-07-23 18:06 UTC (permalink / raw)
  To: emacs-devel

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

^ permalink raw reply	[flat|nested] 18+ messages in thread
* [dak@gnu.org: Re: Redraw problem with overlapping frames]
@ 2007-06-02 17:29 Richard Stallman
  0 siblings, 0 replies; 18+ messages in thread
From: Richard Stallman @ 2007-06-02 17:29 UTC (permalink / raw)
  To: emacs-devel

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2007-08-15 18:22 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-08-14  0:28 [dak@gnu.org: Re: Redraw problem with overlapping frames] Richard Stallman
2007-08-14 13:47 ` Chong Yidong
2007-08-14 15:03   ` David Kastrup
2007-08-14 15:59     ` Chong Yidong
2007-08-14 21:50       ` David Kastrup
2007-08-14 22:47         ` Chong Yidong
2007-08-14 22:58           ` David Kastrup
2007-08-15  6:15             ` Jan Djärv
2007-08-15  7:03               ` David Kastrup
2007-08-15  8:04                 ` Glenn Morris
2007-08-15  8:06                   ` Glenn Morris
2007-08-15 16:50                 ` Barry Fishman
2007-08-15 18:22             ` Richard Stallman
2007-08-14 23:26   ` Richard Stallman
2007-08-14 23:29     ` David Kastrup
  -- strict thread matches above, loose matches on Subject: below --
2007-07-30 20:48 Richard Stallman
2007-07-23 18:06 Richard Stallman
2007-06-02 17:29 Richard Stallman

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.