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

[Daniel P. Gomez]

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

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