Fragile frames

[josephwright]

I wonder if rather than have individual frames as fragile, this should be a global setting. Most presentations don't need verbatim at all, so would stay 'fast', but for those people who do need verbatim content, it would be a one-shot - so easier setup for the frame environment, etc. (A one-shot branching in the preamble.)

[samcarter]

Most presentations don't need verbatim at all

I think the most common use case for fragile aren't frames with verbatim, but to avoid various problems with the current handling of frame content and tikz pictures.

If the speed is the only disadvantage of fragile frames, I think switching it on globally would work. If it causes other limitations, like in beamer, being able to select it on a per frame basis would be more flexible.

---

Throwing another idea in: How about a dedicated environment for fragile frames instead of a frame option? This would also avoid problems of having \end{frame} in the verbatim content. (... which admittedly might not be a big problem, I'm probably biased on how often one talks about beamer code...)

[FrankMittelbach]

Or even have it turned on by default, with the option to globally turn it off and use it on individual frames

[Skillmon]

This is not OS io, I'm pretty confident we can get everything working using \scantokens (but not \tl_rescan:nn). For a PoC see enverb. Otherwise I agree with @FrankMittelbach, having a global and a local option would be fine, imho.

[Skillmon]

Given that @Skillmon has writing access to this repository, I'm not worried about speed :P

We want to create clean code, so there is only so much I can do without re-implementing many L3 functions exploiting some known edge-cases, so don't expect miracles from me here :P

[FrankMittelbach]

This is not OS io, I'm pretty confident we can get everything working using \scantokens (but not \tl_rescan:nn). For a PoC see enverb. Otherwise I agree with @FrankMittelbach, having a global and a local option would be fine, imho.

well, it is at the moment but I guess you are right it could probably be done without the IO overhead

[josephwright]

I think on this we will need some real benchmarking to see the impact - but once we have other stuff in place (fragile frames are overall quite niche - important to people teaching LaTeX, less so for other things).

[cfr42]

Could you allow both? That is, either set it globally or for a particular frame? If it is global, pass it to every frame?

[FrankMittelbach]

I don't see that and agree with @cfr42. If you have a global option then you can check a boolean if if that is true you do it on the frame, if it is false and you have a "fragile" key on the frame that it would locally be turned true and you also do it. Where's the technical problem or complexity in that?

In other words you don't have to make the global option pass "fragile" to every frame to be reprocessed there with the full keyval machinery (which would be a big slowdown on top). Am I missing something?

[Skillmon]

@FrankMittelbach there is a complexity overhead involved: For a global option we can just change from O{} b to O{} c, here we have to change the collection of the body without ltcmd-means, because the pre-code necessarily needs to be executed to parse the keys.

[josephwright]

@Skillmon Exactly - hence my desire to either avoid the issue entirely or make it a one-off global choice - but if that's not performant, then I think we stick to the current model.

[cfr42]

@FrankMittelbach there is a complexity overhead involved: For a global option we can just change from O{} b to O{} c, here we have to change the collection of the body without ltcmd-means, because the pre-code necessarily needs to be executed to parse the keys.

Feel free to ignore, but what is c?

[josephwright]

New 'collect the body verbatim' argument type for ltcmd.

[josephwright]

I now have a prototype that I think would work for 'all frames can contain verbatim':

\DocumentMetadata{tagging = on}
\documentclass{xbeamer}
\usepackage{fancyvrb}
\EditInstance{hidden}{std}{opacity = 0.15}
\ExplSyntaxOn
\RenewDocumentEnvironment { frame } { D <> { all } O { } c }
  {
    \keys_set:nn { xbeamer / frame } {#2}
    \__xbeamer_mode:nT {#1}
      { \__xbeamer_frame_process:n {#3} }
  }
  { }
\group_begin:
  \char_set_catcode_other:n { `\^^M }%
  \cs_gset_protected:Npn \__xbeamer_slide_setup:Nn #1#2%
    {%
      \group_begin:%
        \cs_set:Npn \obeyedline { ^^M }%
        \tl_set:Ne #1 {#2}%
      \exp_args:NNNV \group_end:%
      \tl_set:Nn #1 #1%
    }%
\group_end:%
\cs_gset_protected:Npn \__xbeamer_slide:n #1
  {
    \group_begin:
      \int_gzero:N \g__xbeamer_slide_int
      \RenewCommandCopy \frame \__xbeamer_latexe_frame:n
      \bool_do_while:Nn \g__xbeamer_slide_continue_bool
        {
          \__xbeamer_slide_begin:
            \__xbeamer_slide_setup:Nn \l__xbeamer_tmp_tl {#1}
            \int_set:Nn \tex_newlinechar:D { 13 }
            \tex_scantokens:D \exp_after:wN { \l__xbeamer_tmp_tl }
          \__xbeamer_slide_end:
        }
    \group_end:
  }
\ExplSyntaxOff


\begin{document}

\begin{frame}<all>
  \frametitle{Foo}
  \emph{foo}
  \begin{block}<2-|alert@2>
    \begin{Verbatim}[gobble = 6]
      Some content
      %$_\
      XXX
    \end{Verbatim}
  \end{block}
  \uncover<3->{More text}
\end{frame}

\end{document}

At present, there is an issue if you don't have one of the optional arguments to the frame environment - I will need to see if I can fix that in the LaTeX kernel ltcmd code. In the end, if not, I could stick to a hand-crafted grabber (though I'd prefer not too).

If this approach looks viable, I'd like to trial it as part of the development work: probably at the moment with a global switch which I can set as opt out (so we get testing). If that then looks good, a bit of expl3 development, etc., will be needed but that should be OK.

Thoughts?

[Skillmon]

BTW, at present if you try this approach without an optional arg., you might get a low-level error if the frame starts e.g. \begin{verbatim}. So I will fix but suggest for testing we make this global opt-in, so that one can add a \relax or similar as needed.

Not if you change the signature to \RenewDocumentEnvironment { frame } { !D <> { all } O { } c } for the experiment.

[josephwright]

Ah, hadn't thought of that - yes that should work.

[josephwright]

@Skillmon I tried that - still get tokenisation of the first line - so for the present I've gone lower-level. I'll address the need for that if we decide to go with this approach to fragile frames.

[Skillmon]

Hm, for me (at least in a simple test document) it worked with the !. Unfortunate.

[josephwright]

I have a solution in hand, just held up by a technical issue in the kernel - this will be solved by the June release

[Skillmon]

What if we drop the notion of a fragile key, but instead use a fragileframe environment? Since much of the frame environment lives in internal macros this wouldn't result in much code duplication, but it would greatly simplify the handling.

[josephwright]

As I've mentioned elsewhere, I'm hopeful we can find a way to avoid needing users having to worry at all about fragile frames.

[Skillmon]

@josephwright if the performance of the c-approach turns out reasonably fast (let's be honest xbeamer isn't fast anyway) and stable I'm all on your side here :) The above was just a quick idea I wanted to have written down somewhere if it turns out we don't want the global c-version.

[josephwright]

@Skillmon I think performance for the xbeamer code should be reasonable - the tagging part is likely where at present things are slower, but that will doubtless get tweaked

[josephwright]

I've implemented at present as an opt-in - my brief tests show no measurable impact, but I'd like wider opinions.

[Skillmon]

Yes, the real culprit is the (mandatory) tagging code. And yes, that's most likely improvable as well, once it's stable enough to warrant the effort :) I didn't want to step on your toe.

[josephwright]

As I've noted somewhere, using an 'all fragile' approach raises the issue that it doesn't work in say command hooks, so makes the equivalent of

\AtBeginSection{
  \begin{frame}
    \tableofcontents[currentsection]
  \end{frame}
}

problematic. I wonder though as you couldn't have verb-like content here anyway whether one might flip things around, somewhat based on @skillmon's suggestion in another thread. We could have standard frames 'fragile-safe' and have an alternative 'for use in arguments' environment, say

\AddToHook{section/begin}{
  \begin{frame*}
    \tableofcontents[currentsection]
  \end{frame*}
}

Or of course if we want to stick to opt-in for verbatim material, we could use frame* for that - either way we get to stick to using ltcmd for the grabbing and the code is a lot more manageable and portable here than it would be otherwise.

[cfr42]

I'd prefer a descriptive name difference than the starred/non-starred, but maybe that's just because I don't like the LaTeX syntax here generally. If frame/frame* was following a frequently-used and well-known pattern - if it was for numbered versus unnumbered, say - it would be different. But is there any common use of the star to mark fragility?

Or is it that this makes the implementation easier?

[Skillmon]

It doesn't make any difference for the implementation (\NewDocumentEnvironment{frame*}{...}{...} vs \NewDocumentEnvironment{frameverb}{...}{...}), but you get nicer support from your editor (for many editors) if you simply switch from frame to frame* or vice versa.

[josephwright]

Naming is open - but as you can use \NewEnviornmentCopy here, you could 'roil you own' easily.

[josephwright]

I've gone with an approach based on frame/frame* - we'll see as wider testing happens how that looks.