From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Remote TCP server through ssh tunnel Date: Mon, 25 Oct 2010 12:28:37 -0400 Message-ID: References: <87k4l7mta3.fsf_-_@fulla.xlab.taz> <878w1m5tdw.fsf@ginnungagap.bsc.es> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1288025076 31412 80.91.229.12 (25 Oct 2010 16:44:36 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 25 Oct 2010 16:44:36 +0000 (UTC) Cc: Ken Raeburn , Emacs Developers To: xscript@gmx.net (=?iso-8859-1?Q?Llu=EDs?=) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 25 18:44:35 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 1PAQ9z-0007y8-0u for ged-emacs-devel@m.gmane.org; Mon, 25 Oct 2010 18:44:35 +0200 Original-Received: from localhost ([127.0.0.1]:39194 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PAQ9y-0004oi-58 for ged-emacs-devel@m.gmane.org; Mon, 25 Oct 2010 12:44:34 -0400 Original-Received: from [140.186.70.92] (port=44868 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PAPub-0004VW-KY for emacs-devel@gnu.org; Mon, 25 Oct 2010 12:28:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PAPua-0008M7-Bo for emacs-devel@gnu.org; Mon, 25 Oct 2010 12:28:41 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:26633 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PAPua-0008Lw-9d for emacs-devel@gnu.org; Mon, 25 Oct 2010 12:28:40 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQJANBMxUxFxL/T/2dsb2JhbACgYntyvT+FSASSHw X-IronPort-AV: E=Sophos;i="4.58,236,1286164800"; d="scan'208";a="80630413" Original-Received: from 69-196-191-211.dsl.teksavvy.com (HELO pastel.home) ([69.196.191.211]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 25 Oct 2010 12:28:39 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id D0394A8503; Mon, 25 Oct 2010 12:28:37 -0400 (EDT) In-Reply-To: <878w1m5tdw.fsf@ginnungagap.bsc.es> (=?iso-8859-1?Q?=22Llu=ED?= =?iso-8859-1?Q?s=22's?= message of "Mon, 25 Oct 2010 14:50:03 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. 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:132098 Archived-At: >> ":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. > What I expected was to run emacsclient as a sort of UI client > interacting with a remote server. emacsclient, as it is implemented currently, is an application that just sends some commands to the Emacs server and then exits (in the most complex case it will wait for Emacs to send a reply before exiting). We could try to make it more complex and have emacsclient to care of doing the display: that would make it more "robust" in the sense that it would work in more circumstances, but that would mean designing and implementing an ad-hoc protocol. Tho maybe we could do it by reusing an existing system: e.g. we could have emacsclient create something like an lbx tunnel. And of course we'd want to do the same for ttys. > 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. I think that if we reuse something like lbx, it might not be too difficult. > 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. If you want to do as much as possible locally, I think that Tramp is your friend. Stefan