Re: [Vimprobable-users] Improve handling of file parameters

[Morgan H. <mt...@gm...>]

On Mon, Feb 25, 2013 at 4:30 PM, Hannes Schüller <ha...@yl...> wrote:

> Has it occured to you that it might be much more convenient for
> everyone involved to simply... subscribe? It's not like this list will
> send tons of traffic to your inbox. As you can see, there have been a
> couple of other responses to this thread and it's virtually impossible
> that everybody will remember to keep the CC in all of them.
>

Alright, you've sold me. Subscribed.


>
> > > on your command line. Your solution would make it impossible to call
> > > URLs from a directory which has a file or subdirectory with the same
> > > name as the URL. E.g. if your file system looks like this:
> > > .
> > > ..
> > > http://www.example.org
> > > and you call
> > > vimprobable http://www.example.org
> > > it will call the local directory instead of the URL. No workaround
> > > possible. Before someone argues that this is a rather academic
> > > example, I would like to point out that such a directory structure
> > > is not so uncommon on machines used for web development.
> > >
> >
> > Yeah, I considered this, though I was thinking that would be a rare
> > situation. Not being a web developer personally, that may have been a
> > bit presumptuous. Perhaps it may be better to check if the parameter
> > is already a URI first, before checking if it is a file? At least
> > that way, there would always be a workaround in case of name
> > conflicts.
>
> And how would you detect if something is a URL? The only reliable way I
> can think of would be sending a skeleton HTTP request out to see if
> there is a response. Which would involve potential failure sources like
> DNS which are completely outside the scope of the browser itself.
>
>
No, I would rather not do that and I agree that overly complicate things
and potentially slow down the initial opening of the browser which is
obviously not something we'd want. I was thinking something more along the
lines of just verifying that the parameter is a properly formed URI, and if
it is, we trust the user and explicitly do what they ask. I'm not entirely
versed in the details of RFC 3986 [1], but to refer back to your example, I
was thinking something along these lines:

vp2 www.example.com
Check for file, if it exists, build the URI as in my patch, otherwise fall
back to URL.

vp2 http://www.example.com
Properly formed URI, use it.

Now the only other case would be a file named "http://www.example.com"
which on any of the systems I have available is not a legal filename
anyway. That would be the one case where the user would need to then
properly specify the file:// prefix, though like I said, I'm not sure this
scenario is even possible. Either way, at least with this behavior, there
is always a reasonable workaround. Better suggestions are welcome. :)

Regards,
Morgan

[1] http://www.ietf.org/rfc/rfc3986.txt