Re: Tramp with shots

[MIDI Lutescu]

Hi Michael,

>>>>> "Michael" == Michael Albinus <address@hidden> writes on
>>>>> Wed, 18 Aug 2010 21:13:56 +0200:
    Michael> 
    >> Wow,
    Michael> 
    Michael> Hi,
    Michael> 
    >> That's exactly what I did the last weekend.
    >> 
    >> I crafted a toy tramp method that I called `ext', because litter  
    >> My feeling is, that method is much faster then scp or other tramp
    >> method that I tried.
    Michael> 
    Michael> Sounds promising. Have you profiled your settings, in order
    Michael> to have numbers for comparision? Lets say "ssh" vs
    Michael> "sftp(gvfs)" vs "ext(sshfs)".
    Michael> 

    No scientific comparison, only feelings.  I had always a feeling of
    slowness toward Tramp.  My feeling on fastness is based on browsing,
    opening and saving remote files but not on copying big files
    though.

    There is a little story behind my toy `ext' method, a little bit sad
    one but with happy ending:

    The previous week I had to get some work done on whatever remote
    FreeBSD system, of course I used Tramp to connect remotely and edit
    my files.  I could browse the remote system, I could open the remote
    files, but for don't know what reason I could not save some files.
    I could save smaller files but not ones bigger then
    `tramp-copy-size-limit'.  Trying to save resulted into Emacs being
    stuck, and after interrupting Emacs I had the remote file truncated
    to 0 bytes.

    At first I blamed my own customizations, I used to use (another)
    customized method based on expect to login to remote hosts.
    So I started `emacs -q' and used fresh Tramp, and tried the methods
    ssh, scp, sftp, some '...x' method (I forget which one), and even
    FISH.  To my frustrations I could not save those files by any mean.

    I tried unsuccessfully to debug the stuff, analyzed tramps logs, and
    to make a long story short, no success.  Don't know until now what
    was wrong with that system, or maybe with Tramp, or with me, or who
    knows what.

    My frustration eventually get so big that I decided to give up
    Tramp.  I used sshfs to mount the remote FreeBSD, and saving worked
    like a breeze.  

    So at the culmination of my irritation I said myself, I regretfully confess,
    that I will never use Tramp again.  Never ever. That the sad part of
    the story.

    The happy ending is that immediately after I definitively and
    irremediably divorced Tramp, I started to miss it.  File edition
    worked fine now; but I missed the fine integration with remote
    processes, like find-grep on remote directories, remote compilation,
    opening shell remotely, compilation shell mode highlighting to jump
    to the right file, and so on.

    So I promised myself I will give Tramp a new chance and I to try to
    implement a method which relies on external system mount mechanism
    for file edition, but that will offer usual integration with remote
    processes.  So Tramp and me together again, since the last weekend.


    >> My implementation mounts sillently a directory "/tmp/address@hidden" to 
the
    >> remote path "/ext:address@hidden:/".  That mapping is hardcoded right 
now,
    >> but it's trivial to change it.

    Sorry I meant 'maps silently' but I wrote 'mounts silently'. It's
    the responsibility of the user to mount the remote file system.

    *I was looking for a minimal Tramp method which gives to Tramp only
    one responsibility: integration with remote processes.  Minimum
    involvement in file manipulations (to be delegated to system level
    mounts), and minimum involvement in the logging process (to be
    delegated totally to some user script).*

    Michael> 
    Michael> I see the trick. However, you assume, that the user is
    Michael> capable to mount at "/". Many users might miss such rights.

    That's right.  For me was pretty useful as it is.  I will look into
    the problem.
    
    Michael> 
    Michael> And, secondly, it won't work for XEmacs. There is another
    Michael> file name syntax for remote files; you would need to mount
    Michael> at "/[ext/address@hidden/" - that's really ugly.
    Michael> 

    I used 2 simple functions, which make the translation
    remote->to->local name and viceversa.  Changing them would make the
    trick, I find not difficult this.

    Michael> A more general approach is what tramp-gvfs.el uses. It lets
    Michael> GVFS mount the remote directory at "~/.gvfs/WebDAV on
    Michael> remote.host" (example), and uses functions to map between
    Michael> this internal names, and Tramp's file names.
    Michael> 
    Michael> Something like this could be used for sshfs as well.
    Michael> 

    I will look at tramp-gvfs.el.  On my Ubuntu 10.4 I have installed
    tramp-gvfs.elc but not the source tramp-gvfs.el.gz, the `emacs-el'
    Ubuntu package does not have it.  So I have to check out the sources
    from CVS and look into.

    >> The only problem that I found after a few days of using it is the
    >> expansion of "~" in remote paths like "/ext:address@hidden:~/".  That 
would
    >> not too be to difficult to fix too, but requires to think about how to
    >> map home directories to '/ext:' paths, which I was to lazy to.  For now
    >> using a '~' will map to your local home directory.
    Michael> 
    Michael> There are also more problems. What do you do with symlinks? 
    
    The relative symlinks do work.  The absolute one, don't (yet).  Thanks
    for pointing me to this (looks like I encountered only relative
    symlinks during these days).

    Michael> tried, but does your implementation of start-file-process
    Michael> works on remote hosts?

    That was the whole point for trying to write my own method.  It
    worked pretty well with my expect script.  

    Michael> You also map the arguments of process calls - this might be
    Michael> dangerous. Tramp avoids this for good reasons, and let the
    Michael> caller do the right thing (the best guess is to use
    Michael> relative file names as argument).
    Michael> 

    I do not totally understand the dangers you are talking about.  For
    me was important to get remote compilation & grep & shell mode
    working; don't think launching those kind of processes are
    dangerous.  Maybe you could explain me.

    >> Find bellow the 'tramp-ext.el' method.
    >> 
    >> If you want to try that stuff, don't forget to modify mine
    >> `tramp-login-program'.  (I use to use an expect script to launch
    >> external processes)
    Michael> 
    Michael> This might be a problem as well. It expects from the user
    Michael> an own login script - in my experience, users appreciate a
    Michael> complete solution. This part shall be offered in your
    Michael> package as well.
    Michael> 

    I could supply some sample script of course.  

    About expecting from the user its own script: see, that was exactly
    what I wanted, to have control over the logging process myself.  I
    personally found hard to understand the inner workings of tramp
    while logging, and whenever it didn't work I had hard time to debug
    it.  That's I suppose entirely my fault, I don't bash Tramp here.

    I'm particularly happy instead with the job done by `expect' for
    automation of remote log-ins.  In fact I see the way Tramp deals with
    remote logins is exactly an elisp kind of `expect'.

    That's just me of course, but maybe other feel the same and would
    find such method useful.

    Maybe that's not what most user want.  Maybe I could reuse entirely
    existing tramp mechanism for handling remote process (with ssh
    connections).  I will see.
    

    >> I'm interested in your feedback.  If there is interest I could
    >> volunteer to maintain it.
    Michael> 
    Michael> I'm happy for every volunteer. But please keep in mind,
    Michael> that Tramp is copyrighted by the FSF. This requires for
    Michael> every contributor of non-trivial changes to sign the legal
    Michael> papers of the FSF. Would you be willing to do so?
    Michael> 

    But of course.

    I apologize for this too long post,
    Mihai Luţescu