emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] How to keep correct filepaths when using the #+INCLUDE derivativ


From: Daniel P. Gomez
Subject: Re: [O] How to keep correct filepaths when using the #+INCLUDE derivative?
Date: Sat, 10 Mar 2018 12:28:39 +0100
User-agent: mu4e 1.1.0; emacs 25.3.1


I've fixed the implementation of `org-export--prepare-file-contents` so
that links are relative to the included file. A patch is attached.

I've also created two org files in the test examples directory:
"includer-with-links.org" and "subdir/includee-with-links.org". My goal was to add a test in "test-ox.el" `test-org-export/expand-include` that checks whether, after exporting the "includer-with-links.org" file to
Org, the headings *Source and *Target are the same.

I did not figure out how to do this cleanly, so any help implementing
the test itself would be greatly appreciated.

Regards,

Daniel

Attachment: 0001-Fix-file-links-when-using-INCLUDE.patch
Description: Text Data




Nicolas Goaziou writes:

Hello,

Daniel P Gomez <address@hidden> writes:

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?

I think solution 1 is fine.

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))

Indeed. However, the (if includer-file ...) should be integrated in
new-path binding, IMO.

I will attempt to write them once the implementation is completed.

Great. Thank you!

Regards,


--
Daniel P. Gomez

reply via email to

[Prev in Thread] Current Thread [Next in Thread]