paths are sensative to double separators

paths are sensative to double separators

[Mike Mattie]

[-- Attachment #1: Type: text/plain, Size: 470 bytes --]

Hi,

I have noticed that paths in Emacs are sensitive to double separators e.g:

(load /foo/bar/baz.el)  ;; works
(load /foo/bar//baz.el) ;; broken

The same behavior occurs with (find-file).

This doesn't seem like a good thing. Is there a good reason for
it that I am not aware of ?

GNU Emacs 23.0.91.1 (i686-pc-linux-gnu, X toolkit) of 2009-03-07 on localhost

Cheers,
Mike Mattie

-- 
GnuPG Key: B9012279 is available from HKP server pgp.mit.edu

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: paths are sensative to double separators

[xah lee]

[-- Attachment #1: Type: text/plain, Size: 793 bytes --]

in unix-like OSes, double slash is effectively taken to mean root.
e.g. /foo/bar//baz.el would mean /baz.el
This convention is somewhat rooted in unixes.

 Xah

On Wed, Mar 18, 2009 at 6:50 PM, Mike Mattie <codermattie@gmail.com> wrote:

> Hi,
>
> I have noticed that paths in Emacs are sensitive to double separators e.g:
>
> (load /foo/bar/baz.el)  ;; works
> (load /foo/bar//baz.el) ;; broken
>
> The same behavior occurs with (find-file).
>
> This doesn't seem like a good thing. Is there a good reason for
> it that I am not aware of ?
>
> GNU Emacs 23.0.91.1 (i686-pc-linux-gnu, X toolkit) of 2009-03-07 on
> localhost
>
> Cheers,
> Mike Mattie
>
> --
> GnuPG Key: B9012279 is available from HKP server pgp.mit.edu
>



-- 
 Xah
∑ http://xahlee.org/

[-- Attachment #2: Type: text/html, Size: 1265 bytes --]

Re: paths are sensative to double separators

[Miles Bader]

Mike Mattie <codermattie@gmail.com> writes:
> I have noticed that paths in Emacs are sensitive to double separators e.g:
>
> (load /foo/bar/baz.el)  ;; works
> (load /foo/bar//baz.el) ;; broken
>
> The same behavior occurs with (find-file).
>
> This doesn't seem like a good thing. Is there a good reason for
> it that I am not aware of ?

It's a feature, as it makes filename entry more convenient, as you can
enter absolute filenames without erasing the existing path when entering
a filename.

Perhaps if Emacs were designed today, it might not do this pervasively,
and instead might just restrict this behavior to the filename prompting
functions (see, e.g. file-name-shadow-mode).

However, the current behavior has not been a problem in practice, as far
as I'm aware; the only place doubled slashes seem common is at the
beginning of a filename (because of naive DIR "/" REL_NAME concatention,
 with DIR == "/") , in which case the emacs behavior causes no change.

-Miles

-- 
Fast, small, soon; pick any 2.

Re: paths are sensative to double separators

[Harald Hanche-Olsen]

+ xah lee <xahlee@gmail.com>:

> in unix-like OSes, double slash is effectively taken to mean root.
> e.g. /foo/bar//baz.el would mean /baz.el
> This convention is somewhat rooted in unixes.

Actually, I believe posix says the exact opposite: Multiple slashes
are equivalent to a single slash, except at the head of the path,
where a double slash may have a different meaning. (On the Apollo
machines of old, running domain/os, a leading double slash indicated
the "network root", so you could specify //hostname/foo/bar to get
/foo/bar on the host named hostname. It seems they took the Sun slogan
"the network is the computer" to its logical conclusion.)

Miles Bader gave a different explanation for emacs's behaviour. It
seems odd to me that an interactive feature (a good one, too) should
influence how path names are interpreted in code, however.

- Harald

PS. On those old Apollos, we changed root's home directory from / to
/. in order to avoid being surprised by programs that constructed
paths as $HOME/foo/bar.

Re: paths are sensative to double separators

[Miles Bader]

Harald Hanche-Olsen <hanche@math.ntnu.no> writes:
> Miles Bader gave a different explanation for emacs's behaviour. It
> seems odd to me that an interactive feature (a good one, too) should
> influence how path names are interpreted in code, however.

I agree with you, but I'm not sure that it's reasonable to change it
now, given how long Emacs has behaved this way...

-Miles

-- 
x
y
Z!

Re: paths are sensative to double separators

[Sebastian Rose]

xah lee <xahlee@gmail.com> writes:
> in unix-like OSes, double slash is effectively taken to mean root.
> e.g. /foo/bar//baz.el would mean /baz.el
> This convention is somewhat rooted in unixes.


ls /usr//bin



-- 
Sebastian Rose, EMMA STIL - mediendesign, Niemeyerstr.6, 30449 Hannover
Tel.:  +49 (0)511 - 36 58 472
Fax:   +49 (0)1805 - 233633 - 11044
mobil: +49 (0)173 - 83 93 417
Http:  www.emma-stil.de

Re: paths are sensative to double separators

[Sebastian Rose]

Miles Bader <miles@gnu.org> writes:
> Mike Mattie <codermattie@gmail.com> writes:
>> I have noticed that paths in Emacs are sensitive to double separators e.g:
>>
>> (load /foo/bar/baz.el)  ;; works
>> (load /foo/bar//baz.el) ;; broken
>>
>> The same behavior occurs with (find-file).
>>
>> This doesn't seem like a good thing. Is there a good reason for
>> it that I am not aware of ?
>
> It's a feature, as it makes filename entry more convenient, as you can
> enter absolute filenames without erasing the existing path when entering
> a filename.


Maybe stick with the current behaviuor of the filename prompting
functions (convenience), but instead of greying out the `/home/' part,
remove it from the prompt?



As for the rest, I feel it's sick to stick with behaviours different
from all the rest of OSs and applications around.

While I would have agreed to weeks ago, that this never was an issue, I
now changed my mind completely. It's the first time I collided with this
issue when working on org-protocol.el. There are some odd differences
between find-file versus server-visit-files, find-file versus `ls',
emacs versus posix, emacs versus other applications in general.

Could someone please enlighten me why to stick with this? It's soo
non-standard:



Case 1:

     sh$ ls /home/sebastian//xy.txt
     sh$ gedit /home/sebastian//xy.txt

  versus

     C-x C-f /home//sebastian//xy.txt

  (OK, convenience, agreed, adjust it a little and it's fine.)



Case 2:

     sh$ emacsclient file:///home/sebastian/xy.txt

   versus

     C-x C-f file:///home/sebastian/xy.txt


   What we get in server-visit-files is this:

     `/home/sebastian/file:/home/sebastian/xy.txt'

   Completely odd, isn't it?
   The `/home/sebastian/' part of it is completly weired and just
   guessing.


   Please compare:

     sh$ gedit file:///home/sebastian/xy.txt
     sh$ mozilla file:///home/sebastian/xy.txt
     ... nautilus and _all_ the others but some GNU tools (ls...)

   Clearly an URL is reuested here, and the scheme is "file". But
   URL-schemes are completely ignored when it comes to emacsclient (and
   other GNU tools like `ls').


Resolving URL schemes would solve many problems (think of the scheme "c"
in "c:/autoexec.bat") and make emacs more usable (emacsclient "ftp://...").



Regards,

   Sebastian


--
Sebastian Rose, EMMA STIL - mediendesign, Niemeyerstr.6, 30449 Hannover
Tel.:  +49 (0)511 - 36 58 472
Fax:   +49 (0)1805 - 233633 - 11044
mobil: +49 (0)173 - 83 93 417
Http:  www.emma-stil.de

Re: paths are sensative to double separators

[Giorgos Keramidas]

On Wed, 18 Mar 2009 19:50:37 -0700, xah lee <xahlee@gmail.com> wrote:
> in unix-like OSes, double slash is effectively taken to mean root.
> e.g. /foo/bar//baz.el would mean /baz.el
> This convention is somewhat rooted in unixes.

Not really, no:

  keramida@kobe:/home/keramida$ cd /etc//security
  keramida@kobe:/etc/security$ pwd
  /etc/security

Having said that, I see that a double slash in find-file's prompt starts
over from the filesystem root.  That's slightly annoying when trying to
open a filename with double slashes, but it's also helpful when one
really *wants* to start over from the root of the filesystem :/

Re: paths are sensative to double separators

[Stefan Monnier]

> It's a feature, as it makes filename entry more convenient, as you can
> enter absolute filenames without erasing the existing path when entering
> a filename.

Yes, it's a feature in find-file (actually in the underlying
`read-file-name' function).  It's normally only used for interactive
filename entry, with one historical exception: `load'.
It's implemented by `substitute-in-file-name' which additionally does
expansion of envvars, so (load "$FOOBAR/lisp/toto.el") also works.

This `load' exception is undesirable, but at this point, it's not clear
whether it's best to fix it or to preserve compatibility.


        Stefan

Re: paths are sensative to double separators

[Stephen J. Turnbull]

Giorgos Keramidas writes:

 > Having said that, I see that a double slash in find-file's prompt starts
 > over from the filesystem root.  That's slightly annoying when trying to
 > open a filename with double slashes,

Which is rather uncommon and has an obvious, Emacs-wide solution: C-q /.

 > but it's also helpful when one really *wants* to start over from
 > the root of the filesystem :/

Which is much more common and deserves a one-keystroke solution.

Re: paths are sensative to double separators

[Giorgos Keramidas]

On Thu, 19 Mar 2009 23:20:04 +0900, "Stephen J. Turnbull" <stephen@xemacs.org> wrote:
>Giorgos Keramidas writes:
>> Having said that, I see that a double slash in find-file's prompt starts
>> over from the filesystem root.  That's slightly annoying when trying to
>> open a filename with double slashes,
>
> Which is rather uncommon and has an obvious, Emacs-wide solution: C-q /.

Unfortunately, quoting either slash of the double slash parts in
something like `C-x C-f /etc//foo' still restarts the search from the
filesystem root here, in GNU Emacs 23.0.91.1 (i386-unknown-freebsd8.0,
GTK+ Version 2.14.7) of 2009-03-14.

I think if `C-x C-f /etc/ C-q / foo' really passed "/etc//foo" as the
file path name to the find-file function, it might be a nice change that
doesn't feel too surprising to someone who relies on the current behavior.

>> but it's also helpful when one really *wants* to start over from
>> the root of the filesystem :/
>
> Which is much more common and deserves a one-keystroke solution.

Certainly :)

Re: paths are sensative to double separators

[Miles Bader]

Sebastian Rose <sebastian_rose@gmx.de> writes:
>> It's a feature, as it makes filename entry more convenient, as you can
>> enter absolute filenames without erasing the existing path when entering
>> a filename.
>
> Maybe stick with the current behaviuor of the filename prompting
> functions (convenience), but instead of greying out the `/home/' part,
> remove it from the prompt?

You can customize it to your liking; see the variable
`file-name-shadow-properties'.

-Miles

-- 
Bore, n. A person who talks when you wish him to listen.

Re: paths are sensative to double separators

[Stefan Monnier]

> Having said that, I see that a double slash in find-file's prompt starts
> over from the filesystem root.  That's slightly annoying when trying to
> open a filename with double slashes, but it's also helpful when one
> really *wants* to start over from the root of the filesystem :/

In normal Unix file systems, there cannot be a "filename with double
slashes".  Emacs is already careful to preserve double slashes in the
few known cases where they can appear (mostly in
"//<share>/<filename>"), so if you find more such cases, please report
them here so we can try and teach Emacs about them.


        Stefan

Re: paths are sensative to double separators

[David De La Harpe Golden]

Harald Hanche-Olsen wrote:


> 
> Actually, I believe posix says the exact opposite: Multiple slashes
> are equivalent to a single slash, except at the head of the path,
> where a double slash may have a different meaning. 


> (On the Apollo
> machines of old, running domain/os, a leading double slash indicated
> the "network root",



On ammig // is also meaningful, not just leading in leading positions, 
as the amiga "parent directory" syntax.

i.e.
unix
foo/bar/../baz

amiga

foo/bar//baz



Emacs used to have an amiga port, but not sure whether it used 
ixemul.library  (analogous to cygwin) or was native. In the latter case, 
it would have mattered.

Re: paths are sensative to double separators

[Mike Mattie]

[-- Attachment #1: Type: text/plain, Size: 1499 bytes --]

On Thu, Mar 19, 2009 at 09:33:56AM -0400, Stefan Monnier wrote:
> > It's a feature, as it makes filename entry more convenient, as you can
> > enter absolute filenames without erasing the existing path when entering
> > a filename.
> 
> Yes, it's a feature in find-file (actually in the underlying
> `read-file-name' function).  It's normally only used for interactive
> filename entry, with one historical exception: `load'.
> It's implemented by `substitute-in-file-name' which additionally does
> expansion of envvars, so (load "$FOOBAR/lisp/toto.el") also works.
> 
> This `load' exception is undesirable, but at this point, it's not clear
> whether it's best to fix it or to preserve compatibility.

I can certianly understand when find-file has interesting behavior, in
fact I expect that sort of thing from Emacs. Especially from the "Emacs still
runs on my steam powered dinosaur" angle.

the 'load' case is what spurred me to bring up the issue. I cannot
be sure that some path set by the user contains a trailing '/',
and so I need to append one.

I can, and do now check for this:

(replace-regexp-in-string "/+" "/" path)

but having to gaurd every path is simply begging for errors.
When the beta period is over I would like to revisit the
issue with a patch.

Thank you for expanding on my question so thoroughly,
it was educational.

Cheers,
Mike Mattie


> 
>         Stefan

-- 
GnuPG Key: B9012279 is available from HKP server pgp.mit.edu

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: paths are sensative to double separators

[Giorgos Keramidas]

On Thu, 19 Mar 2009 11:47:26 -0400, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> Having said that, I see that a double slash in find-file's prompt starts
>> over from the filesystem root.  That's slightly annoying when trying to
>> open a filename with double slashes, but it's also helpful when one
>> really *wants* to start over from the root of the filesystem :/
>
> In normal Unix file systems, there cannot be a "filename with double
> slashes".  Emacs is already careful to preserve double slashes in the
> few known cases where they can appear (mostly in
> "//<share>/<filename>"), so if you find more such cases, please report
> them here so we can try and teach Emacs about them.

I will, thanks :)

Re: paths are sensative to double separators

[Richard M Stallman]

    Miles Bader gave a different explanation for emacs's behaviour. It
    seems odd to me that an interactive feature (a good one, too) should
    influence how path names are interpreted in code, however.

This conversion concerns entering file names in the minibuffer,
and does not occur in most functions when they are called from Lisp code.

In particular, I find that find-file called from Lisp converts //
equivalent to one /.  However, strangely there is a difference between
(find-file "~/xmail/stallman.xmail") and (find-file "~/xmail//stallman.xmail").
The former asks me whether to convert the Babyl file to mbox.
The latter just visits the Babyl file in Rmail without conversion.
This seems to be a bug.

Re: paths are sensative to double separators

[Stefan Monnier]

>    What we get in server-visit-files is this:
>      `/home/sebastian/file:/home/sebastian/xy.txt'

This bug was fixed a few days ago.  Of course, to really work, you need
to (url-handler-mode 1) in order to tell Emacs that it should try and
understand URLs.


        Stefan

Re: paths are sensative to double separators

[Stefan Monnier]

> the 'load' case is what spurred me to bring up the issue.  I cannot
> be sure that some path set by the user contains a trailing '/',
> and so I need to append one.

My crystal ball tells me you shouldn't worry about such details and use
higher-level functions such as expand-file-name.


        Stefan

Re: paths are sensative to double separators

[Sebastian Rose]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>    What we get in server-visit-files is this:
>>      `/home/sebastian/file:/home/sebastian/xy.txt'
>
> This bug was fixed a few days ago.  Of course, to really work, you need
> to (url-handler-mode 1) in order to tell Emacs that it should try and
> understand URLs.

I learn something every day I read here :-)


Thanks,

  Sebastian

Re: paths are sensative to double separators

[Xavier Maillard]

   Harald Hanche-Olsen <hanche@math.ntnu.no> writes:
   > Miles Bader gave a different explanation for emacs's behaviour. It
   > seems odd to me that an interactive feature (a good one, too) should
   > influence how path names are interpreted in code, however.

   I agree with you, but I'm not sure that it's reasonable to change it
   now, given how long Emacs has behaved this way...

I agree with Miles here although the "posix way" should be also
supported (at the user discretion -i.e. via a defcustom).

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Re: paths are sensative to double separators

[Mike Mattie]

[-- Attachment #1: Type: text/plain, Size: 600 bytes --]

On Thu, Mar 19, 2009 at 04:34:26PM -0400, Stefan Monnier wrote:
> > the 'load' case is what spurred me to bring up the issue.  I cannot
> > be sure that some path set by the user contains a trailing '/',
> > and so I need to append one.
> 
> My crystal ball tells me you shouldn't worry about such details and use
> higher-level functions such as expand-file-name.
> 
> 
>         Stefan

Thank you for the suggestion. Finding the equivalant distributed Emacs functions
for my home-brew defuns is a perrenial quest.


-- 
GnuPG Key: B9012279 is available from HKP server pgp.mit.edu

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: paths are sensative to double separators

[Byung-Hee HWANG]

Giorgos Keramidas <keramida@ceid.upatras.gr> writes:

> On Wed, 18 Mar 2009 19:50:37 -0700, xah lee <xahlee@gmail.com> wrote:
>> in unix-like OSes, double slash is effectively taken to mean root.
>> e.g. /foo/bar//baz.el would mean /baz.el
>> This convention is somewhat rooted in unixes.
>
> Not really, no:
>
>   keramida@kobe:/home/keramida$ cd /etc//security
>   keramida@kobe:/etc/security$ pwd
>   /etc/security

SunOS's screenshot:

$ uname -a
SunOS rose0 5.9 Generic_122300-13 sun4u sparc SUNW,Sun-Fire-880
$ pwd
/user2/hak/z9618029
$ cd /etc//security
$ pwd
/etc/security
$

> Having said that, I see that a double slash in find-file's prompt starts
> over from the filesystem root.  That's slightly annoying when trying to
> open a filename with double slashes, but it's also helpful when one
> really *wants* to start over from the root of the filesystem :/

Sincerely,

-- 
Byung-Hee HWANG, KNU 
∑ WWW: http://izb.knu.ac.kr/~bh/

Re: paths are sensative to double separators

[xah lee]

[-- Attachment #1: Type: text/plain, Size: 1186 bytes --]

Thanks all for the correction.
 Xah

On Wed, Mar 18, 2009 at 10:42 PM, Harald Hanche-Olsen
<hanche@math.ntnu.no>wrote:

> + xah lee <xahlee@gmail.com>:
>
> > in unix-like OSes, double slash is effectively taken to mean root.
> > e.g. /foo/bar//baz.el would mean /baz.el
> > This convention is somewhat rooted in unixes.
>
> Actually, I believe posix says the exact opposite: Multiple slashes
> are equivalent to a single slash, except at the head of the path,
> where a double slash may have a different meaning. (On the Apollo
> machines of old, running domain/os, a leading double slash indicated
> the "network root", so you could specify //hostname/foo/bar to get
> /foo/bar on the host named hostname. It seems they took the Sun slogan
> "the network is the computer" to its logical conclusion.)
>
> Miles Bader gave a different explanation for emacs's behaviour. It
> seems odd to me that an interactive feature (a good one, too) should
> influence how path names are interpreted in code, however.
>
> - Harald
>
> PS. On those old Apollos, we changed root's home directory from / to
> /. in order to avoid being surprised by programs that constructed
> paths as $HOME/foo/bar.
>

[-- Attachment #2: Type: text/html, Size: 1650 bytes --]

Re: paths are sensative to double separators

[Stephen J. Turnbull]

Giorgos Keramidas writes:

 > > Which is rather uncommon and has an obvious, Emacs-wide solution: C-q /.
 > 
 > Unfortunately, quoting either slash of the double slash parts in
 > something like `C-x C-f /etc//foo' still restarts the search from the
 > filesystem root here

To me quoting the first slash would be a no-op, but quoting the second
slash should work.  But it does the same thing you observe in 22.1.1
here.  So I guess that's intentional.

I think it's astonishing that Emacs overrides the user's explicit
intent, and it should be changed.

 > I think if `C-x C-f /etc/ C-q / foo' really passed "/etc//foo" as
 > the file path name to the find-file function, it might be a nice
 > change that doesn't feel too surprising to someone who relies on
 > the current behavior.

I can't imagine anyone relies on having Emacs deliberately disobey
"/foo/" C-q "/" and convert it to "/".

Hm, interesting.  In the minibuffer, XEmacs takes C-q at its word, but
find-file (and completion) indeed converts "/foo/bar//" to "/".  This
is really ugly IMO.  I wonder what it takes to fix.  Interestingly,
"/etc/./foo" and "/etc/bar/../foo" work as expected, but both XEmacs
and Emacs 22.1.1 canonicalize the path to "/etc/foo".

N.B.  This matters if you want to use URLs, because not only do you
need the colon-double-slash to define the authority (which could be
special-cased in the function that canonicalizes paths, I guess), but
the RFCs don't define the semantics of double slash (and the Mercurial
URL hg://foo/bar means something different from hg://foo//bar).

Re: paths are sensative to double separators

[Stefan Monnier]

> I can't imagine anyone relies on having Emacs deliberately disobey
> "/foo/" C-q "/" and convert it to "/".

C-q / doesn't say "mark this slash as a special slash that shouldn't
be magical.  It only says "don't use the command bound to slash, but
instead just insert a slash char".

The "/foo// -> /" conversion is done much later (as can be seen since
hitting DEL after having hit / gets you back to /foo/).

> N.B.  This matters if you want to use URLs, because not only do you

find-file does not work for URLs unless you enable url-handler-mode.
If you enable url-handler-mode, then "file:///foo" will not be converted
to "/foo".  I.e. I think it works correctly, including for URLs.


        Stefan

Re: paths are sensative to double separators

[Stephen J. Turnbull]

Stefan Monnier writes:

 > > I can't imagine anyone relies on having Emacs deliberately disobey
 > > "/foo/" C-q "/" and convert it to "/".
 > 
 > C-q / doesn't say "mark this slash as a special slash that shouldn't
 > be magical.  It only says "don't use the command bound to slash, but
 > instead just insert a slash char".

My opinion is that slashes should not be magical at all, except as
electric key strokes in UI.  If the facility were implemented that
way, I would automatically get the behavior I prefer (and at least
some others seem to agree).

 > > N.B.  This matters if you want to use URLs, because not only do you
 > 
 > find-file does not work for URLs unless you enable url-handler-mode.
 > If you enable url-handler-mode, then "file:///foo" will not be converted
 > to "/foo".  I.e. I think it works correctly, including for URLs.

The question I asked is, will "hg://authority//foo" be converted to
"hg://authority/foo"?  Url-handler-mode is clearly broken in 22.1.1.
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
worse, C-x C-f C-a C-k "file:///Users/steve//.zshrc" RET ==> wrong
type argument: stringp, nil.  I hope/assume this works better in 23,
but maybe you should check.

Re: paths are sensative to double separators

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 20 Mar 2009 08:57:45 -0400
> Cc: Giorgos Keramidas <keramida@ceid.upatras.gr>, xah@xahlee.org,
> 	emacs-devel@gnu.org, Mike Mattie <codermattie@gmail.com>
> 
> > I can't imagine anyone relies on having Emacs deliberately disobey
> > "/foo/" C-q "/" and convert it to "/".
> 
> C-q / doesn't say "mark this slash as a special slash that shouldn't
> be magical.  It only says "don't use the command bound to slash, but
> instead just insert a slash char".

Right.  If one wants to quote a file name, start it with a "/:"; see
the node "Quoted File Names" in the Emacs manual.  I don't think that
it will defeat the "//" case, but I have no system to check that
myself.

Re: paths are sensative to double separators

[Stefan Monnier]

>> > I can't imagine anyone relies on having Emacs deliberately disobey
>> > "/foo/" C-q "/" and convert it to "/".
>> 
>> C-q / doesn't say "mark this slash as a special slash that shouldn't
>> be magical.  It only says "don't use the command bound to slash, but
>> instead just insert a slash char".

> Right.  If one wants to quote a file name, start it with a "/:"; see
> the node "Quoted File Names" in the Emacs manual.  I don't think that
> it will defeat the "//" case,

Depends what you mean by "defeat".  E.g. C-x C-f /:/foo///bar RET
will open /foo/bar.


        Stefan

Re: paths are sensative to double separators

[Stefan Monnier]

> 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.

> worse, C-x C-f C-a C-k "file:///Users/steve//.zshrc" RET ==> wrong
> type argument: stringp, nil.  I hope/assume this works better in 23,
> but maybe you should check.

Just checked: got the same error (plus a few other odd things along the
way).  Thanks for bringing it up,


        Stefan

Re: paths are sensative to double separators

[Giorgos Keramidas]

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 :-)

Re: paths are sensative to double separators

[Sebastian Rose]

Giorgos Keramidas <keramida@ceid.upatras.gr> writes:
>     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 :-)

+1

Accepting URIs is the standard everywhere.

Far the most applications accept URIs. Either a path is absolute,
relative or an URI. It should be supported by default.

  Sebastian

Re: paths are sensative to double separators

[Miles Bader]

Sebastian Rose <sebastian_rose@gmx.de> writes:
> Far the most applications accept URIs.

Er, I suspect that's not actually true...

Many recently written "big momma" apps accept URIs.

The majority of apps, probably not.

-Miles

-- 
Run away!  Run away!

Re: paths are sensative to double separators

[Stephen J. Turnbull]

Giorgos Keramidas writes:

 > 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.

This is (or should be) defined by the scheme.  Emacs should only do
canonicalization when the scheme defines it, or there's clear user
demand for canonicalization in a widely used scheme.

 > RFC 2396

... is obsolete.  Cf. RFC 3986, which probably says the same thing but
I don't have time to check the details.

 > A list of URI schemes that support this sort of path-parsing would
 > be really nice to have as a customizable option :-)

Other way around.  See above.

Re: paths are sensative to double separators

[Giorgos Keramidas]

On Sat, 21 Mar 2009 13:43:41 +0900, "Stephen J. Turnbull" <stephen@xemacs.org> wrote:
> Giorgos Keramidas writes:
>
>  > 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.
>
> This is (or should be) defined by the scheme.  Emacs should only do
> canonicalization when the scheme defines it, or there's clear user
> demand for canonicalization in a widely used scheme.

Yes, that seems to make more sense :)