Re: paths are sensative to double separators

[Giorgos Keramidas <keramida@ceid.upatras.gr>]

On Fri, 20 Mar 2009 16:19:18 -0400, Stefan Monnier <monnier@IRO.UMontreal.CA> wrote:
>> The question I asked is, will "hg://authority//foo" be converted to
>> "hg://authority/foo"?
>
> Assuming that the URL library is extended to understand the `hg'
> protocol, and that url-handler-mode is modified to provide access to it:
> no, such a conversion will not take place.
>
>> Url-handler-mode is clearly broken in 22.1.1.
>
> It's not very reliable in Emacs-23 either, to tell you the truth, which
> is why it's not enabled by default.
>
>> It doesn't understand the hg: scheme, so after enabling url handler
>> mode, C-x C-f C-a C-k "hg://" ==> "/" in the minibuffer, and even
>
> Indeed, there is no support for the `hg' protocol in the URL library.

The double slash in Mercurial repositories is actually a semi-standard
way of referring to pathnames rooted at the `filesystem root' instead of
the default starting directory for the particular URI authority.

RFC 2396 section 5.2 defines an _example_ scheme of resolving relative
URI based on an application-specific base URI.  Part of that example
scheme states:

   5) If the path component begins with a slash character ("/"), then
      the reference is an absolute-path and we skip to step 7.

Based on an interpretation of this RFC example, Mercurial (and possibly
other systems too) interpret URIs using a scheme that maps:

    ssh://user@host/foo         The file `foo' under the HOME directory
                                of `user'.

    ssh://user@host//foo        The file `foo' at the file system root.

This interpretation of URIs is not specific to `hg://' URIs, so if we do
something that parses this sort of double-slash path in the URL library,
it may be nice if we enable it at least for the first path delimiting
slash after the URI authority for most schemes.  Or at least if we can
make it configurable which schemes support this sort of thing.  A list
of URI schemes that support this sort of path-parsing would be really
nice to have as a customizable option :-)