[dev] [surf] URI handling, with patch

Hi,

Surf takes a URI as a command line argument or via dmenu/xprop. I have
two small and unimportant problems with the way it is currently done.

First, I am not sure surf handles the command line argument with the
URI in the correct way. The issue here is that everything that doesn't
have a "://" string inside is assumed to be http: type URI, but this
is mildly problematic when trying to open locally-stored HTML files
(file:// URI). Currently, to open a local file, you can specify 'surf
file:///path/to/file.html' and it will work fine. However, this will
break tab-completion for relative links, since the shell will try to
expand from / after you type in file://. This means that to open a
local HTML file with tab-completion assistance, you must specify its
path from /, rather than using ~, ., or .. shortcuts.

Second, dmenu's "suggested" integration with surf is a bit dodgy. If,
for example, a user is viewing surf.suckless.org and they wish to
navigate to suckless.org, they would be required to strike
shift+return in order to actually visit suckless.org. If the shift key
is not used, the current page will simply refresh. The reason for the
refresh is because dmenu matches the input text against the selected
text, and if it is a substring of the selected text, it will just
output the selected text when return has been struck, which means the
page simply refreshes because the new URI is the same as the current
one.

The first problem is a simple patch, but I'm not sure what is the best
approach here. As far as I can see, I think it would be best to assume
that URIs without "://" in them are actually file:// types, and
http:// should be required for all http:// type URIs. It would be
trivial to insert a leading "http://" to the URI using shell tools if
a scripting solution is required, and in many cases, the "http://" is
already in place. A suggested patch is included in this mail, though
it isn't great because I'm using an extra struct stat for data that I
wind up not using, and so there is unnecessary overhead.

As far as I know, the dmenu problem is a feature for one set of users
and an issue for another set. I wouldn't know how to please everyone
on this. Feedback appreciated.

Ryan

diff -r dbb565b8d61c surf.c
--- a/surf.c Fri Jun 25 09:42:58 2010 +0200
+++ b/surf.c Tue Aug 17 18:41:12 2010 -0400
@@ -384,12 +384,20 @@
 loaduri(Client *c, const Arg *arg) {
         char *u;
         const char *uri = (char *)arg->v;
+ struct stat sb;
         Arg a = { .b = FALSE };

         if(strcmp(uri, "") == 0)
                 return;
- u = g_strrstr(uri, "://") ? g_strdup(uri)
- : g_strdup_printf("http://%s", uri);
+ if(g_strrstr(uri, "://")) {
+ u = g_strdup(uri);
+ }
+ else if (stat(uri,&sb) ) {
+ u = g_strdup_printf("http://%s", uri);
+ }
+ else {
+ u = g_strdup_printf("file://%s", uri);
+ }
         /* prevents endless loop */
         if(c->uri && strcmp(u, c->uri) == 0) {
                 reload(c, &a);
Received on Wed Aug 18 2010 - 00:52:40 CEST