From: gnuric@pm.me
To: Ihor Radchenko <yantar92@posteo.net>
Cc: gnuric@pm.me, orgmode@tec.tecosaur.net, emacs-orgmode@gnu.org
Subject: 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)
Date: Tue, 04 Apr 2023 08:07:00 +0000 [thread overview]
Message-ID: <875yacrrz5.fsf@pm.me> (raw)
In-Reply-To: <87cz4lb9ya.fsf@localhost>
Thank you for your detailed reply, Ihor.
"Ihor Radchenko" <yantar92@posteo.net> writes:
> gnuric@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:
<img src="./a/img.png" alt="img.png" />
Notice there is only ONE a/ in the img src path. Without :includer arg
we would get
<img src="./a/a/img.png" alt="img.png" />
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
#+BEGIN<sub>includer</sub>
...
<img src="./a/img.png" alt="img.png" />
#+END<sub>includer</sub>
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.
next prev parent reply other threads:[~2023-04-04 8:08 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-26 1:52 Have export treat file: paths in INCLUDED file relative to the INCLUDING file's dir gnuric
2023-02-28 10:34 ` [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) Ihor Radchenko
2023-02-28 15:12 ` Timothy
2023-02-28 21:34 ` gnuric
2023-03-30 18:17 ` gnuric
2023-04-02 10:24 ` Ihor Radchenko
2023-04-02 21:32 ` gnuric
2023-04-03 9:18 ` Ihor Radchenko
2023-04-04 1:04 ` Samuel Wales
2023-04-04 8:57 ` Ihor Radchenko
2023-04-05 0:16 ` Samuel Wales
2023-04-04 8:07 ` gnuric [this message]
2023-04-04 8:26 ` Ihor Radchenko
2023-03-01 9:58 ` Ihor Radchenko
2023-02-28 15:03 ` Have export treat file: paths in INCLUDED file relative to the INCLUDING file's dir Max Nikulin
2023-02-28 21:42 ` gnuric
2023-03-02 12:14 ` Max Nikulin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=875yacrrz5.fsf@pm.me \
--to=gnuric@pm.me \
--cc=emacs-orgmode@gnu.org \
--cc=orgmode@tec.tecosaur.net \
--cc=yantar92@posteo.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).