Hrvoje Niksic <hniksic(a)xemacs.org> wrote:
Glynn Clements <glynn.clements(a)virgin.net> writes:
> Scott: I think that you want this:
>
> (setq gnuserv-frame t)
Yes, that's it. For some reason I thought that gnuclient would still
force creation of its own frame when DISPLAY is not set, but the code
is in fact smarter than I gave it credit for.
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