|
From: | csant |
Subject: | Re: [multi-tty] X or tty |
Date: | Fri, 18 May 2007 22:39:40 +0200 |
User-agent: | Opera Mail/9.21 (Linux) |
Funny. For me it is just the other way round. The normal case for me is to run my emacs server in an X session. Now if I am somewhere on the road and want to access my Emacs session at home via a modem connection or similar, I have quite limited bandwidth. Even though the ssh session I'll be using into my home computer forwards X connections, I would not want to make use of it: it would be dead slow.
I am not completely sure that this is what you'd really have to expect. If you'd be ssh-ing without X forwarding, then this would be a no-brainer, but if you ssh with X forwarding, you probably are doing that... because you want to forward X? Not wanting X to be forwarded for one application (the emacsclient) sounds more like a the exception that you could overwrite with an explicit -t .
Ideally, I'd like the client to inherit by default any `forced' flags set to the server, i.e. to start by default with -t when the server was deliberately started -nw in an environment that does have $DISPLAY set. This could be overwritten in the client with -d .
I think it would be unexpected.
I am currently solving it with wrappers. But I am not convinced that if I am forcing the `main' emacs instance (the server) into deliberately ignoring X, I do not want this to be `inherited' by the clients. Right now it feels more, from the `dumb user's perspective, as `hrmph - didn't I say --no-window-system?' each time the emacsclient starts with X.
/c
[Prev in Thread] | Current Thread | [Next in Thread] |