[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Integrate Tramp

From: Richard Stallman
Subject: Re: Integrate Tramp
Date: Fri, 21 Jun 2002 10:29:29 -0600 (MDT)

    However, internally, Tramp still uses the old filenames.  This means
    that hitting C-x C-f in a buffer visiting a file via Tramp will still
    show "/[sm/address@hidden" (plus some suffix) instead of
    "/address@hidden:" (plus some suffix).

That will tend to confuse users.

    The other alternative would be to change Tramp to use a filename
    format that's similar to the format used by Ange-FTP and to call
    Ange-FTP for some user/host combinations if the method is not
    specified.  This would entail removing ange-ftp from
    file-name-handler-alist, I guess.  It would also mean that all Tramp
    filenames should use the Ange-FTP `style'.

That seems like the clean approach.  Removing ange-ftp from direct
presence in the file-name-handler-alist is ok, since the feature will
still *work* properly using the new mechanism.

    Tramp knows the following kinds of filenames (square brackets are
    literal characters):


(Note that I am not sure whether the strings `hop1' and `hop2' that
appear in the last example are literal or metasyntactic variables.)

I suggest these syntaxes:


If there is some sort of "hop" information that needs to be given,
the last could look like


This seems both simpler and more natural than either your current
syntax or your current proposal.  `[multi]' seems unnecessary, since
you can determine how many colons there are.  The
file-name-handler-alist can specify "^/\\([^/:]*[^/:.]:\\)+" to match
the whole prefix.

    * We designate a special method "ftp" which, when specified, invokes

That is a good idea.

    * Tramp is augmented with an alist of user/host pairs and default
      methods.  This alist can be used to tell Tramp to use any method,
      including "ftp", for a specific user/host combination.

    * Specifying the method in the filename overrides this alist.

Those seem like good ideas too.  Perhaps the alist should contain
regexps to match against the user and the host.

In addition, there should be a separate customizable user option that
specifies the ultimate choice of method, for when the user/host pair
is not mentioned in the alist.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]