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

[Nicolas Goaziou]

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,

-- 
Nicolas Goaziou                                                0x80A93738