Greetings. On Mon, 19 Jan 2015 22:44:11 +0100 Markus Teich <markus.te...@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
