* Re: Re: [BUG] beamer export
[not found] <mailman.49.1706374853.3945.emacs-orgmode@gnu.org>
@ 2024-01-28 6:33 ` Pedro Andres Aranda Gutierrez
0 siblings, 0 replies; only message in thread
From: Pedro Andres Aranda Gutierrez @ 2024-01-28 6:33 UTC (permalink / raw)
To: Org Mode List; +Cc: Leo.Butler, Ihor Radchenko
[-- Attachment #1: Type: text/plain, Size: 5598 bytes --]
Hi
CAVEAT EMPTOR: Although it’s some years that I have been using org to create my slides, I never needed this… Interesting to learn new things ;-)
I personally would not oppose to have a customizable org-frame-environment variable, with its default value being “frame”.
Then, when actually emitting the code, add something like:
(unless (string= org-frame-environment “frame”
…)
Which would create the code most of us would expect (i.e. \begin{frame}…\end{frame}) in almost any case except when you really need the `newenvironment’ construct.
My .02 cents, /PA
> El 27 ene 2024, a las 18:00, emacs-orgmode-request@gnu.org escribió:
>
> Message: 2
> Date: Fri, 26 Jan 2024 20:54:17 +0000
> From: Leo Butler <Leo.Butler@umanitoba.ca <mailto:Leo.Butler@umanitoba.ca>>
> To: Ihor Radchenko <yantar92@posteo.net <mailto:yantar92@posteo.net>>
> Cc: Ihor Radchenko <yantar92@gmail.com <mailto:yantar92@gmail.com>>, Daniel Fleischer
> <danflscr@gmail.com <mailto:danflscr@gmail.com>>, Org Mode Mailing List <emacs-orgmode@gnu.org <mailto:emacs-orgmode@gnu.org>>
> Subject: Re: [BUG] beamer export
> Message-ID: <87wmrvlsso.fsf@t14.reltub.ca <mailto:87wmrvlsso.fsf@t14.reltub.ca>>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Fri, Jan 26 2024, Ihor Radchenko <yantar92@posteo.net <mailto:yantar92@posteo.net>> wrote:
>
>> Leo Butler <Leo.Butler@umanitoba.ca <mailto:Leo.Butler@umanitoba.ca>> 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 <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 <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 <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
[-- Attachment #2: Type: text/html, Size: 42296 bytes --]
^ permalink raw reply [flat|nested] only message in thread