Hello, Achim Gratz <strom...@nexgo.de> writes:
> It still isn't correct. If you put "//" after a "file:" scheme, then > you need to put an authority there (an empty authority means localhost > in some contexts, but then the path has to start with a slash). The patch didn't change "file" scheme handling. It changed "http", "https" and "ftp". > Also, with the new implementation relative file: links would stop > working. A relative file link cannot have any slashes after the > scheme, while an absolute path must have three (not going into the > vagaries of trying to use UNC paths and file links that work around > the security policies of various web browsers). With latest patch and following Org buffer file:test.org file:/test.org file:///test.org I get (HTML export) <a href="test.html">test.html</a> <a href="file:///test.html">file:///test.html</a> <a href="file:///test.html">file:///test.html</a> So, it looks good so far. Unfortunately, it fails with a non-empty authority. E.g., file://hostname/test.org becomes <a href="hostname/test.html">test.html</a> So it is not satisfactory. One possibility is to store somewhere in the parsed link that the URI provided the "//" part, and, if so, re-introduce it unconditionally when building back the link. Another one is to drop the whole thing, return to previous state, and implement ad-hoc rules to fix "file:", which is probably the only scheme introducing problems. Regards, -- Nicolas Goaziou
