From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: xscript@gmx.net (=?utf-8?Q?Llu=C3=ADs?=) Newsgroups: gmane.emacs.devel Subject: Re: Remote TCP server through ssh tunnel Date: Mon, 25 Oct 2010 14:50:03 +0200 Message-ID: <878w1m5tdw.fsf@ginnungagap.bsc.es> References: <87k4l7mta3.fsf_-_@fulla.xlab.taz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1288010987 25761 80.91.229.12 (25 Oct 2010 12:49:47 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 25 Oct 2010 12:49:47 +0000 (UTC) Cc: Emacs Developers To: Ken Raeburn Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 25 14:49:44 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PAMUh-0003oY-U7 for ged-emacs-devel@m.gmane.org; Mon, 25 Oct 2010 14:49:44 +0200 Original-Received: from localhost ([127.0.0.1]:38881 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PAMUg-0003Pk-OR for ged-emacs-devel@m.gmane.org; Mon, 25 Oct 2010 08:49:42 -0400 Original-Received: from [140.186.70.92] (port=47387 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PAMUX-0003Nw-18 for emacs-devel@gnu.org; Mon, 25 Oct 2010 08:49:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PAMUV-0005YB-Hk for emacs-devel@gnu.org; Mon, 25 Oct 2010 08:49:32 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:39174 helo=mail.gmx.net) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1PAMUV-0005Xs-4L for emacs-devel@gnu.org; Mon, 25 Oct 2010 08:49:31 -0400 Original-Received: (qmail invoked by alias); 25 Oct 2010 12:49:29 -0000 Original-Received: from unknown (EHLO localhost) [84.88.53.92] by mail.gmx.net (mp048) with SMTP; 25 Oct 2010 14:49:29 +0200 X-Authenticated: #12333383 X-Provags-ID: V01U2FsdGVkX19JIGVPTMlJbGMURbPkLbJoAozczDO9lrqBXjjq+p behT7neqUvqfQp In-Reply-To: (Ken Raeburn's message of "Sun, 24 Oct 2010 17:50:31 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:132088 Archived-At: Ken Raeburn writes: > On Oct 24, 2010, at 12:48, Llu=C3=ADs wrote: >> I've tried with this: >>=20 >> server$ emacs --daemon --eval '(setq server-use-tcp t server-host "0.0.0= .0")' >> server$ netstat -nap | grep emacs >> tcp 0 0 0.0.0.0:13501 0.0.0.0:* LIST= EN 12078/emacs=20=20=20=20=20 >> server$ ssh -R 13502:localhost:13501 firewall >> client$ ssh -L 13501:localhost:13502 vilanova@gso.ac.upc.edu >> # I already have an existing tunnel for ssh connections to server >> client$ scp server:.emacs.d/server/server /tmp/server >> client$ sed -i -e s/0.0.0.0/127.0.0.1/ /tmp/server >> client$ emacsclient -f /tmp/server -c >> Waiting for Emacs... >> *ERROR*: Display :0.0 can't be opened >> [Exit 1 ] > ":0.0" is the name you generally use for connecting to the local X11 > display on the machine running the X program. That's what you've got > on the client, and what emacsclient passes over to the emacs server > process. Unfortunately since that's running on a different machine, > the local X display *there* -- if there even is one -- is not the one > on your client machine. Right. That's what I found out after trying it. The emacs server is expecting everything to be run on the server machine. What I expected was to run emacsclient as a sort of UI client interacting with a remote server. The objective is to have a local X window but doing everything on the server. I know I could just "ssh -X" to the server and start a client there, but insteractivity is too sloppy then due to network delay. In any case, I suppose emacs is not ready for such a client-server interaction, although I don't really know if that would be hard to achieve. > If your SSH path through is forwarding X11 as well as TCP connections, > you need to find the server-side name for that forwarded "display" and > give it to emacsclient to pass through. I think that'll work; I > haven't tried it. (I usually just run emacsclient on the server > machine, over an SSH session, and let it pop up a window over that > same SSH session.) That's what I do, but is not comfortable for high delay network connections. As I said, I expected to run locally "as much as possible", but modify everything remotely. I suppose that's not an easy task, as emacs is still relying on a lot of global variables, so client interaction still needs to send a lot of information back and forth to the server. This would probably require modifications to the core VM in order to provide a true client-server model with client-side caching. >> Do you have any clue of why is this happenning? According to the >> documentation, this should work flawlessly (at least with hosts on the >> same network): >> http://www.gnu.org/software/emacs/manual/html_node/emacs/emacsclient-Opt= ions.html > It's a bit misleading, yeah... evaluating an expression or editing a > file in shared NFS space might make sense to trigger remotely like > this, and the documentation was probably fine when multi-tty and > daemon support hadn't come along, but now it probably needs to > highlight these problems. > Please file a bug report (M-x report-emacs-bug RET) and/or submit a fix... You mean a bug report to the paragraph that misled me? > (And of course the Emacs driving the new window will be running on the > server, so it can't access files on the client machine without jumping > through hoops. If you really want to be able to do something on the > local machine that triggers editing of files that are on the server > machine, you might also look at the Tramp package, which will let you > use your local Emacs, which may be faster. But if you want to run > subprocesses and such over there, or share an Emacs session there > across multiple clients, yeah, getting a window popped up remotely may > be best.) As said, I did expect everything to run on the server, but without sending "canvas diffs" of the X11 frames through the network. Lluis --=20 "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth