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: Sat, 3 Mar 2018 14:06:05 +0100 Message-ID: References: <87woyxhuk2.fsf@nicolasgoaziou.fr> <87o9k7ir3i.fsf@nicolasgoaziou.fr> <87h8pzifk7.fsf@nicolasgoaziou.fr> <878tbahrxv.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:43200) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1es6rY-00011z-Ct for emacs-orgmode@gnu.org; Sat, 03 Mar 2018 08:06:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1es6rX-0005uH-8d for emacs-orgmode@gnu.org; Sat, 03 Mar 2018 08:06:08 -0500 Received: from mail-qk0-x22a.google.com ([2607:f8b0:400d:c09::22a]:42397) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1es6rX-0005so-3b for emacs-orgmode@gnu.org; Sat, 03 Mar 2018 08:06:07 -0500 Received: by mail-qk0-x22a.google.com with SMTP id b130so15327921qkg.9 for ; Sat, 03 Mar 2018 05:06:06 -0800 (PST) In-Reply-To: <878tbahrxv.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 Hi, > `org-export--prepare-file-contents' is called from the including > document, so you can get its path with (buffer-file-name > (buffer-base-buffer)). > > However, we need to handle the case where the including buffer is not > associated to a file, i.e., the Sexp above returns nil. > I noticed that (buffer-file-name (buffer-base-buffer)) will always return nil because `org-export--prepare-file-contents` is called in `org-export-include-keyword` after a call to `with-temp-buffer`. Two possible solutions to this issue would be either 1. passing the includer-file as an extra parameter to `org-export--prepare-file-contents` and then using `file-relative-name` to generate a relative path, or alternatively 2 . passing the matched string that points to the file to be included. Example: #+INCLUDE: "directory/file.org" Here, if file.org contains a link [[other/image.png]], then all one has to do is append the (file-name-directory matched) to the old-path. In this example this would result in directory/other/image.png. This second solution does not require a call to (buffer-file-name (buffer-base-buffer)), but seems hackish in the sense that we would pass 2 redundant arguments to `org-export-prepare-file-contents`: both the expanded and the non-expanded include-file filename. Perhaps I'm missing a simpler 3rd solution? > It would be nice to add a comment explaining what we are going to do. > Of course. ;; Adapt all file links within the included document that ;; contain relative paths in order to make these paths ;; relative to the base document, or absolute > I suggest the following inner part: > > (when (string= "file" (org-element-property :type link)) > (let* ((old-path (org-element-property :path link)) > (new-path (expand-file-name old-path (file-name-directory file)))) I noticed that the call to delete here will break `org-element-adopt-elements` later on since the real buffer positions will be changed and we are still querying for old, invalid positions stored in link. > ;; (delete-region (org-element-property :begin link) > ;; (org-element-property :end link)) > (insert (let ((new (org-element-copy link))) If we opt for solution 1 then new-path could be made relative here > ;; (org-element-put-property new :path new-path) (org-element-put-property new :path (if includer-file (file-relative-name new-path (file-name-directory includer-file)) new-path)) > (when (org-element-property :contents-begin link) > (org-element-adopt-elements new > (buffer-substring (org-element-property :contents-begin link) > (org-element-property :contents-end link)))) Deleting immediately before the insertion works. (delete-region (org-element-property :begin link) (org-element-property :end link)) > (org-element-interpret-data new))))) > > Also, would you mind adding a test in "text-ox.el", within > `test-org-export/expand-include'? I will attempt to write them once the implementation is completed. Thanks for the support. Regards, Daniel > Regards, > > -- > Nicolas Goaziou