[Bug: 21.4.12] xemacs: X Error of failed request: BadWindow(invalid Window parameter)

[Glynn Clements]

Darryl Okahata wrote:

> > Ok, here it is.  Could not quickly get it to exit() when using
> > (x-debug-mode t), but it did produce the error msg reliably.
> 
> This is weird (but I'm not familiar with the code):

I've spent some time looking into similar errors in the past; I made
some comments in:

http://list-archive.xemacs.org/xemacs-beta/200309/msg00056.html

The same factors apply to Michael's report.

> * The stack trace is strangely recursive: execute_internal_event() gets
>   recursively called five times, mostly via wait_delaying_user_input().
> 
> * Selections are involved.  I seem to recall that there are issues with
>   selections, X, and/or Motif.  I have the following in my init.el, and
>   you might want to see if these make a difference for you:
> 
>     ;; Setting this to nil dramatically improves responsiveness when
>     ;; killing text.  If x-selection-strict-motif-ownership is non-nil,
>     ;; the clipboard is "owned in the Motif Way", which generates a
>     ;; sh*tload of X protocol traffic, but insures that cut and paste
>     ;; works correctly.  If x-selection-strict-motif-ownership is nil, the
>     ;; amount of protocol traffic is greatly lessened, but cut-and-paste
>     ;; may not always work correctly with Motif widgets.
>     ;(setq x-selection-strict-motif-ownership nil)
> 
>     ;;; Similar to above, but more correct?  from Glynn Clements
>     (setq interprogram-cut-function nil)
>     (setq interprogram-paste-function nil)

The last two simply prevent XEmacs' kill/yank operations (C-w, M-w,
C-y etc) from setting or using the clipboard; you have to use C-ins
and Sh-ins for copy/paste between programs. This can be a big
performance gain if you have a (slow) remote X connection.

The first one is a fudge which makes inter-program cut/copy faster at
the expense of making it less reliable (if you do: copy, switch to
another application, paste, switch back, copy something else, switch,
paste, the second paste will paste the contents from the first copy,
not the second).

I'd suggest using the last two and not the first. The speed of copying
to the clipboard is only really an issue when every kill-like
operation copies to the clipboard (i.e. when interprogram-cut-function
is set to 'own-clipboard).

-- 
Glynn Clements <glynn at gclements.plus.com>