Re: [Bug: 21.4.17] FreeBSD 6, Gnome 2.12.1, Xemacs 21.4 spews BadWindow errors.
Stephen J. Turnbull wrote:
>>>>>"George" == George Hartzell
<hartzell(a)kestrel.alerce.com> writes:
>>>>>
>>>>>
George> Whenever I type a bit of text into xemacs and "kill" it
George> (e.g. move to the beginning of the line hit control-k), I
George> get a pair of messages in the xterm window from which I
George> started xemacs:
George> It only happens when nautilus is running.
As far as I know this is harmless, except that it messes up your
terminal screen.
It's possible that it's an XEmacs bug, but the last time I tried to
debug this I put a trace on the window creation function and those are
definitely not XEmacs's windows. We may have misimplemented the
protocol (see below), but the folks who did that work were pretty
wizardly.
Caveat: I don't understand the following, I'm just repeating what
somebody else diagnosed.
Apparently some applications misuse the X selection, by setting the
owner to a window that they later destroy without disowning the
selection. The X selection (or maybe it's the clipboard) protocol
requires some communication with the former owner when this is done,
but that window no longer exists so you get the bad resource message.
GNOME applications are apparently especially prone to this behavior.
well, we can "fix" this by just swallowing the x error. there is a
function expect_x_error() that's meant to be used prior to a call that
may produce an x error that we want to trap. after the call, use
x_error_occurred_p() to put things back to normal (and return whether an
error occurred). but you need to figure out which call is producing the
error; see FAQ 2.4.4. note especially the following:
＠item
If XEmacs is outputting lots of X errors, put a breakpoint on
＠code{x_error_handler()}; that will tell you which call is causing
them. Note that the result may not be very useful by default because
X Windows normally operates asynchronously: A bunch of commands are
buffered up and then sent to the server all at once. This greatly
improves performance over a network but means that an error may not be
reported until the server receives the commands, which can be long
after XEmacs made the erroneous calls. For best results, you need to
make the X server synchronous before getting the backtrace. This can
be done by starting XEmacs with the ＠samp{-sync} option or executing
the Lisp code ＠code{(x-debug-mode t)}.