On Sun, Nov 02, 2003 at 02:51:47PM +0900, Stephen J. Turnbull wrote: 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 xemacs releases. Yeah, yeah...that's not really a feasible solution (much as I'd like to :))... 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. Yes - that would help (by masking the real problem :)). 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) and do gnuclient foo 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. Scott

Hrvoje Niksic wrote: Scott: I think that you want this: (setq gnuserv-frame t) or this: M-x customize-variable RET gnuserv-frame RET C-h v gnuserv-frame: `gnuserv-frame' is a variable declared in Lisp. -- loaded from "gnuserv" Value: t Documentation: *The frame to be used to display all edited files. If nil, then a new frame is created for each file edited. If t, then the currently selected frame will be used. If a function, then this will be called with a symbol `x' or `tty' as the only argument, and its return value will be interpreted as above. -- Glynn Clements <glynn.clements(a)virgin.net&gt;

Hrvoje Niksic <hniksic(a)xemacs.org&gt; wrote: I have this set now: (defun sab:gnuserv-frame (arg) (if (eq arg 'tty) t) ) (setq gnuserv-frame 'sab:gnuserv-frame) (gnuserv-start) But it doesn't quite do everything I'd like: 1) Run xemacs on X display with the above gnuserv-frame setting, then run gnuclient with DISPLAY set to the same thing -> get new frame for new buffer (no problem). 2) Run xemacs on X display as above. Then run gnuclient from a shell with no DISPLAY setting. The above function returns t (which I verified by dumping the returned value to a separate buffer) and I get my new buffer displayed in the frame that I have on my X display (not good as I'm probably not sitting in front of that X display at the time). 3) Run xemacs on X display, but with gnuserv-frame explicitly set to nil. Then run gnuclient from a shell with no DISPLAY setting. I get my new buffer displayed in my tty as I want. 4) Do #3, then switch to the *shell* buffer I have in the xemacs session and run another 'gnuclient'. I get the error: IO Error: Terminal type undefined (or can't access database?), "emacs" 5) Do #3, #4, then explicitly do (setq gnuserv-frame t) in that *shell* buffer. Now it gives me the buffer displayed in the tty I'm running in with no DISPLAY. Seems like there should be enough clues floating around for it to be able to "do what I want" instead of having to manually change gnuserv-frame to get it to happen. Scott

Valdis> My pet peev is that DISPLAY isn't available (which has bit Valdis> me a few times, if I'm SSH'ed into a net-slow box I Valdis> probably want 'use an existing frame on THIS display' Valdis> semantics (as opening a whole new frame may take 10-15 Valdis> seconds). And as you noted in (2), using the value of Valdis> DISPLAY that the XEmacs end has is Totally Wrong, since Valdis> you may not even be in the same time zone. ;) This sounds like a job for ... Specifierman! Except that there's no 'ssh-d-into-a-net-slow-box display type. It sounds like something that would be worth taking a hack at. What kind of API do you need? Ie, suppose there were a variable `gnuclient-environmental-conditions'. What kinds of questions would you want to ask it, and what kinds of answers do you want in what conditions? Or maybe gnuclient should somehow intervene in the environment that getenv sees? (That's too evil to actually implement I suspect, but it might suggest something more appropriate.) Maybe there could be a display-local environment process environment? -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

On Thu, 06 Nov 2003 11:48:36 +0900, "Stephen J. Turnbull" said: Actually, it's easier than that, at least for all the cases that I was worried about. From gnuserv.el, line 426: TYPE should either be a (tty TTY TERM PID) list, or (x DISPLAY) list. Hey lookie all that neat info in TYPE ;) So a few lines later: (dest-frame (if (functionp gnuserv-frame) (funcall gnuserv-frame (car type)) gnuserv-frame)) We pass (car type), when (type) would be much more useful. I played around with having gnuserv-frame return a lambda that would evaluate type and DTRT, but never got all the quoting to work out so it would evaluate later... Of course, the next lines explain why it's busticated: ;; The gnuserv-frame dependencies are ugly, but it's ;; extremely hard to make that stuff cleaner without ;; breaking everything in sight. Oh well.

On Sun, 02 Nov 2003, hniksic(a)xemacs.org wrote: If you have a usable DISPLAY, then ssh X11 forwarding is working. How are you doing the different ssh commands. If you don't have a usable DISPLAY don't you have to run xemacs -nw? C-x C-f <foobar> would work for 'gnuclient <foobar>' command from the *shell* buffer. There are various commands that invoke $EDITOR, like crontab -e, which should work if you've done export EDITOR=gnuclient, and have gnuserv running. -jeff

On Sun, Nov 02, 2003 at 08:15:25PM +0100, Hrvoje Niksic wrote: I've tried that, but it's really slow (especially when I'm ssh'ing over an analog modem connection as I sometimes do). And that's basically the situation I run into...crontab -e is something I do occasionally, but I also do Perforce and/or CVS commands in that shell that use $EDITOR to gather comments. Yes, they have xemacs integrations, so I can generally get by using the appropriate elisp functionality, but my fingers don't always remember that. Scott