This is a follow up on beamer's fragile frame as default. What are the drawbacks of setting the default frame to be fragile (or passing the optional fragile argument to all frames). The beamer user guide says
If a frame contains fragile text, different internal mechanisms are used to typeset the frame to ensure that inside the frame the character codes can be reset. The price of switching to another internal mechanism is that either you cannot use overlays or an external file needs to be written and read back (which is not always desirable).
Presumably writing and reading a file takes time and so this increases the time it takes to compile, but are there things that do not work in a fragile frame?
As for an MWE:
\documentclass{beamer}
\def\foo{Something that makes the fragile frame fail is: }
\begin{document}
\begin{frame}
\foo
\end{frame}
\begin{frame}[fragile]
\foo
\end{frame}
\end{document}
I am trying to understand what \foo
would need to be defined as to cause problems.
\foo
is undefined), then withoutfragile
, you get the line number of the\end{frame}
in which the error occurred. On the other hand, withfragile
, you just get the line number within the frame (the.vrb
file), not of the frame itself.fragile
frame.\newcommand{\bar}{bar}
inside a fragile frame doesn't work, but\def\bar{}\renewcommand{\bar}{bar}
does work. I think\newcommand
fails because of the writing a file and reading it back in issue, making this a potential answer. That said, the need to use\newcommand
within a frame and the simple work around, means it is not much of a drawback.fragile
proved problematic and the solution to the problem involved an alternative approach which avoided the need forfragile
.