* Re: Server port
[not found] <alpine.LFD.1.10.0808311533530.2934@froglet.home.mavit.org.uk>
@ 2008-08-31 18:22 ` Stefan Monnier
[not found] ` <alpine.LFD.1.10.0808312118210.2934@froglet.home.mavit.org.uk>
0 siblings, 1 reply; 15+ messages in thread
From: Stefan Monnier @ 2008-08-31 18:22 UTC (permalink / raw
To: Peter Oliver; +Cc: emacs-devel
> I wanted to force the Emacs server to listen on a particular port. Here is
> a patch that allows this by adding a customisation option.
Why?
Stefan
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Server port
[not found] ` <alpine.LFD.1.10.0808312118210.2934@froglet.home.mavit.org.uk>
@ 2008-09-01 3:02 ` Stefan Monnier
2010-10-23 18:44 ` Peter Oliver
0 siblings, 1 reply; 15+ messages in thread
From: Stefan Monnier @ 2008-09-01 3:02 UTC (permalink / raw
To: Peter Oliver; +Cc: emacs-devel
>>> I wanted to force the Emacs server to listen on a particular port.
>>> Here is a patch that allows this by adding a customisation option.
>> Why?
> So that it would be simple to set up a firewall rule or port forwarding to
> allow incoming connections from remote emacsclients.
Makes sense.
Can you post your patch to bug-gnu-emacs so that we can save it for when
we reopen the trunk for new features?
Stefan
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Server port
2008-09-01 3:02 ` Stefan Monnier
@ 2010-10-23 18:44 ` Peter Oliver
2010-10-23 19:29 ` Leo
2010-10-24 1:11 ` Stefan Monnier
0 siblings, 2 replies; 15+ messages in thread
From: Peter Oliver @ 2010-10-23 18:44 UTC (permalink / raw
To: emacs-devel
On Sun, 31 Aug 2008, Stefan Monnier wrote:
> On Sun, 31 Aug 2008, Peter Oliver wrote:
>>>> I wanted to force the Emacs server to listen on a particular port.
>>>> Here is a patch that allows this by adding a customisation option.
>>>
>>> Why?
>>
>> So that it would be simple to set up a firewall rule or port forwarding to
>> allow incoming connections from remote emacsclients.
>
> Makes sense.
> Can you post your patch to bug-gnu-emacs so that we can save it for when
> we reopen the trunk for new features?
Can this now be applied? I have posted an updated patch to
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=854
--
Peter Oliver
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Server port
2010-10-23 18:44 ` Peter Oliver
@ 2010-10-23 19:29 ` Leo
2010-10-23 19:38 ` Juanma Barranquero
2010-10-24 1:11 ` Stefan Monnier
1 sibling, 1 reply; 15+ messages in thread
From: Leo @ 2010-10-23 19:29 UTC (permalink / raw
To: Peter Oliver; +Cc: emacs-devel
On 2010-10-24 02:44 +0800, Peter Oliver wrote:
> Can this now be applied? I have posted an updated patch to
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=854
I also proposed this in private email to Juanma but was turned down due
to security concern. This is what I used locally:
commit 014a288ac84b11453334397c77f439071fa138f2
Date: Fri Aug 20 16:47:03 2010 +0100
Make port number of emacs server customisable
Modified lisp/server.el
diff --git a/lisp/server.el b/lisp/server.el
index 7e2c35a..50d08b0 100644
--- a/lisp/server.el
+++ b/lisp/server.el
@@ -112,6 +112,14 @@ If set, the server accepts remote connections; otherwise it is local."
:version "22.1")
(put 'server-host 'risky-local-variable t)
+(defcustom server-port t
+ "TCP socket port for the server process.
+If t use a random port number."
+ :group 'server
+ :type '(choice (const :tag "Random" t)
+ (integer :tag "Port" 10007))
+ :version "24.1")
+
(defcustom server-auth-dir (locate-user-emacs-file "server/")
"Directory for server authentication files.
@@ -561,7 +569,7 @@ server or call `M-x server-force-delete' to forcibly disconnect it.")
;; The other args depend on the kind of socket used.
(if server-use-tcp
(list :family 'ipv4 ;; We're not ready for IPv6 yet
- :service t
+ :service server-port
:host (or server-host "127.0.0.1") ;; See bug#6781
:plist '(:authenticated nil))
(list :family 'local
Leo
^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: Server port
2010-10-23 19:29 ` Leo
@ 2010-10-23 19:38 ` Juanma Barranquero
2010-10-23 20:01 ` Leo
0 siblings, 1 reply; 15+ messages in thread
From: Juanma Barranquero @ 2010-10-23 19:38 UTC (permalink / raw
To: Leo; +Cc: Peter Oliver, emacs-devel
On Sat, Oct 23, 2010 at 21:29, Leo <sdl.web@gmail.com> wrote:
> I also proposed this in private email to Juanma but was turned down due
> to security concern.
Just for clarification, I didn't "turn down" anything, because the
decision is not mine to make. I likely pointed out that a similar idea
was initially turned down because of security concerns.
Stefan's (couple of years old) message in this thread seems to
indicate that the proposed patch is acceptable.
Juanma
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Server port
2010-10-23 19:38 ` Juanma Barranquero
@ 2010-10-23 20:01 ` Leo
0 siblings, 0 replies; 15+ messages in thread
From: Leo @ 2010-10-23 20:01 UTC (permalink / raw
To: Juanma Barranquero; +Cc: Peter Oliver, emacs-devel
On 2010-10-24 03:38 +0800, Juanma Barranquero wrote:
>> I also proposed this in private email to Juanma but was turned down due
>> to security concern.
>
> Just for clarification, I didn't "turn down" anything, because the
> decision is not mine to make. I likely pointed out that a similar idea
> was initially turned down because of security concerns.
That's what I meant ;) Sorry for my English.
Leo
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Server port
2010-10-23 18:44 ` Peter Oliver
2010-10-23 19:29 ` Leo
@ 2010-10-24 1:11 ` Stefan Monnier
2010-10-24 16:48 ` Remote TCP server through ssh tunnel [Was: Re: Server port] Lluís
1 sibling, 1 reply; 15+ messages in thread
From: Stefan Monnier @ 2010-10-24 1:11 UTC (permalink / raw
To: Peter Oliver; +Cc: emacs-devel
> Can this now be applied? I have posted an updated patch to
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=854
Yes, people, feel free to install it, thank you,
Stefan
^ permalink raw reply [flat|nested] 15+ messages in thread
* Remote TCP server through ssh tunnel [Was: Re: Server port]
2010-10-24 1:11 ` Stefan Monnier
@ 2010-10-24 16:48 ` Lluís
2010-10-24 21:50 ` Ken Raeburn
0 siblings, 1 reply; 15+ messages in thread
From: Lluís @ 2010-10-24 16:48 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
Stefan Monnier writes:
>> Can this now be applied? I have posted an updated patch to
>> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=854
> Yes, people, feel free to install it, thank you,
Which reminds me... can I use emacsclient to connect to a server behind
a firewall?
I've tried with this:
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:* LISTEN 12078/emacs
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 ]
client$ emacsclient -f /tmp/server -nw
*ERROR*: Could not open file: /dev/pts/5
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-Options.html
Thanks,
Lluis
--
"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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Remote TCP server through ssh tunnel [Was: Re: Server port]
2010-10-24 16:48 ` Remote TCP server through ssh tunnel [Was: Re: Server port] Lluís
@ 2010-10-24 21:50 ` Ken Raeburn
2010-10-25 12:50 ` Remote TCP server through ssh tunnel Lluís
0 siblings, 1 reply; 15+ messages in thread
From: Ken Raeburn @ 2010-10-24 21:50 UTC (permalink / raw
To: Lluís; +Cc: Emacs Developers
On Oct 24, 2010, at 12:48, Lluís wrote:
> Which reminds me... can I use emacsclient to connect to a server behind
> a firewall?
This would probably be a more appropriate question for emacs-help, but....
> I've tried with this:
>
> 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:* LISTEN 12078/emacs
> 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.
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.)
> client$ emacsclient -f /tmp/server -nw
> *ERROR*: Could not open file: /dev/pts/5
This can't work. Emacs running on the server can't access the local tty device on your client machine.
> 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-Options.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...
(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.)
Ken
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Remote TCP server through ssh tunnel
2010-10-24 21:50 ` Ken Raeburn
@ 2010-10-25 12:50 ` Lluís
2010-10-25 15:33 ` Chad Brown
` (2 more replies)
0 siblings, 3 replies; 15+ messages in thread
From: Lluís @ 2010-10-25 12:50 UTC (permalink / raw
To: Ken Raeburn; +Cc: Emacs Developers
Ken Raeburn writes:
> On Oct 24, 2010, at 12:48, Lluís wrote:
>> I've tried with this:
>>
>> 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:* LISTEN 12078/emacs
>> 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-Options.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
--
"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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Remote TCP server through ssh tunnel
2010-10-25 12:50 ` Remote TCP server through ssh tunnel Lluís
@ 2010-10-25 15:33 ` Chad Brown
2010-10-25 16:28 ` Stefan Monnier
2010-10-25 17:28 ` Peter Oliver
2 siblings, 0 replies; 15+ messages in thread
From: Chad Brown @ 2010-10-25 15:33 UTC (permalink / raw
To: Lluís; +Cc: Emacs Developers
[-- Attachment #1: Type: text/plain, Size: 1276 bytes --]
On Oct 25, 2010, at 5:50 AM, Lluís wrote:
>
> What I expected was to run emacsclient as a sort of UI client
> interacting with a remote server.
> [...]
> 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.
For your idea, emacsclient would have to have some way of transmitting every change from either the server or client) over the communications channel. Someone would have to figure out the set of all interactions between the client along with an efficient marshaling/unmarshaling protocol (more efficient than just using something like lbX). For emacs, this would mean breaking in two the redisplay engine, which is probably the most complicated part of the program.
There are a few editors that have tried this experiment (notably, sam/samterm, by Rob Pike http://en.wikipedia.org/wiki/Sam_%28text_editor%29). When last I followed that community, the split usage had proven to be less and less valuable over time, and I suspect that the specific functionality might have bit-rotted away.
I would suggest that you look into something like low-bandwith X (http://en.wikipedia.org/wiki/Low_Bandwidth_X) as an alternative.
I hope that helps,
*Chad
[-- Attachment #2: Type: text/html, Size: 1891 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Remote TCP server through ssh tunnel
2010-10-25 12:50 ` Remote TCP server through ssh tunnel Lluís
2010-10-25 15:33 ` Chad Brown
@ 2010-10-25 16:28 ` Stefan Monnier
2010-10-25 17:28 ` Peter Oliver
2 siblings, 0 replies; 15+ messages in thread
From: Stefan Monnier @ 2010-10-25 16:28 UTC (permalink / raw
To: Lluís; +Cc: Ken Raeburn, Emacs Developers
>> ":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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Remote TCP server through ssh tunnel
2010-10-25 12:50 ` Remote TCP server through ssh tunnel Lluís
2010-10-25 15:33 ` Chad Brown
2010-10-25 16:28 ` Stefan Monnier
@ 2010-10-25 17:28 ` Peter Oliver
2010-10-25 20:22 ` Lluís
2 siblings, 1 reply; 15+ messages in thread
From: Peter Oliver @ 2010-10-25 17:28 UTC (permalink / raw
To: Lluís; +Cc: Ken Raeburn, Emacs Developers
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2229 bytes --]
On Mon, 25 Oct 2010, Lluís wrote:
> Ken Raeburn writes:
>
>> On Oct 24, 2010, at 12:48, Lluís wrote:
>>> I've tried with this:
>>>
>>> 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:* LISTEN 12078/emacs
>>> 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 ]
>>
>> 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've tried it, and can confirm that it does work.
> 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 think you misunderstand. The suggestion here isn't that you should
run emacs over X11. The other person is pointing out that SSH arranges
this for you in a way that confuses emacsclient. All this talk of
"servers" is rather confusing when your X11 server is at the opposite
end of the connection to your SSH server :-)
Try the following:
server$ echo $DISPLAY
# Confirm that you can connect to this display by running, e.g.,
server$ xdpyinfo
# Then:
client$ export DISPLAY="<value from echo, above>"
Anyway, as people have mentioned, I think you should look into Tramp.
I call emacsclient with a simple shell wrapper that prefixes
"/ssh:login@host:" to the file name. Emacs then fetches the
file for me for local editing.
If you re-use your existing SSH connections by adding, e.g.,
ControlMaster auto
ControlPath ~/.ssh/mux/%r@%h:%p
to your ~/.ssh/config, this is all perfectly speedy.
--
Peter Oliver
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Remote TCP server through ssh tunnel
2010-10-25 17:28 ` Peter Oliver
@ 2010-10-25 20:22 ` Lluís
2010-10-26 4:05 ` Ken Raeburn
0 siblings, 1 reply; 15+ messages in thread
From: Lluís @ 2010-10-25 20:22 UTC (permalink / raw
To: Peter Oliver; +Cc: Emacs Developers
Peter Oliver writes:
> I think you misunderstand. The suggestion here isn't that you should run emacs
> over X11. The other person is pointing out that SSH arranges this for you in a
> way that confuses emacsclient.
Yup, but the net effect is equivalent to going into the server machine
and executing a graphical emacs that is transported through X11 back to
my client machine (where the X11 server resides :)).
That's exactly what I was trying to avoid, and what I was expecting was
the split model that Chad and Stefan were describing.
In any case, thanks a lot for your answers, at least now I can tell my
work mate that this is one of the few things that his shiny new emacs
cannot do :)
> Anyway, as people have mentioned, I think you should look into Tramp.
Well, he told me that tramp was just "too slow" when saving files. I
don't know if this can be optimized.
> If you re-use your existing SSH connections by adding, e.g.,
> ControlMaster auto
> ControlPath ~/.ssh/mux/%r@%h:%p
> to your ~/.ssh/config, this is all perfectly speedy.
Which I already do :)
Thanks,
Lluis
--
"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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Remote TCP server through ssh tunnel
2010-10-25 20:22 ` Lluís
@ 2010-10-26 4:05 ` Ken Raeburn
0 siblings, 0 replies; 15+ messages in thread
From: Ken Raeburn @ 2010-10-26 4:05 UTC (permalink / raw
To: Lluís; +Cc: Peter Oliver, Emacs Developers
On Oct 25, 2010, at 16:22, Lluís wrote:
> In any case, thanks a lot for your answers, at least now I can tell my
> work mate that this is one of the few things that his shiny new emacs
> cannot do :)
Blasphemy! :-)
If you're interested in speeding up X11 sessions, I was pretty happy with dxpc years ago (and implemented an option to have it forcibly set the "backing store" option of all visible windows, to reduce refreshes); NX looks like an interesting option too.
>> Anyway, as people have mentioned, I think you should look into Tramp.
>
> Well, he told me that tramp was just "too slow" when saving files. I
> don't know if this can be optimized.
It's slower than operating on local files, certainly, but I haven't been annoyed with it enough to look much into speeding it up. It does appears that Tramp supports using rsync; that may be faster for sending back large files to which you've made small changes, especially combined with the SSH connection multiplexing you've already got. In my experience, the default seems to be to use scp, so explicitly selecting rsync may be necessary.
Ken
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2010-10-26 4:05 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <alpine.LFD.1.10.0808311533530.2934@froglet.home.mavit.org.uk>
2008-08-31 18:22 ` Server port Stefan Monnier
[not found] ` <alpine.LFD.1.10.0808312118210.2934@froglet.home.mavit.org.uk>
2008-09-01 3:02 ` Stefan Monnier
2010-10-23 18:44 ` Peter Oliver
2010-10-23 19:29 ` Leo
2010-10-23 19:38 ` Juanma Barranquero
2010-10-23 20:01 ` Leo
2010-10-24 1:11 ` Stefan Monnier
2010-10-24 16:48 ` Remote TCP server through ssh tunnel [Was: Re: Server port] Lluís
2010-10-24 21:50 ` Ken Raeburn
2010-10-25 12:50 ` Remote TCP server through ssh tunnel Lluís
2010-10-25 15:33 ` Chad Brown
2010-10-25 16:28 ` Stefan Monnier
2010-10-25 17:28 ` Peter Oliver
2010-10-25 20:22 ` Lluís
2010-10-26 4:05 ` Ken Raeburn
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.