emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

issues and limitations with macros and export process


From: Dauer, Michael
Subject: issues and limitations with macros and export process
Date: Wed, 25 Nov 2020 10:27:52 +0100

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]