From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id ML3aLcsjvl8FRgAA0tVLHw (envelope-from ) for ; Wed, 25 Nov 2020 09:28:43 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id eGTqKcsjvl8jPAAAB5/wlQ (envelope-from ) for ; Wed, 25 Nov 2020 09:28:43 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 1BEB39403E8 for ; Wed, 25 Nov 2020 09:28:43 +0000 (UTC) Received: from localhost ([::1]:52264 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1khr6P-0001LV-Rr for larch@yhetil.org; Wed, 25 Nov 2020 04:28:41 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:59326) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1khr5s-0001KL-G0 for emacs-orgmode@gnu.org; Wed, 25 Nov 2020 04:28:08 -0500 Received: from mail-lf1-x131.google.com ([2a00:1450:4864:20::131]:40102) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1khr5q-0005EV-73 for emacs-orgmode@gnu.org; Wed, 25 Nov 2020 04:28:08 -0500 Received: by mail-lf1-x131.google.com with SMTP id u19so2152708lfr.7 for ; Wed, 25 Nov 2020 01:28:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smartpm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=2CKg1/XtBopvQNIVLFMPxMo5biEk8kK19crkg06vGDk=; b=DBtRRs/AHomVkG54o5TtfyjvtHqkhz8/SD/BVgo9M/U1d37AFBqaVm6CxOHQlYUjJV aegXbFGLjuAqF3aESYgudBQEV97gT1TsPv+gy4oGf9QugjE6QFRiuuGyyTTVJb3+nD4u m5hXT1ICY0o/3D6VcIrm6gDtynAts+faaO77lBnfv79jigQ6KuGJyCoUQxHy2+biJKMZ xXa1OfiVoxbvHJ/WuDIazOCDoI+S7WSv7LD+Met4RuzPet54vAvQHGHuIKkLbkRsHwNB 8l4/lIRxPmXqMlsMOTtAPN2Srf6vsm2xuSoix00pGeoGrt4upk1Up7uY4KlfO8OVO2Qr /ADQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=2CKg1/XtBopvQNIVLFMPxMo5biEk8kK19crkg06vGDk=; b=RuvDXsQJCAWzCfkzuBtcs1EHCM6CJnY/VYJG4m4S76OsxGU3BfYXA7iQwGDPEodeDW DHBInz1pNG6XUlTCgFsm/9HPlOYyhp4IjbqBUqCfsAuSywniScCjawLecSB59xu1yirR KIy+/jk5simtYXiOWUdxXe/e9WMIeugCBI6kxaJz1VJE3v6gNAPBtOnV0DVr0ba5+hU/ BL51FSyoHJIXXmb/MVL3UzpJvQ6eML+N1U2hUo1Gj+2Tps5Ozj950E5NPxZHaCFsGl7F 84pmfCae+EgoO50+yhtA9zvVOmMkuhlTD/aHREUVILPmNBH5EuGa5HYuooqAXjbFDtX0 TyAg== X-Gm-Message-State: AOAM5305N4E7a8L1xkNCYd6Do5UcidJKF7XKPSNNkTfZ6Fmj++EBwj6R GUmhq2/OWsBnHDBO/tK6e8L3q1HgI+BqmPLYVEr+JVEbjBI= X-Google-Smtp-Source: ABdhPJwGH2m3kVvc9wU5GqnmBlkMmczTYVFb44wDozqp564XN1DRu+zax6szO05jwnSUW8MbE4+WuIZMvwUzj+Z76KY= X-Received: by 2002:a19:8292:: with SMTP id e140mr971567lfd.110.1606296483281; Wed, 25 Nov 2020 01:28:03 -0800 (PST) MIME-Version: 1.0 From: "Dauer, Michael" Date: Wed, 25 Nov 2020 10:27:52 +0100 Message-ID: Subject: issues and limitations with macros and export process To: emacs-orgmode@gnu.org Content-Type: multipart/alternative; boundary="0000000000004a513b05b4eb0bf9" Received-SPF: pass client-ip=2a00:1450:4864:20::131; envelope-from=michael.dauer@smartpm.com; helo=mail-lf1-x131.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=smartpm-com.20150623.gappssmtp.com header.s=20150623 header.b=DBtRRs/A; dmarc=none; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Spam-Score: -1.21 X-TUID: W6lrWaar0QAl --0000000000004a513b05b4eb0bf9 Content-Type: text/plain; charset="UTF-8" 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 --0000000000004a513b05b4eb0bf9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

My use case:
I export var= ious sub-branches with different exporters (html, latex, ox-taskjuggler) vi= a 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 onl= y see the sub-branch and cannot access e.g. properties on file level or in = parent nodes.
3. Interestingly static macros created on file leve= l are resolved=C2=A0correctly. Where/when are they collected?
Guessed root cause:
During the export process as a fi= rst step the sub-branch is copied into a "temp" buffer, and all m= acro expansions happen=C2=A0there. In this buffer is no information left fr= om 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, nod= es above, and file level (at least before the sub-branch). Include files ca= n hold macro definitions too.
c. Expand macros in sub-branch. (wi= der 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 befor= e copying into temp buffer.
b. Do macro evaluation during expansi= on 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=C2=A0improvement, which also incr= eases the minimal complexity of eval macros.

The s= olution and work-around A would imply changes in the code base with potenti= al incompatibilities to existing custom code.

For = work-around B I haven't found a way to temporarily switch to the origin= al 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 ei= ther.
3. Currently=C2=A0I'm trying to derive the original buf= fer from the name of the temp buffer (removing the <2> suffix) but th= ere 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 t= he narrowings done by the user before, right?

Plea= se comment on my thoughts. Tell me if I missed something relevant. And dire= ct me to a better solution if you know.

Thanks
--0000000000004a513b05b4eb0bf9--