From: Samuel Wales <samologist@gmail.com>
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: Mon, 3 Apr 2023 18:04:51 -0700 [thread overview]
Message-ID: <CAJcAo8tzXpVfjs5fFQKKif58tJs0uwKPGoLc9SwiQFdmN_kFJA@mail.gmail.com> (raw)
In-Reply-To: <87cz4lb9ya.fsf@localhost>
off topic, but is it possible to leverage such a default into being
able to include a paragraph [or a section] from the current file?
istr this required specifying both dir [fixed with this default] and
the file basename.
here are some of the things i tried.
bad syntax no doubt.
# #+include: [[id:d3df9f9f-946d-44b6-9b58-b3a69e069458][About]] :only-contents t
# #+include: "#about" :only-contents t
# #+include: "*about" :only-contents t
# #+include: [*about] :only-contents t
On 4/3/23, Ihor Radchenko <yantar92@posteo.net> wrote:
> 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.
>
>> 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>
>
>
--
The Kafka Pandemic
A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com
next prev parent reply other threads:[~2023-04-04 1:06 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 [this message]
2023-04-04 8:57 ` Ihor Radchenko
2023-04-05 0:16 ` Samuel Wales
2023-04-04 8:07 ` gnuric
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJcAo8tzXpVfjs5fFQKKif58tJs0uwKPGoLc9SwiQFdmN_kFJA@mail.gmail.com \
--to=samologist@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=gnuric@pm.me \
--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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.