(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