5

It dawned on me that the title in beamer, which is provided for in curly braces, is optional! Help me to understand this. Normally, optional arguments are supplied in square brackets. As I show on slide 1 of my MWE, optional arguments can be finicky and will screw up if the optional argument itself contains optional [] data. (Note that, in the MWE, \xyz is a macro that ignores its optional argument and just outputs the mandatory argument.)

The beamer frame title suffers none of these problems, and can process an argument that contains [] options.

And yet, when an embraced frame title is omitted, as in slide 2 of my MWE, the following first letter of frame text is not taken as the 1-letter title. So frame is able to differentiate between an embraced {title} and generic slide text. In essence, the braces on the title are serving as the optional argument delimiters.

On slide 3 of my MWE, I give the \meaning of \frame, which might help unravel the mystery of how beamer can use a curly-braced item as an optional argument.

Am I missing something simple? Please help me to understand how this works.

\documentclass{beamer}
\usepackage[T1]{fontenc}
\newcommand\xyz[2][]{#2}
\begin{document}
\begin{frame}{title is in braces, but optional! \xyz[\xyz{DOES~NOT}]{WORKS}}
Here is text after title.

Optional arguments can be tricky.  For example,

take \textbackslash xyz macro:

.\xyz{WORKS with no optional argument}.

.\xyz[\xyz{DOES~NOT}]{WORKS with optional argument}.

.\xyz[\xyz[ignoreme]{DOES~NOT}]{WORK when optional argument has []}.

\bigskip
The problem is an optional argument within an optional argument.  
But that problem did not apply to the title (where an optional argument 
was processed).
\end{frame}

\begin{frame}
Here is text after no title is specified.  

Note that the ``H'' was not taken as a title, 
implying that the title, within braces, is optional.

\bigskip
\textbf{How does this work?!}

The title is an optional argument in curly braces,
not square brackets.  It can process optional arguments within the title.

\end{frame}

\begin{frame}
Help me to understand this, if this is where the magic is:

\bigskip
\meaning\frame
\end{frame}

\end{document}

enter image description here


enter image description here


enter image description here

  • This is not an answer to your question, but did you try \xyz[{\xyz[Some content]{DOES~NOT}}]{WORKS}? The inner [] pair must be 'protected' – user31729 Dec 31 '14 at 5:10
  • @ChristianHupfer I haven't tried that, but the point stands that a "normal" optional argument needs special care to avoid stupid stuff like brackets within brackets, for which the title of frame is immune, because it doesn't use bracket delimiters. And the real question isn't how to protect optional arguments (though that's good to know), but how beamer accomplishes an optional argument in braces. – Steven B. Segletes Dec 31 '14 at 5:14
  • I agree with that -- did you have a look into beamer.cls? – user31729 Dec 31 '14 at 5:16
  • @ChristianHupfer I'm not sure I'm up to that at "Oh'dark thirty" where I sit ;^). Perhaps tomorrow. – Steven B. Segletes Dec 31 '14 at 5:17
5

The bottom line is that this is a design decision. To understand what is going on, we need to look at the technical detail.

When Leslie Lamport wrote LaTeX, he decided that as a user having a difference between optional and mandatory arguments was a 'good thing'. He did that by using the { ... } pair for mandatory arguments and the [ ... ] pair for optional ones. However, other people writing LaTeX code can use other conventions.

In LaTeX, the characters [ and ] have TeX category codes 'other'. In contrast to { and }, which are 'begin group' and 'end group', respectively. TeX does brace matching when grabbing an argument inside { ... } (a LaTeX mandatory argument) as the rules for 'begin'/'end' group tokens are clear: they must balance. On the other hand, TeX does not do that for [ ... ] as they are just 'other' tokens. LaTeX2e implements optional arguments using some look-ahead code (to find a [) and what is called a delimited argument

\def\foo[#1]{% Code here

When TeX looks for an argument surrounded by tokens in this way, it does it in a 'lazy' sense. Thus

\foo[[bar]]

will grab [bar as #1 and leave the second ] 'dangling'.

It is possible to add additional code to do matching of [ ... ] tokens: xparse does this. The 'cost' (lines of code) is too high to have been realistic when LaTeX2e was released but is now perfectly acceptable. Thus commands produced using xparse do not have the issue with nested square brackets.

In the beamer case, Till Tantau uses some look-ahead code for { rather than [. It's slightly more tricky to do this, but it's is quite workable if commands do not need to be 'expandable'. There are a few minor issues with verbatim slides (the look-ahead is a bit of a pain!), but other than that the reason to not favour Till's approach is that it's not at all obvious reading the code which arguments are required.

| improve this answer | |
  • Note that LaTeX's not the only format using [ ... ] and { ... } for different things. ConTeXt uses sqaure brackets for arguments which are not typeset: the same restrictions on nesting apply. – Joseph Wright Dec 31 '14 at 9:07
4

It is only a hint, but the mechanism of using the same kind of braces in different meanings is well-known in basic LaTeX. In

\begin{picture}(a,b)(c,d)

(a,b) are mandatory, (c,d) optional. The trick is the following:

\long\gdef\picture#1{\pictur@#1}
\gdef\pictur@(#1){%
  \@ifnextchar({\@picture(#1)}{\@picture(#1)(0,0)}}

The construction in beamerbaseframe.sty is similar:

  \def\beamer@checkframetitle{\@ifnextchar\bgroup\beamer@inlineframetitle{}}
  \def\beamer@inlineframetitle#1{%
    \@ifnextchar\bgroup{\frametitle{#1}\framesubtitle}{\frametitle{#1}\relax}%

but ( is replaced by \bgroup.

| improve this answer | |
  • Why do the contents of the argument need be not expandable, but the delimiter can be? – 1010011010 Dec 31 '14 at 10:08
  • I'm sorry for you that I chose to give Joseph the acceptance. His answer put things in a larger perspective. But I really appreciate you tracking down the chunk of relevant code where I can see with my eyes what is happening. Thanks again. – Steven B. Segletes Jan 3 '15 at 13:15
  • @StevenB.Segletes For me it is also a better answer. It remains that I am still proud that I could add at least a bit to the knowledge of so advanced user as you. – Przemysław Scherwentke Jan 7 '15 at 12:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.