Nautilus, xemacs, ssh -Y, and BadWindow messages.

[George Hartzell]

Joe Marcus Clarke writes:
 > On Tue, 2005-06-28 at 09:46 -0700, George Hartzell wrote:
 > > Hi all,
 > > [...]
 > > There are more details in the bug.
 > > 
 > > 	ports/82498
 > > [...]
 > 
 > I think Nautilus is a red herring.  The real problem is most likely
 > gnome-settings-daemon and its tendency to merge xrdb data into your
 > current environment.  You could hack the xrdb support out of g-s-d, or
 > simply override the default Emacs resource settings with your own
 > ~/.gnome2/xrdb/Emacs.ad file. 
 > 

I don't think that this is has anything to do with resource settings.
You helped me work through that back in 2003, here's a pointer to the
start of that thread:

  http://lists.freebsd.org/pipermail/freebsd-gnome/2003-October/003503.html

In this case, I can start nautilus, kill a line in an xemacs and see
the error, stop nautilus, kill a line in an xemacs and not see an
error, start nautilus, etc....

Using 'xlsclients -al', the nautilus window id is the closest to the
window id that's reported in the error message (they're always a bit
off, which I assume has to do with the way that X apps are constructed
in nested windows).  For instance, I just generated a pair of error
messages w/ the

  Resource id in failed request: 0x1c0034a

xlsclients -al says that the window for Nautilus is

  Window 0x1c00001

xwininfo and clicking on the background says:

  xwininfo: Window id: 0x1c0002c "Desktop"

xinfinfo -id 0xc0034a says there there is no such window.

And, I just noticed that every time that I generate the error message
the "Resource id in failed request" increments a bit (but not by the
same amount)....

I started messing about in the xemacs code, changing it to use the
'PRIMARY selection instead of the 'CLIPBOARD, and that also quiets the
error (I'm not sure I'm using the terms PRIMARY, CLIPBOARD, selection,
etc... in the completely correct technical sense).

Using ssh -Y to connect back to the same machine doesn't seem to
trigger it, but ssh -Y'ing into a jail on that machine does.

I haven't been able to try it yet w/out using an ssh tunnel, just
setting DISPLAY to point back to the host-machine's display.  That's
my next simple step.

I'm pretty open minded at this point, it could be an xemacs problem,
an ssh problem, or a nautilus problem (or, ssh tunnelling mucking up
an improper window id that xemacs generates when it sees the Nautilus
background window), or....

I'm just looking for suggestions for experiments to help characterize
it.  For instance, running nautilus with either --no-desktop or
--no-default-window does not get rid of the problem.

Any interesting debugging switches, sniffing methods, etc.... would be
welcome.

g.