order of evaluation upon export: macros are evaluated too soon

order of evaluation upon export: macros are evaluated too soon

[Eric S Fraga]

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

Hello all,

I have a document with this (ECM) structure:

#+begin_src org
  ,#+macro: item I{{{n(i)}}}@@latex:}%@@
  ,#+options: toc:nil num:nil

  ,* {{{item()}}} Some topic
  ,* {{{item()}}} Another topic                                  :noexport:
  ,* {{{item()}}} A final one
#+end_src

I would like the exported headings to be numbered Q1, Q2, ... but only
the exported ones.  At the moment, the item macro is expanded on every
occurrence in the file, regardless of export settings.  So, if I export
to ASCII, I get:

: I1 Some topic
: =============
: 
: 
: I3 A final one
: ==============

whereas I want I2 for the second heading.  Example of use case: agenda
of meeting where certain commonly appearing entries may be excluded;
bank of questions for tutorials etc. with sub-selection; all kinds of
enumerations with different tag selections; ...

I used to do this with LaTeX counters but I thought I would use the new
counter capability in org.  Unfortunately, it doesn't do the job for me.

Any suggestions please?

thanks,
eric

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 26.0.50, Org release_9.0.7-531-g530113

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: order of evaluation upon export: macros are evaluated too soon

[Charles C. Berry]

On Wed, 7 Jun 2017, Eric S Fraga wrote:

> Hello all,
>
> I have a document with this (ECM) structure:
>
> #+begin_src org
>  ,#+macro: item I{{{n(i)}}}@@latex:}%@@
>  ,#+options: toc:nil num:nil
>
>  ,* {{{item()}}} Some topic
>  ,* {{{item()}}} Another topic                                  :noexport:
>  ,* {{{item()}}} A final one
> #+end_src
>
> I would like the exported headings to be numbered Q1, Q2, ... but only
> the exported ones.


Maybe implement somethng like this:


#+BEGIN_SRC emacs-lisp
   (defun n-noexport (x y)
     (let ((tags (nth 5 (org-heading-components))))
       (unless (and tags
 		   (string-match ":noexport:" tags))
 	(org-macro--counter-increment x y))))
#+END_SRC

#+MACRO: n2 (eval (n-noexport "$1" "$2"))


* heading 1

{{{n2()}}}


* heading 2                                                :noexport:notever:

{{{n2()}}}

* heading 3
{{{n2()}}}


HTH,

Chuck

Re: order of evaluation upon export: macros are evaluated too soon

[Nicolas Goaziou]

Hello,

"Charles C. Berry" <ccberry@ucsd.edu> writes:

> Maybe implement somethng like this:
>
> #+BEGIN_SRC emacs-lisp
>    (defun n-noexport (x y)
>      (let ((tags (nth 5 (org-heading-components))))
>        (unless (and tags
>  		   (string-match ":noexport:" tags))
>  	(org-macro--counter-increment x y))))
> #+END_SRC
>
> #+MACRO: n2 (eval (n-noexport "$1" "$2"))
>
> * heading 1
>
> {{{n2()}}}
>
>
> * heading 2                                                :noexport:notever:
>
> {{{n2()}}}
>
> * heading 3
> {{{n2()}}}
>

What about simply removing macros in :noexport: trees from
a pre-processing-hook?

Regards,

-- 
Nicolas Goaziou

Re: order of evaluation upon export: macros are evaluated too soon

[Eric S Fraga]

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

On Wednesday,  7 Jun 2017 at 18:43, Charles C. Berry wrote:

[...]

> Maybe implement somethng like this:
>
> #+BEGIN_SRC emacs-lisp
>    (defun n-noexport (x y)
>      (let ((tags (nth 5 (org-heading-components))))
>        (unless (and tags
>  		   (string-match ":noexport:" tags))
>  	(org-macro--counter-increment x y))))
> #+END_SRC
>
> #+MACRO: n2 (eval (n-noexport "$1" "$2"))

This is really straightforward and solves my problem perfectly.  Thank
you!

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 26.0.50, Org release_9.0.7-531-g530113

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: order of evaluation upon export: macros are evaluated too soon

[Eric S Fraga]

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

On Wednesday,  7 Jun 2017 at 19:56, Nicolas Goaziou wrote:

[...]

> What about simply removing macros in :noexport: trees from
> a pre-processing-hook?

Hi Nicolas,

Thanks for the suggestion.  It makes sense but the problem (for me) is
the "simply" in the above. ;-)

But Charles's solution works perfectly so I'm happy!

I do wonder, philosophically, about the use cases for macro expansion
and the resulting implementation.  My understanding is that macros are
only for export so should they not pay attention to export exclusion
directives?

Thanks again,
eric

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 26.0.50, Org release_9.0.7-531-g530113

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: order of evaluation upon export: macros are evaluated too soon

[Nicolas Goaziou]

Hello,

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> I do wonder, philosophically, about the use cases for macro expansion
> and the resulting implementation.  My understanding is that macros are
> only for export so should they not pay attention to export exclusion
> directives?

Macros are expanded prior to Babel code evaluation—they can make nice
shortcuts for long Babel calls—so they have to obey to the same rules as
Babel code evaluation, which ignores ":noexport:" directive. I do
realize that macros, however, are expanded within commented trees; this
is a mistake I am going to fix.

Of course, if we accept to limit more macro expansion scope, we get more
latitude in choosing the position of the expansion stage during the
export process. I'm open to discussions about it, and more generally,
about macros' features.

Regards,

-- 
Nicolas Goaziou

Re: order of evaluation upon export: macros are evaluated too soon

[Eric S Fraga]

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


(Nicolas, forgot to send this to the list so apologies if you get this
twice)


On Thursday,  8 Jun 2017 at 12:36, Nicolas Goaziou wrote:
> Macros are expanded prior to Babel code evaluation—they can make nice
> shortcuts for long Babel calls—so they have to obey to the same rules as
> Babel code evaluation, which ignores ":noexport:" directive. I do

Ah, okay, this is a reasonable use case for ignoring the noexport
directive.  Thanks for this.

> Of course, if we accept to limit more macro expansion scope, we get more
> latitude in choosing the position of the expansion stage during the
> export process. I'm open to discussions about it, and more generally,
> about macros' features.

Consistency is the most important feature, in many ways, especially as
the (eco-)system grows.  For my own use case, the little bit of elisp
posted earlier is sufficient for me so I'm happy with the current
configuration, especially as I like hiding babel blocks in non-exported
subtrees but still want them executed on export.

Thanks again,
eric

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 26.0.50, Org release_9.0.6-425-gf4fca1

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 194 bytes --]