On Fri, Jan 26 2024, Ihor Radchenko wrote: > Leo Butler writes: > >>> Apparently, LaTeX has really hard time processing verbatim code inside >>> beamer frames. >> >> I looked again at the solution here: >> https://tex.stackexchange.com/questions/140719/verbatim-in-beamer-showing-error-file-ended-while-scanning-use-of-xverbatim >> >> and it errors out with a recent version of pdflatex: >> >> This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023/Debian) (preloaded format=pdflatex) >> >> This is, apparently, a known problem: >> >> https://github.com/josephwright/beamer/issues/360 >> >> The end of that issue report includes a work-around that we might apply >> in org. I have attached a patch for your feedback. The example that >> stimulated this discussion compiles with the patch and the testsuite >> shows no errors related to it. > > Thanks! > I have concerns about your approach though. > > You are replacing all the frame environments with custom environment > unconditionally. However, custom environment has downsides. For example, > \againframe will stop working, as pointed earlier in the linked beamer > thread > https://github.com/josephwright/beamer/issues/360#issuecomment-708705250 The comment that you are citing shows how to define the custom environment so that \againframe works correctly. See the attachment `beamer-example-againframe.tex' and pdf. You can see that \againframe works with the custom environment. > > Since the problem appears only when the frame contents contains > \end{frame}, it may be sufficient to replace the standard frame > environment with the workaround only in such scenario. Yes, that might be true. But my feeling is that it would be simpler and more robust to use the custom frame environment in most cases. > >> +;; Needed to set-up Beamer export. >> +(defconst org-beamer--frame-environment >> + (concat "orgframe" (org-id-uuid)) >> + "Name of the beamer frame environment. >> +This is randomized to prevent collisions.") > > Please use constant name. (org-id-uuid) makes export randomized for no > good reason. There is a good reason to randomize (or at least make customize-able) the environment name: so that beamer code generated by ox-beamer can be safely inserted into org files and exported by ox-beamer. With a fixed name for the environment, we will have just recreated the original source of the bug report. As a compromise, in the attached patch, I have made the environment name customize-able. > >> ;; Install a default set-up for Beamer export. >> (unless (assoc "beamer" org-latex-classes) >> (add-to-list 'org-latex-classes >> - '("beamer" >> - "\\documentclass[presentation]{beamer}" >> + `("beamer" >> + ,(concat "\\documentclass[presentation]{beamer}\n" >> + ;; Define an alias for the beamer frame environment >> + "\\newenvironment<>{" >> + org-beamer--frame-environment >> + "}[1][]{\\begin{frame}[environment=" >> + org-beamer--frame-environment >> + ",#1]}{\\end{frame}}") > > Please use `org-beamer-template' rather than modifying the class. > Modifying the class may confuse users. Ok, I have done so. The docstring of `org-latex-classes' says: The HEADER-STRING is the header that will be inserted into the LaTeX file. It should contain the \documentclass macro, and anything else that is needed for this setup. From that, I figured that would be the correct place to put that \newenvironment command. I have moved it, as requested. Please see the revised patch. I believe that I have taken into account your suggestions. Leo