Re: Feature request: new function start-remote-process

[Michael Albinus <michael.albinus@gmx.de>]

"Sean O'Rourke" <sorourke@cs.ucsd.edu> writes:

> Michael Albinus <michael.albinus@gmx.de> writes:
>> start-remote-process shall behave similar: if default-directory points
>> to a remote host, the corresponding program shall be executed there.
>
> This would be great for compiling programs, but from what I have
> seen, it has to be done carefully to avoid breaking things.  For
> example, Tramp 2.1's current emulation interacts badly with
> `ediff-buffers', which will sometimes write temporary files
> locally, then try to diff them on the remote system.  So it seems
> like it may be necessary to explicitly allow or prevent
> individual calls to start-process from being handled remotely.

That's exactly the reason of my proposal. The proof of concept in Tramp
2.1 did show this deficiency. With the new function, every package could
decide whether to apply start-process or start-remote-process.

A package like gnus shall always use start-process; it is unlikely to
use mail programs on a remote host. In contrary, compile shall use
start-remote-process - when default-directory is local, there is no
difference to the current behaviour.

> /s

Best regards, Michael.

PS: The problem with ediff has been worked around in Tramp's CVS version
already, because it disturbs me as well. But it is still a kludge.