emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed

From: "Dauer, Michael" <michael.dauer@smartpm.com>
To: emacs-orgmode@gnu.org
Subject: issues and limitations with macros and export process
Date: Wed, 25 Nov 2020 10:27:52 +0100	[thread overview]
Message-ID: <CAA3mUeb2FJ8HAx4JQqBn2vKE6vyAiBAhwXYYX0AvYLZv79SidA@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2465 bytes --]

Hi,

My use case:
I export various sub-branches with different exporters (html, latex,
ox-taskjuggler) via dispatcher and more via custom code.

The issues:
1. Include files about the current branch and on file level are not
considered.
2. Macros that are evaluated during expansion only see the sub-branch and
cannot access e.g. properties on file level or in parent nodes.
3. Interestingly static macros created on file level are
resolved correctly. Where/when are they collected?

Guessed root cause:
During the export process as a first step the sub-branch is copied into a
"temp" buffer, and all macro expansions happen there. In this buffer is no
information left from file level or parent nodes.

Possible solutions / work-arounds:
1. Solution:
a. First copy whole buffer in first temp buffer.
b. Insert include files in sub-branch, nodes above, and file level (at
least before the sub-branch). Include files can hold macro definitions too.
c. Expand macros in sub-branch. (wider scope needed if recursive macros are
expected to work)
d. Do further export processing of sub-branch maybe in a second temp buffer
2. Work-around A:
a. Save reference to original buffer before copying into temp buffer.
b. Do macro evaluation during expansion while temporarily switching back to
original buffer
This does not resolve the limitations of the include files.
3. Work-around B:
a. Have a means to know what the original buffer was.
b. Switch back to the original buffer explicitly in the code of the eval
macros.
This is a quite limited improvement, which also increases the minimal
complexity of eval macros.

The solution and work-around A would imply changes in the code base with
potential incompatibilities to existing custom code.

For work-around B I haven't found a way to temporarily switch to the
original buffer.
1. There is no hook for before the switch to the temp buffer, in which I
could save the reference to the original buffer.
2. The change-buffer-list hook is not reliable to save this reference
either.
3. Currently I'm trying to derive the original buffer from the name of the
temp buffer (removing the <2> suffix) but there seems to be a narrowing to
the sub-tree even in the original buffer at that point of time. If I just
widen then this would cause side effects on the narrowings done by the user
before, right?

Please comment on my thoughts. Tell me if I missed something relevant. And
direct me to a better solution if you know.

Thanks

[-- Attachment #2: Type: text/html, Size: 2917 bytes --]

                 reply	other threads:[~2020-11-25  9:28 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=CAA3mUeb2FJ8HAx4JQqBn2vKE6vyAiBAhwXYYX0AvYLZv79SidA@mail.gmail.com \
    --to=michael.dauer@smartpm.com \
    --cc=emacs-orgmode@gnu.org \
    /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

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).