On Sun, Nov 02, 2003 at 02:51:47PM +0900, Stephen J. Turnbull wrote:
>>>>> "Scott" == Scott Blachowicz
Scott> I sometimes run it in a tty (well...putty window on an XP
Scott> box ssh'd into a Linux box, with no X display). [...] It
Scott> tries to take over my shell-mode buffer as a tty and run an
Scott> xemacs within it (presumably not a separate xemacs process,
Scott> but my existing xemacs process thinking that my shell-mode
Scott> buffer is a tty that it has to operate within).
That's exactly what it is supposed to do. It looks for a GUI display
to connect to, there isn't one (that accepts connections), so it tries
to use gnuclient's controlling TTY. XEmacs makes up for a lot of the
design flaws in Windows, but working around this one would require
rootkitting your Windows box, and we aren't script kiddies.
This has nothing to do with Windoze - it's because I don't have a GUI
display to connect to and because this used to work better in previous
Scott> Any suggestions on getting this to work?
fdisk comes to mind, then install an open OS with a windowing system
that can accept connections from the network. :-)
Yeah, yeah...that's not really a feasible solution (much as I'd like to
A more palatable alternative might be to run XEmacs locally on the
Windows box and use Tramp to remote access files on the Linux box.
However, Windows XP is not a properly supported platform; apparently
programming techniques that work for other Windows OSes don't work
there, and we've had a rash of bug reports which AFAIK have not been
That doesn't help...the problem is that when I run 'gnuclient' it doesn't
just attach to my existing xemacs and get new buffers, it tries to display
those buffers on the tty being run by my shell-mode.
A third possibility would be to install an X server.
Yes - that would help (by masking the real problem :)).
Scott> (like it used to with xemacs 21.1.8, and other
Scott> I've used)
Not on a Windows XP display, or any Windows display, it didn't.
I think I'm not explaining my problem well then...let's try again...
I believe that the type of OS reading my keyboard is irrelevant here...
1) I ssh into a Linux box
2) run 'xemacs -q'
3) Within xeamcs, do `M-x gnuserv-start'
4) Within xemacs, do `M-x shell'
5) Within the *shell* buffer, type 'gnuclient foobar'
At this point, if I have a usable $DISPLAY setting, I would get a new
frame. If I do NOT have a usable $DISPLAY, it complains about:
IO Error: Terminal type undefined (or can't access database?), "emacs"
in my minibuffer line from which I infer that it's trying to use the $TERM
setting to decide if it can run an xemacs buffer inside of it instead
of getting the xemacs to new buffer in the term it is already running
within. If I change my TERM setting in the shell in the shell-mode buffer
to something like "xterm" , it confirms that by showing me lots of nice
escape sequences in my shell-mode buffer.
Hmmm...in doing that repro case, I notice that xemacs 21.1.8 gives a
similar error, so that's not the right repro case.
What I was actually doing before was...I had an xemacs running against my X
server at work. From home, I ssh into my work system (no X11 forwarding)
at which point, my work xemacs (and gnuserv) responds by giving me a 'foo'
buffer within the tty of my ssh session. Then I do `C-x b *shell* RET' to
get to my shell buffer and continue on my merry way. At some point, I do
a command in my shell buffer that ends up running gnuclient. With xemacs
21.1.8 (the pre-existing version on my work system), it wouldn't complain,
but it also wouldn't show me the buffer right away - I would have to use
`C-x b' to get to it, but it was there (so not really working right, but
usable). With xemacs 21.5b16, it prevented me from getting that far. At
this point (being at home), I'm having trouble getting things back into a
state where I can reproduce this...so that's just my memory for now. :)
Anyways...it'd be nice if the xemacs could track the tty that was in use by
its own shell buffers to be able to detect gnuclient runs from within those
shells and handle them.