Simple macro syntax

[lcnbr]

Jumping off what was said here, it seems that the bare {foo} attribute syntax could be a simple way for an in markdown macro definition! Just like reference links the foo would just be a label for whatever was defined in the label definition

{foo}: bar

One could even imagine going further and having label functions ie macros, used like {foo(arg1,arg2)}

And then defined as

{foo(arg1,arg2)}: do something with (arg1) and (arg2)

The only thing is that this would be very useful in the math context but of course clashes with latex syntax..

[lcnbr]

Thinking about it more, it seems I want latex macro-like functionality, but with a semantic focus more than a typographical one. The macro expansion could be handled by any sort of filter, but having a predefined syntax in the spec means anyone writing such a filter would have a simple node in the AST, that is well defined, and standardized, with basic functionality like text replacement covered by the base syntax. I feel like this gives the end user incredible flexibility, which is hard to achieve in any markdown flavor. Additionally, it opens the space up to text-based syntax, that crucially is user-defined, and thus not English first.

[jgm]

If you look at my motivating article "Beyond Markdown," you'll see that I envision this kind of extension through four basic constructions that are already in djot:

• verbatim spans with attributes
• verbatim blocks with attributes
• formatted spans with attributes
• formatted blocks with attributes

With these four things and filters, you have quite a lot of flexibility without any additional syntax.

[bpj]

@lcnhb What do you want which you can't get with possibly nested spans and divs and filters?
I agree that it would be nice if there were list-like containers so that

[foo][bar][baz]{.quux}

were treated as equivalent to

[[foo]{}[bar]{}[baz]{}]{.quux}

but it is indistinguishable from a reference link followed by a span, so perhaps some separator character like

[foo]+[bar]+[baz]{.quux}

which could be extended to divs too:

{.quux}
:::
foo
+:::
bar
+:::
baz
:::

An actual macro functionality where you can define macros in-text leads to clutter and a lot of (for humans) confusion between what is definitions and what is content, and since I use Pandoc/Markdown in preference to LaTeX to get away from not seeing the text for all the markup I advice strongly against such.

What I do use is my own string templating (pre)processor (which I will put online as soon as I have got some decent documentation written) which takes a hint from lightweight markup languages in preferring punctuation to keywords and is vaguely similar to Bash parameter expansion, e.g.:

• $(foo) or $foo

  Inserts the value of variable foo.

• $<foo bar> $<bæz>

  Inserts variable values but variable names are not limited to ASCII alphanumerics, underscores and hyphens.

• $(foo?|bar) or $(foo ?| (bar) )

  Inserts the value of variable foo or if it is empty the string "bar".

• $(foo??bar) or $( foo ?? (bar) )

  Inserts the string "bar" if the variable foo is non-empty.

• $(foo?!bar) or $( foo ?! (bar) )

  Inserts the string "bar" if the variable foo is empty.

• $( foo ?? $bar ?! (no $game) )

  Inserts the value of variable bar if variable foo is non-empty, or the string "no X", where X is the value of the variable game, if foo is empty.

• $:foo( $bar, (my $game), 42, (ba@<331>) )

  Inserts the return value of calling the function foo with four arguments, where @<331> aka @<0x14b> is replaced with the Unicode character "ŋ" LATIN SMALL LETTER ENG.

Now the difference between the template processor and a macro processor is of course that with the former variables and functions are defined outside the template file by a script which imports the template engine class and passes the functions to the constructor as a data structure of function references written in the same language as the template engine. Variables are passed as a data structure of strings/numbers/booleans to the template expansion method and/or the constructor. Templates can be passed to the expansion method either as strings or as pre-parsed objects, allowing the calling program to parse a template once and fill it in several times with different data sets.

The templating engine is separate from Pandoc; it can be used for any text to be further processed with any program, but since it is written in pure MoonScript/Lua it can also be used from inside a Pandoc filter, typically defining templates as verbatim spans or blocks, either in the body or the metadata, which after expansion are passed to the Pandoc Lua API's read function to be converted to AST fragments which are then inserted into the document body. It is still separate from the markup language as parsed by Pandoc; it can be used within Markdown or djot input, and might make sense with other input formats too.
There is a "light" implementation with a subset of the functionality roughly equivalent to what I showed above which is small enough to inline into a Pandoc filter.