I still don't see (and haven't thought about) pros and cons of making available the arguments as \foo{…}
or \foo\bgroup …\egroup
(or even unbalanced, \bgroup …}
and {…\egroup
). But I'm curious about enabling it for certain commands (in a way that, for instance, you could create environments from commands).
How can we create a macro like
\def\foo#1{…}
that does accept
\foo\bgroup …\egroup
Another option I thought about is a command like
\delimitedbybegroup{<pre code>}<argument delimited by braces or \bgroup and \egroup>
So one could say \delimitedbybegroup\emph{Some text}
or \delimitedbybegroup\emph\bgroup Some text\egroup
both of them giving \emph{Some text}
.
A more advanced one, for instance, might be
\delimitedbybegroup{\def\foo#1#2}\bgroup Something with #1 and #2\egroup
In any case any thoughts about why and why not are useful this kind of commands would be welcome.
And, in a similar way… how are (usually) handled commands that do look for a “closing” token, if the token is not visible. Like
\def\foo{\delimiter}
\def\baz#1\delimiter{…#1…}
\baz some code \foo{} and some more here that should be outside the argument of \string\baz.
Best Answer
The question gives me a sense if it is read from its end: give the possibility of creating a macro which expands its parameter during parameter scanning. Then the variants
}
or\egroup
as a delimiter of the parameter is serviceable.I've created the
\eparam
macro with this syntax:The
parameter-text
is equal toreal-parameter-text
enclosed by braces or by another control sequences declared by\eparamopen
and\eparamclose
.Example:
The main point of the
\eparam
is that it prepares an Expanded Parameter. Thereal-parameter-text
is expanded during parameter scanning like by\edef
. This means that all expandable primitives and macros are expanded during the parameter is read. Unexpandable primitives do nothing in this time (like\edef
) so you can do reassigmnent of registers/macros inside this parameter but without any effect for parameter scaninng. This is main difference between this case and the\hbox {...}
primitive syntax.There is one little difference between
\edef
and parameter scanning: undefined control sequences do nothing (like unexpandable primitives) during parameter scanning. The error can be occur only when the parameter is used (no during parameter scanning).The separator declared by
\eparamclose
can be hidden in a macro. Example:The first open brace or delimiter given by
\eparamopen
is optional. I.e. you can omit it:The parameter is always balanced by braces. This means that the delimiter declared by
\eparamclose
does no effect inside inner braces pair (like normal parameter scanning):The implementation (or wipet's sorcery :) and little tests follow.
Edit: I did do a small modification of the code in order to solve the last demand from the question:
acts like
\edef\foo#1#2{Something with #1 and #2}
.If you need to deactivate the expansion process (i.e. you need to do
\def
, no\edef
) then you can declareOf course, the delimiter declared by
\eparamclose
cannot be found in nested macro in such case.