Re: Alternatives to tramp

[Tim X <timx@nospam.dev.null>]

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