Re: [dev] [surf][patch] Add support for mailto links

From: Christoph Lohmann <20h_AT_r-36.net>
Date: Mon, 19 Jan 2015 22:44:11 +0100

Greetings.

On Mon, 19 Jan 2015 22:44:11 +0100 Markus Teich <markus.teich_AT_stusta.mhn.de> wrote:
> Christoph Lohmann wrote:
> > There is now PLUMB() in config.h, which will be run, when some URI does
> > not start with "about:", "http://" or "https://". Please test this if
> > there are some other URIS that should be handled from some outside ap‐
> > plication.
>
> Heyho Christoph,
>
> What about "file:///"?

This was discussed on IRC, which convinced me to include file:// in the
browser handling too.

The ideal case would be a plumber handling all URIs and just giving
http:// and https://, which is HTML to surf. Other files should be han‐
dled by being downloaded by local media players etc. But if surf is run
on a system without such a plumber it’s useless. The main users are peo‐
ple without such a plumber, so file:// should be run in the webbrowser.
There simply is no good default browser for file://.

Another argument is that when you give the browser a file:// argument
you want it to be opened in the browser. This clearly breaks the global
URI space, where there should be just one browser handling all the
plumbing.

I can’t think of a solution now how this could be handled. Should there
be metadata of how some URI should be displayed? Like you have see(1),
edit(1), compose(1) and print(1) in mailcap? Should there be different
open modes? I now have Mod + o for opening some link in the plumber.
Should there be simply Mod + e for edit, Mod + c for compose etc.? This
wouldn’t handle it bi‐directional, so someone giving out some URI on the
web won’t edit, compose, but just see. Introducing the modes only local‐
ly will block the idea of a global URI space.

Anyone has thought about this or tried something out?


Sincerely,

Christoph Lohmann
Received on Mon Jan 19 2015 - 22:44:11 CET