From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel P Gomez Subject: Re: How to keep correct filepaths when using the #+INCLUDE derivative? Date: Fri, 2 Mar 2018 15:16:21 +0100 Message-ID: References: <87woyxhuk2.fsf@nicolasgoaziou.fr> <87o9k7ir3i.fsf@nicolasgoaziou.fr> <87h8pzifk7.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="94eb2c114ed0eb083805666e9e8a" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:36716) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1erlTz-0001kK-UN for emacs-orgmode@gnu.org; Fri, 02 Mar 2018 09:16:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1erlTy-0006H9-UO for emacs-orgmode@gnu.org; Fri, 02 Mar 2018 09:16:23 -0500 Received: from mail-qt0-x22f.google.com ([2607:f8b0:400d:c0d::22f]:37461) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1erlTy-0006GH-Md for emacs-orgmode@gnu.org; Fri, 02 Mar 2018 09:16:22 -0500 Received: by mail-qt0-x22f.google.com with SMTP id r16so12008631qtm.4 for ; Fri, 02 Mar 2018 06:16:22 -0800 (PST) In-Reply-To: <87h8pzifk7.fsf@nicolasgoaziou.fr> 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" To: Nicolas Goaziou Cc: emacs-orgmode@gnu.org --94eb2c114ed0eb083805666e9e8a Content-Type: text/plain; charset="UTF-8" I've adapted the code such that it handles both bracketed and unbracketed links, and links with descriptions. As it is now, the changes are always automatically applied. > Also, rewriting needs not be always absolute path, if both directories > share a common root. I couldn't find a simple way of rewriting links without making them absolute, as `org-export--prepare-file-contents` does not have access to the path of the including file, only of the included file. On Thu, Mar 1, 2018 at 11:42 PM, Nicolas Goaziou wrote: > Hello, > > Daniel P Gomez writes: > >> Currently when passing the :absolute-paths toggle to an include >> derivative, as in : >> >> #+INCLUDE: file.org :absolute-paths t >> >> The function `org-export--prepare-file-contents` will automatically >> deduce the directory from file.org and adapt links by calling: >> `(new-path (expand-file-name old-path (file-name-directory file)))`. >> I could either make this a default option, such that links get >> corrected but users can overwrite this by calling `:absolute-paths >> nil`, or I could completely remove this toggle and always correct >> links no matter what. > > I am wondering about the latter. If there is no reason to keep broken > file names, it makes sense to automatically apply it. > > Also, rewriting needs not be always absolute path, if both directories > share a common root. > >> One question regarding the implementation, currently I'm deleting the >> link with a call to `delete-region` and using `(insert "[[file:" >> new-path "]]")` to insert the corrected one. This does not take into >> consideration whether links are bracketed or not ( is there a >> functional difference if links are not bracketed?). > > Yes. White spaces are handled differently in each link type. > >> Also, my approach completely disregards link descriptions, which may >> be relevant if the linked file would be, for example, an html >> document. Would there be a cleaner org approach to replace the path >> keeping the description? > > You could check :contents-begin and :contents-end for the link. If they > are not nil, extract this region, and insert it again in the new link. > > Regards, > > -- > Nicolas Goaziou 0x80A93738 --94eb2c114ed0eb083805666e9e8a Content-Type: application/octet-stream; name="0001-Fix-file-links-when-using-INCLUDE.patch" Content-Disposition: attachment; filename="0001-Fix-file-links-when-using-INCLUDE.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_jea0mu3n0 RnJvbSBmZWNjZmU4MjllYTlmYTRmNDRjNDdkOGM4NDVlZDYwMmQyOTQ1ZGNkIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBEYW5pZWwgR29tZXogPGQuZ29tZXpAcG9zdGVvLm9yZz4KRGF0 ZTogRnJpLCAyIE1hciAyMDE4IDE0OjQ2OjQxICswMTAwClN1YmplY3Q6IFtQQVRDSCAxLzFdIEZp eCBmaWxlIGxpbmtzIHdoZW4gdXNpbmcgIytJTkNMVURFCgotLS0KIGxpc3Avb3guZWwgfCAyOCAr KysrKysrKysrKysrKysrKysrKysrKysrKysrCiAxIGZpbGUgY2hhbmdlZCwgMjggaW5zZXJ0aW9u cygrKQoKZGlmZiAtLWdpdCBhL2xpc3Avb3guZWwgYi9saXNwL294LmVsCmluZGV4IGJkNDlhOGEy Ni4uOGYwYWNhOTg5IDEwMDY0NAotLS0gYS9saXNwL294LmVsCisrKyBiL2xpc3Avb3guZWwKQEAg LTM0NzYsNiArMzQ3NiwzNCBAQCBPcHRpb25hbCBhcmd1bWVudCBGT09UTk9URVMgaXMgYSBoYXNo LXRhYmxlIHRvIHN0b3JlIGZvb3Rub3RlcyBpbgogdGhlIGluY2x1ZGVkIGRvY3VtZW50LiIKICAg KHdpdGgtdGVtcC1idWZmZXIKICAgICAoaW5zZXJ0LWZpbGUtY29udGVudHMgZmlsZSkKKyAgICAo Z290by1jaGFyIChwb2ludC1taW4pKQorICAgICh3aGlsZSAocmUtc2VhcmNoLWZvcndhcmQgb3Jn LWFueS1saW5rLXJlIG5pbCB0KQorICAgICAgKGxldCAoKGxpbmsgKHNhdmUtZXhjdXJzaW9uCisJ CSAgICAoYmFja3dhcmQtY2hhcikKKwkJICAgIChvcmctZWxlbWVudC1jb250ZXh0KSkpKQorCSh3 aGVuIChzdHJpbmc9IChvcmctZWxlbWVudC1wcm9wZXJ0eSA6dHlwZSBsaW5rKSAiZmlsZSIpCisJ ICAobGV0KiAoKGhhcy1icmFja2V0IChzdHJpbmc9CisJCQkgICAgICAgKG9yZy1lbGVtZW50LXBy b3BlcnR5IDpmb3JtYXQgbGluaykgImJyYWNrZXQiKSkKKwkJIChoYXMtY29udGVudCAob3JnLWVs ZW1lbnQtcHJvcGVydHkgOmNvbnRlbnRzLWJlZ2luIGxpbmspKQorCQkgKG9sZC1wYXRoIChvcmct ZWxlbWVudC1wcm9wZXJ0eSA6cGF0aCBsaW5rKSkKKwkJIChuZXctcGF0aCAoZXhwYW5kLWZpbGUt bmFtZSBvbGQtcGF0aAorCQkJCQkgICAgIChmaWxlLW5hbWUtZGlyZWN0b3J5IGZpbGUpKSkKKwkJ IChyYXctbmV3LWxpbmsKKwkJICAoY29uY2F0ICJmaWxlOiIgbmV3LXBhdGgpKQorCQkgKG5ldy1s aW5rCisJCSAgKGNvbmQKKwkJICAgKChhbmQgaGFzLWJyYWNrZXQgKG5vdCBoYXMtY29udGVudCkp CisJCSAgICAoY29uY2F0ICJbWyIgcmF3LW5ldy1saW5rICJdXSIpKQorCQkgICAoKGFuZCBoYXMt YnJhY2tldCBoYXMtY29udGVudCkKKwkJICAgIChsZXQgKChkZXNjcmlwdGlvbgorCQkJICAgKGJ1 ZmZlci1zdWJzdHJpbmcKKwkJCSAgICAob3JnLWVsZW1lbnQtcHJvcGVydHkgOmNvbnRlbnRzLWJl Z2luIGxpbmspCisJCQkgICAgKG9yZy1lbGVtZW50LXByb3BlcnR5IDpjb250ZW50cy1lbmQgbGlu aykpKSkKKwkJICAgICAgKGNvbmNhdCAiW1siIHJhdy1uZXctbGluayAiXVsiIGRlc2NyaXB0aW9u ICJdXSIpKSkKKwkJICAgKHQgcmF3LW5ldy1saW5rKSkpKQorCSAgICAoYXBwbHkgIydkZWxldGUt cmVnaW9uIChsaXN0IChvcmctZWxlbWVudC1wcm9wZXJ0eSA6YmVnaW4gbGluaykKKwkJCQkJIChv cmctZWxlbWVudC1wcm9wZXJ0eSA6ZW5kIGxpbmspKSkKKwkgICAgKGluc2VydCBuZXctbGluaykp KSkpCiAgICAgKHdoZW4gbGluZXMKICAgICAgIChsZXQqICgobGluZXMgKHNwbGl0LXN0cmluZyBs aW5lcyAiLSIpKQogCSAgICAgKGxiZWcgKHN0cmluZy10by1udW1iZXIgKGNhciBsaW5lcykpKQot LSAKMi4xNi4yCgo= --94eb2c114ed0eb083805666e9e8a--