[Bug: 21.4.17] FreeBSD 6, Gnome 2.12.1, Xemacs 21.4 spews BadWindow errors.

[Ben Wing]

Stephen J. Turnbull wrote:

>>>>>>"George" == George Hartzell <hartzell at 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)}.