Nicolas Goaziou writes:

> Hello,
>
> Daniel P Gomez <gomez.danp@gmail.com> 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