Alternatives to tramp

Alternatives to tramp

[Gary]

I'm absolutely fed up with tramp's inability to play nicely with other
modes. What are the alternatives, please?

Re: Alternatives to tramp

[Lennart Borgman]

On Thu, Nov 11, 2010 at 1:24 PM, Gary <help-gnu-emacs@garydjones.name> wrote:
> I'm absolutely fed up with tramp's inability to play nicely with other
> modes. What are the alternatives, please?

In what ways doesn't it play nice with other modes? What version of
Emacs are you using?

Re: Alternatives to tramp

[Tassilo Horn]

Gary <help-gnu-emacs@garydjones.name> writes:

> I'm absolutely fed up with tramp's inability to play nicely with other
> modes.

You mean modes that implement alternative completion styles like ido,
iswitchb, lusty-explorer, and friends, right?

> What are the alternatives, please?

Well, I guess, there are none, at least none that support most TRAMP
features.  For FTP, there's ange-ftp, but that's it AFAIK.

Bye,
Tassilo

Re: Alternatives to tramp

[Gary]

Tassilo Horn wrote:
> Gary writes:
>
>> I'm absolutely fed up with tramp's inability to play nicely with other
>> modes.
>
> You mean modes that implement alternative completion styles like ido,
> iswitchb, lusty-explorer, and friends, right?

Not only, but possibly also:

Desktop mode and tiny-desktop (tramp tries to restore the remote
buffers, but fails because - unsurprisingly - it doesn't have a password
at startup, so the desktop packages then whine because they could not
reopen the buffers);

Flymake (see previous posts, although Michael says he has patched things
since then);

There was at least one other, but I can't recall exactly what it was now.

Anyway. I'm just using scp now. More manual steps, but at least nothing
complains.

Re: Alternatives to tramp

[Michael Albinus]

Gary <help-gnu-emacs@garydjones.name> writes:

> Tassilo Horn wrote:
>> Gary writes:
>>
>>> I'm absolutely fed up with tramp's inability to play nicely with other
>>> modes.
>>
>> You mean modes that implement alternative completion styles like ido,
>> iswitchb, lusty-explorer, and friends, right?
>
> Not only, but possibly also:
>
> Desktop mode and tiny-desktop (tramp tries to restore the remote
> buffers, but fails because - unsurprisingly - it doesn't have a password
> at startup, so the desktop packages then whine because they could not
> reopen the buffers);

It is not because of Tramp, it is because of major modes which do not
handle remote files pretty well. Have you written a bug report?
OK, let's handle desktop.el. It has the variable `desktop-files-not-to-save',
which shall prevent saving remote file names in ~/.emacs.desktop. If it
doesn't for you: could you, please, show the value of this variable as
well as the contents of ~/.emacs.desktop, which triggers to load remote
files the next startup?

> Flymake (see previous posts, although Michael says he has patched things
> since then);

Hmm. Could you be a little bit more verbose?

> There was at least one other, but I can't recall exactly what it was now.

Sigh.

> Anyway. I'm just using scp now. More manual steps, but at least nothing
> complains.

Best regards, Michael.

Re: Alternatives to tramp

[Gary]

Michael Albinus wrote:
> It is not because of Tramp

In the manual you talk of making "the remote file system transparently
accessible from the local machine". Don't blame other modes if that is
not the case.

Re: Alternatives to tramp

[Michael Albinus]

Gary <help-gnu-emacs@garydjones.name> writes:

> Michael Albinus wrote:
>> It is not because of Tramp
>
> In the manual you talk of making "the remote file system transparently
> accessible from the local machine". Don't blame other modes if that is
> not the case.

Tramp is a library, documented in the Elisp manual. Most of its
functions are invisible, due to the file name handler mechanism.

I acknowledge that it is a "new" library, available in core Emacs since
22.1. However, other packages shall know about, and respect it. Or not.

I believe it is not worth a flame war. I try to help improving major
modes where possible, and I did so in the past. If you want to show me
details of your problem, I'll try my best. If you don't - your decision.

Best regards, Michael.

Re: Alternatives to tramp

[Gary]

Michael Albinus wrote:

> If you want to show me
> details of your problem, I'll try my best. If you don't - your decision.

Read the "Subject:" line again. This was never a thread about getting
help with Tramp.

See also Message-ID: <ibu10o$7hf$1@dough.gmane.org> - "I'm just using
scp now."

Re: Alternatives to tramp

[Richard Riley]

Gary <help-gnu-emacs@garydjones.name> writes:

> Michael Albinus wrote:
>
>> If you want to show me
>> details of your problem, I'll try my best. If you don't - your decision.
>
> Read the "Subject:" line again. This was never a thread about getting
> help with Tramp.
>
> See also Message-ID: <ibu10o$7hf$1@dough.gmane.org> - "I'm just using
> scp now."
>

Possibly by being more verbose with the actual errors and problems you
are having Michael can look at improving tramp. This would mean being
more constructive and less rude and objectionable of course.

Re: Alternatives to tramp

[Tim X]

Gary <help-gnu-emacs@garydjones.name> writes:

> Tassilo Horn wrote:
>> Gary writes:
>>
>>> I'm absolutely fed up with tramp's inability to play nicely with other
>>> modes.
>>
>> You mean modes that implement alternative completion styles like ido,
>> iswitchb, lusty-explorer, and friends, right?
>
> Not only, but possibly also:
>
> Desktop mode and tiny-desktop (tramp tries to restore the remote
> buffers, but fails because - unsurprisingly - it doesn't have a password
> at startup, so the desktop packages then whine because they could not
> reopen the buffers);
>
> Flymake (see previous posts, although Michael says he has patched things
> since then);
>
> There was at least one other, but I can't recall exactly what it was now.
>
> Anyway. I'm just using scp now. More manual steps, but at least nothing
> complains.
>
>

I suspect you are blaming the wrong culprit. In my experience, tramp has
not been the problem, but rather other modes that do not recognise the 
power of emacs buffers and have a limited expectation regarding the
relationship between buffers, files and resources. In reality, the
problem is not with tramp not playing well with others, but others not
playing well with tramp. I have found that once you adopt this
perspective, resolving issues can be much faster as you look for the
solution from a different perspective.

Even if you use other solutions, such as sshfs or nfs, so that all the
remote files are accessible from within emacs, you will still run into
problems with (probably) the same modes who will also not handle the
situation of non-local resources being unavailable in a graceful manner.

For example, desktop.el - the problem here is not with tramp. The
problem here is with desktop.el attempting to restore references to
remote files that were being accessed via a method that requires
additional information/resources and that additional
information/resource is not available. 

It isn't tramp's failure that it is being asked to open these files
without first having obtained the necessary resources i.e. network,
password etc. Provided you have a network and provided you have setup
things like an ssh agent to handle passwords, this isn't even a problem.
However, if this is not possible for some reason, then surely desktop.el
and friends can be configured not to try and restore buffers that depend
on remote resources that may not always be available?  If not, surely
this is a limitation of these modes and not of tramp? Noting of course
that desktop.el would likely have just as many or more problems if you
were using sshfs or nfs rather than tramp and these methods were
unavailable. 

Of course, it has to be recognised that tramp has moved the goal posts
somewhat. It has made things possible that use to be quite difficult to
configure from within emacs and has made new things possible. Remote
execution of programs/processes for example. There were ways of doing
this in the past, but they tended to be very mode specific and fragile.
Establishing a more consistent standard approach is a good thing, but
will likely take some time to evolve. Likewise, it will also take some
time for many modes, especially those which are not part of the core
emacs distribution, to adjust to these changes and enhancements.
However, my recommendation is that if you have a problem with a mode's
interaction with a tramp based resource, look for ways to adjust that
mode rather than adjust tramp. If none exists, maybe recommend a feature
to the mode author. I've also noticed extremely good responses from
tramp maintainers to requests and assistance, so there is likely help
available to mode authors in updating their modes to play nicely with
tramp. 

Tim

-- 
tcross (at) rapttech dot com dot au

Re: Alternatives to tramp

[Thierry Volpiatto]

Gary <help-gnu-emacs@garydjones.name> writes:

> I'm absolutely fed up with tramp's inability to play nicely with other
> modes. What are the alternatives, please?

sshfs is nice and much faster than tramp.
Otherwise, tramp work fine with anything (anything-find-files).

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: Alternatives to tramp

[Xavier Maillard]

On Thu, 11 Nov 2010 19:02:02 +0100, Thierry Volpiatto <thierry.volpiatto@gmail.com> wrote:
> Gary <help-gnu-emacs@garydjones.name> writes:
> 
> > I'm absolutely fed up with tramp's inability to play nicely with other
> > modes. What are the alternatives, please?
> 
> sshfs is nice and much faster than tramp.

Do you have numbers ? Last time I tried it (sshfs), I had the exact
opposite feeling.

Xavier

Re: Alternatives to tramp

[Andrea Crotti]

Xavier Maillard <xavier@maillard.im> writes:

>
> Do you have numbers ? Last time I tried it (sshfs), I had the exact
> opposite feeling.
>
> Xavier

well there is no way that sshfs can be slower than tramp, it's a
filesystem done on purpose, maybe you mounted with some wrong options
the volume.

Anyway what is tramp doing so badly with other modes I don't get it?

Re: Alternatives to tramp

[Michael Albinus]

Gary <help-gnu-emacs@garydjones.name> writes:

> I'm absolutely fed up with tramp's inability to play nicely with other
> modes. What are the alternatives, please?

The major problem is when "other modes" call external programs. Often,
they are not prepared to run on remote hosts.

This is not because of Tramp; Tramp provides just the infrastructure.

OTOH: you are working on Windows, IIRC. If the remote host runs a Samba
server, mount the directory.

Best regards, Michael.

Re: Alternatives to tramp

[Barry Margolin]

In article <mailman.2.1289504993.29678.help-gnu-emacs@gnu.org>,
 Michael Albinus <michael.albinus@gmx.de> wrote:

> Gary <help-gnu-emacs@garydjones.name> writes:
> 
> > I'm absolutely fed up with tramp's inability to play nicely with other
> > modes. What are the alternatives, please?
> 
> The major problem is when "other modes" call external programs. Often,
> they are not prepared to run on remote hosts.

This also seems to happen with some basic commands.  If I'm in a buffer 
visiting a remote file, and use M-!, it tries to run the command on the 
remote system.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***