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 22:06:55 +0200 Message-ID: <877g6rhe00.fsf@gmail.com> References: <87mwfofewj.fsf@bzg.ath.cx> <87ob04gnz1.fsf@gmail.com> <87y4z7rgas.fsf@Rainer.invalid> <87d2gjhglr.fsf@gmail.com> <87ha5vra6p.fsf@Rainer.invalid> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:44972) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WZn9G-0005MF-GY for emacs-orgmode@gnu.org; Mon, 14 Apr 2014 16:06:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WZn9A-0002ES-1x for emacs-orgmode@gnu.org; Mon, 14 Apr 2014 16:06:34 -0400 Received: from mail-wg0-x232.google.com ([2a00:1450:400c:c00::232]:47588) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WZn99-0002EA-SK for emacs-orgmode@gnu.org; Mon, 14 Apr 2014 16:06:28 -0400 Received: by mail-wg0-f50.google.com with SMTP id x13so8485613wgg.33 for ; Mon, 14 Apr 2014 13:06:27 -0700 (PDT) In-Reply-To: <87ha5vra6p.fsf@Rainer.invalid> (Achim Gratz's message of "Mon, 14 Apr 2014 21:19:10 +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 Achim Gratz writes: > groff has this snippet: > > > (if (file-name-absolute-p raw-path) > (concat "file://" (expand-file-name raw-path)) > (concat "file://" raw-path))) This needs to be fixed, along with ox-man.el. Anyway, that wasn't introduced with the patch being discussed. > Well, there's the option of correctly parsing into scheme, authority, > path, query and fragment... But that is probably not going into 8.2.6 > in any case. I don't think we need to completely parse the URI because: - we are not going to consume it, - Org syntax is not completely compatible with RFC3986 (e.g., search options like [[file:test.org::* My headline]]). I think we need scheme, authority, path+query+fragment, and search options. At the moment, the parser handles scheme, authority+path+query+fragment and search options. `url-generic-parse-url' may help, too. We also need a function to build back the link, in order to make life of back-end developers easier. This is why authority is needed. >> 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. > > I forgot what the previous state was, but trying to fix file: URIs > without correctly parsing them sounds like a losing proposition. Previous state was, in a nutshell, to recognize scheme:blob, which leads to the same kind of problem since blob may or may not contain the authority part. Regards, -- Nicolas Goaziou