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.
\foois 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.vrbfile), not of the frame itself. – cyberSingularity Oct 03 '13 at 21:27fragileframe. – Paul Gaborit Nov 07 '13 at 00:10\newcommand{\bar}{bar}inside a fragile frame doesn't work, but\def\bar{}\renewcommand{\bar}{bar}does work. I think\newcommandfails because of the writing a file and reading it back in issue, making this a potential answer. That said, the need to use\newcommandwithin a frame and the simple work around, means it is not much of a drawback. – StrongBad Nov 07 '13 at 10:56fragileproved problematic and the solution to the problem involved an alternative approach which avoided the need forfragile. – cfr Feb 12 '14 at 01:17\mode<presentation> { ... }. – Henk Metselaar Mar 08 '17 at 01:31