Have export treat file: paths in INCLUDED file relative to the INCLUDING file's dir
Hello, I have a file s.org in ./ (current directory), which includes another file s0.org living under ./media/s/: ./s.org: #+TITLE: s #+INCLUDE: "./media/s/s0.org" ./media/s/s0.org: * s0 ** s01 file:media/s01_image.png I want the org export to html to treat the file: paths in ./media/s/s0.org with respect to the directory of the ./s.org file. In other words, I want export NOT TO TOUCH the file: paths as written included files and effectively just paste the text of s0.org verbatim in s.org (basically similar to what #include directive in C preprocessor would do, e.g.). As of now, the above s.org exports to s.html which has the file: link converted to file:///home/user/media/s/media/s01_image.png I want that link to instead become file:///home/user/media/s01_image.png which used to be the default behavior in a previous version of Org mode (I don't recall which one). Is there a flag that could be passed to #+INCLUDE: to change the 'relativeness' of the link treatment when it comes to #+INCLUDE: directives? I see in ox.el, (defun org-export-expand-include-keyword (&optional included dir footnotes) "Expand every include keyword in buffer. Optional argument INCLUDED is a list of included file names along with their line restriction, when appropriate. It is used to avoid infinite recursion. Optional argument DIR is the current working directory. It is used to properly resolve relative paths. Optional argument FOOTNOTES is a hash-table used for storing and resolving footnotes. It is created automatically." Is this DIR what's needed (to be given to #+INCLUDE: with a flag) to change the link translation behavior? Org mode version 9.4.4 (release_9.4.4) GNU Emacs 27.2 Thanks, Omid
Re: [FR] Allow to #+include files verbatim without any processing (was: Have export treat file: paths in INCLUDED file relative to the INCLUDING file's dir)
Hi Timothy, Thanks for your reply. "Timothy" writes: > Hi Ihor, > >> This sounds like a reasonable request. >> What we may do here is allowing a new parameter :verbatim > > From a read of the original email, it sounds like a `:dir' > parameter could also > solve this use case, and allow for a bit more flexibility. > Is `:dir' a parameter to pass to `#+INCLUDE:'? I don't see it in the manual: https://orgmode.org/manual/Include-Files.html > All the best, > Timothy Regards, Omid
Re: Have export treat file: paths in INCLUDED file relative to the INCLUDING file's dir
Hi Max, Thanks for your reply. "Max Nikulin" writes: > On 26/02/2023 08:52, gnu...@pm.me wrote: >> (basically similar to what #include >> directive in C preprocessor would do, e.g.). As of now, the >> above >> s.org exports to s.html which has the file: link converted to >> >> file:///home/user/media/s/media/s01_image.png > > Doesn't cpp behave in a similar way? > > grep --include=*.h -r '' h-0.h include-1/ > h-0.h: > h-0.h:#include "include-1/h-1.h" > h-0.h: > h-0.h:extern int h0; > include-1/h-1.h: > include-1/h-1.h:#include "include-2/h-2.h" > include-1/h-1.h: > include-1/h-1.h:extern int h1; > include-1/include-2/h-2.h: > include-1/include-2/h-2.h:extern int h2; > You have two #include directives in your example, which are processed recursively according to the preprocessor rules. What I had in mind was one #include preprocessor directive (similar to one #+INCLUDE: 'directive' in Org) and a non-preprocessor directive (`file:' in Org). > cpp -nostdinc h-0.h > # 1 "h-0.h" > # 1 "" > # 1 "" > # 1 "h-0.h" > > # 1 "include-1/h-1.h" 1 > > # 1 "include-1/include-2/h-2.h" 1 > > extern int h2; > # 3 "include-1/h-1.h" 2 > > extern int h1; > # 3 "h-0.h" 2 > > extern int h0; > > > So in a file residing in ./include-1/ reference to > "include-2/h-2.h" > means ./include-1/include-2/h-2.h, not ./include-2/h-2.h Regards, Omid
Re: [FR] Allow to #+include files verbatim without any processing (was: Have export treat file: paths in INCLUDED file relative to the INCLUDING file's dir)
Hi, I was wondering if anyone had any new ideas on this question (or an explanation on what Timothy meant by a :dir parameter). Right now I'm having to use a search and replace back on the whole generated html buffer, which is fragile and inefficient. Thanks, Omid Original Message On Feb 28, 2023, 1:34 PM, wrote: > Hi Timothy, Thanks for your reply. "Timothy" writes: > Hi Ihor, > >> This > sounds like a reasonable request. >> What we may do here is allowing a new > parameter :verbatim > > From a read of the original email, it sounds like a > `:dir' > parameter could also > solve this use case, and allow for a bit more > flexibility. > Is `:dir' a parameter to pass to `#+INCLUDE:'? I don't see it > in the manual: https://orgmode.org/manual/Include-Files.html > All the best, > > Timothy Regards, Omid
Re: [FR] Allow to #+include files verbatim without any processing (was: Have export treat file: paths in INCLUDED file relative to the INCLUDING file's dir)
Hi Ihor, Thanks for your reply and clarification on what Timothy meant. 1. Is there a general workaround that could be used as of now? 2. Is there something I can do to help with a :dir or similar option's development? I have some (very) basic knowledge of lisp. 3. If it helps, this behavior has changed since (at least) Org 9.1.9-65-g5e4542, which is the default distributed with GNU Emacs 26.3. With that Org, export to html took the links in the #+INCLUDE'd .org files as being relative to the includer's dir (i.e., the PARENT .org file's dir), which I consider 'verbatim' inclusion. -Omid "Ihor Radchenko" writes: > gnu...@pm.me writes: > >> I was wondering if anyone had any new ideas on this question (or an >> explanation on what Timothy meant by a :dir parameter). > > Timothy meant that we can introduce a new #+INCLUDE option :dir that > will define custom path used to resolve relative paths inside links in > the included file.
Re: [FR] Allow to #+include files verbatim without any processing (was: Have export treat file: paths in INCLUDED file relative to the INCLUDING file's dir)
Thank you for your detailed reply, Ihor. "Ihor Radchenko" writes: > gnu...@pm.me writes: > >> Hi Ihor, >> Thanks for your reply and clarification on what Timothy meant. >> >> 1. Is there a general workaround that could be used as of now? > > Nothing great. You may have to use a custom macro, but you will then > miss auto adjustment of heading levels and other #+INCLUDE features. > > A bit more dramatic would be advising `org-export--update-included-link' > with :around advice #'ignore. That will skip link updates completely. > >> 2. Is there something I can do to help with a :dir or similar >> option's development? I have some (very) basic knowledge of lisp. > > You can look into `org-export--prepare-file-contents' that is doing all > the processing of the included files. It will have to be modified to > take the new options. The options are parsed by > `org-export-expand-include-keyword'. > > If you have experience with other programming languages, things should > not be too hard - just follow the existing code. > So, looking in ox.el (from Org 9.4.4 coming in GNU Emacs 27.2), it appears that there is an optional INCLUDER arg that is supposed to do what I'm looking for, except that there seems to be a bug somewhere: Try the following: CORRECT includer.org: #+INCLUDE: "./a/included.org" :includer . a/included.org: [[./a/img.png]] org-html-export-to-html results in the expected output in includer.html: Notice there is only ONE a/ in the img src path. Without :includer arg we would get Notice there are TWO a/ (a/a/) in the img src path. -- WRONG But if we just add a * section/heading to a/includer.org, e.g., a/includer.org: * some [[./a/img.png]] Now, org-html-export-to-html spits #+BEGINincluder ... #+ENDincluder Why are these #+BEGIN_includer #+END_includer delimiters are being produced? --- >> 3. If it helps, this behavior has changed since (at least) Org >> 9.1.9-65-g5e4542, which is the default distributed with GNU Emacs >> 26.3. With that Org, export to html took the links in the >> #+INCLUDE'd .org files as being relative to the includer's dir >> (i.e., the PARENT .org file's dir), which I consider 'verbatim' >> inclusion. > > This behaviour is not documented and not defined. > The relative file link resolution was requested in > https://lists.gnu.org/r/emacs-orgmode/2019-02/msg00103.html and then > implemented in 931b7b8faf9. > > Note that #+INCLUDE generally assumes regular Org files and the new > behaviour you stumbled upon makes more sense as the default. > > Unfortunately, this change has not been announced in ORG-NEWS.
