Re: URL syntax (was: Re: Tramp, "[]" in file names, and file-expand-wildcards)

[William M. Perry]

Simon Josefsson <address@hidden> writes:

> address@hidden (William M. Perry) writes:
> 
> > Richard Stallman <address@hidden> writes:
> >
> >>       After calling
> >>     (url-setup-file-name-handlers) manually, I could do C-x C-v
> >>     http://www.gnu.org/ and it did the right thing.
> >> 
> >> Why is it necessary to do that manually?  Is that a bug, or a feature?
> >
> > It isn't enabled automatically so that people don't get bitten by any bugs
> > in the support.  I think there must still be some lurking somewhere
> > because Gnus freaks out occasionally trying to do (file-exists-p nil)
> 
> The URL file name handler doesn't seem to like being nestled:
> 
> (expand-file-name "foo" (file-name-as-directory
>                        (expand-file-name "foo:bar"
>                                          gnus-cache-directory)))
> "foo:foo"
> 
> it should return:
> 
> (expand-file-name "foo" (file-name-as-directory
>                        (expand-file-name "foo:bar"
>                                          gnus-cache-directory)))
> "/home/jas/News/cache/foo:bar/foo"

I've got a preliminary fix for this in in my local workspace.  The problem
is that I put a generic regular expression on there that should match any
value URL scheme.  This unfortunately conflicts with some valid filenames
(gnus' cache files most noticably).

The alternative is building up a gigantic regular expression like:

^\(hotlist\|vars\|util\|proxy\|privacy\|parse\|ns\|nfs\|news\|misc\|methods\|mailto\|ldap\|irc\|imap\|https\|http\|history\|handlers\|gw\|ftp\|file\|expand\|dired\|cookie\|cid\|cache\|auto\|auth\|about\|info\|man\|rlogin\|telnet\|tn3270\|data\|snews\):

in the file-name-handlers-alist.  And then you lose if somebody writes a
new protocol loader and installs it.

And I can't cheat and set the regexp to (...):// because not all schemes
have // in them. :(

-bp
-- 
Ceterum censeo vi esse delendam