From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [BUG] Cannot export a raw link Date: Mon, 14 Apr 2014 21:10:40 +0200 Message-ID: <87d2gjhglr.fsf@gmail.com> References: <87mwfofewj.fsf@bzg.ath.cx> <87ob04gnz1.fsf@gmail.com> <87y4z7rgas.fsf@Rainer.invalid> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:33925) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WZmGn-0005rZ-F6 for emacs-orgmode@gnu.org; Mon, 14 Apr 2014 15:10:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WZmGj-0005dL-25 for emacs-orgmode@gnu.org; Mon, 14 Apr 2014 15:10:17 -0400 Received: from mail-we0-x231.google.com ([2a00:1450:400c:c03::231]:62670) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WZmGi-0005d7-Rc for emacs-orgmode@gnu.org; Mon, 14 Apr 2014 15:10:12 -0400 Received: by mail-we0-f177.google.com with SMTP id u57so8571025wes.36 for ; Mon, 14 Apr 2014 12:10:11 -0700 (PDT) In-Reply-To: <87y4z7rgas.fsf@Rainer.invalid> (Achim Gratz's message of "Mon, 14 Apr 2014 19:07:07 +0200") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Achim Gratz Cc: emacs-orgmode@gnu.org Hello, Achim Gratz 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) test.html file:///test.html file:///test.html So, it looks good so far. Unfortunately, it fails with a non-empty authority. E.g., file://hostname/test.org becomes test.html 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