Re: [Emacs-diffs] trunk r116230: Fix bug #16558 with w32-shell-execute on remote file names.

[Stefan Monnier]

>> That look reasonable (and didn't involve any remote connection or any
>> such problem).
> How is the 2nd one reasonable?

Why shouldn't it be?  It's in a context where url-handler-mode is
deactivated, so Emacs has no reason to presume that it's a URL.

> It means we will pass it through
> expand-file-name,

Which might be the right thing to do.

>   (expand-file-name "http://foo.com/wherever/index.html";)
>     => "d:/gnu/bzr/emacs/trunk/http:/foo.com/wherever/index.html"

If d:/gnu/bzr/emacs/trunk/http:/foo.com/wherever/ exists, then I'd argue
it was the right thing to do.

>> And faccess("http://foo.com/wherever/";) should presumably tell you that
>> dir doesn't exist.  So it behaves just as well as the current code.
> By sheer luck, if you ask me.

The name *is* ambiguous.  The only reason such ambiguity is frequent and
non-problematic is because conflicts rarely arise.  So I don't consider
this to be luck.  It's basically by design (design of the URL name space).

>> The connection between the core problem of detecting the case of
>> (w32-shell-execute "dir/file") and the check of file-name-handlers is
>> really non-obvious.
> If DOCUMENT doesn't have file handlers, it is more likely to be a
> local file or directory.

The correlation is weak.  I don't think this heuristic is worth much if
anything in this context.

> I don't see how your proposal is simpler than what's already there, or
> better, sorry.

It's better because all the checks are *directly* related to the problem
at hand: detecting non-absolute file names which include
a directory component.

If you only care about simpler, then we can just remove the
file-name-handler check and only rely on the faccess check.
That should work just as well.


        Stefan