URL-like Tramp syntax

URL-like Tramp syntax

[Michael Albinus]

Hi,

Tramp supports three different syntaxes for remote files, see variable
`tramp-syntax'. According to the bug reports over the last 9 years, the
URL-like syntax hasn't been used ever (IIRC).

Therefore, I plan to remove it from the upcoming Tramp 2.2.8. At some
few places, this will also simplify the implementation.

Any objections?

Best regards, Michael.

Re: URL-like Tramp syntax

[Davis Herring]

> Tramp supports three different syntaxes for remote files, see variable
> `tramp-syntax'. According to the bug reports over the last 9 years, the
> URL-like syntax hasn't been used ever (IIRC).
> 
> Therefore, I plan to remove it from the upcoming Tramp 2.2.8. At some
> few places, this will also simplify the implementation.

You've written recently about the inherent ambiguities of Tramp file
name syntax.  Is the URL syntax (or, for that matter, the third syntax)
less problematic in this regard?  It might be better to switch to it
than away from it...

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: URL-like Tramp syntax

[Michael Albinus]

Davis Herring <herring@lanl.gov> writes:

Hi Davis,

> You've written recently about the inherent ambiguities of Tramp file
> name syntax.  Is the URL syntax (or, for that matter, the third syntax)
> less problematic in this regard?  It might be better to switch to it
> than away from it...

I don't believe this is preferred. Tramp's URL-like syntax competes with
url-handlers.el. This is another reason I believe we should remove it
from Tramp.

If we want to solve the ambiguities in Tramp's primary syntax, we should
change the separator between methods and user/host names. Or we should
switch to the syntax used in XEmacs. But that's another story.

> Davis

Best regards, Michael.

Re: URL-like Tramp syntax

[Stefan Monnier]

>> You've written recently about the inherent ambiguities of Tramp file
>> name syntax.  Is the URL syntax (or, for that matter, the third syntax)
>> less problematic in this regard?  It might be better to switch to it
>> than away from it...

The ambiguities are only in the added shorthands, so they can be
resolved trivially (as we did) by disallowing some shorthands.

> I don't believe this is preferred. Tramp's URL-like syntax competes with
> url-handlers.el. This is another reason I believe we should remove it
> from Tramp.

Indeed.

> If we want to solve the ambiguities in Tramp's primary syntax, we should
> change the separator between methods and user/host names.

I think the problem is minor enough not to justify such a change.


        Stefan