Org-mode mailing list
 help / color / mirror / Atom feed
* issues and limitations with macros and export process
@ 2020-11-25  9:27 Dauer, Michael
  0 siblings, 0 replies; only message in thread
From: Dauer, Michael @ 2020-11-25  9:27 UTC (permalink / raw)
  To: emacs-orgmode

[-- 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 --]

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2020-11-25  9:28 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-25  9:27 issues and limitations with macros and export process Dauer, Michael

Org-mode mailing list

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://orgmode.org/list/0 list/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 list list/ https://orgmode.org/list \
		emacs-orgmode@gnu.org
	public-inbox-index list

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.emacs.orgmode
	nntp://news.gmane.io/gmane.emacs.orgmode


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git