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. > 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. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
