Closed amonakov closed 5 months ago
Thanks for your PR! As this is like an open-heart-surgery on beamer, I'll do a bit of testing before merging.
I think this PR needs both @samcarter and I to read carefully. What we definitely should do is tidy up coding in such changes: for example, %
should only be at the end of the lines where it's needed.
There might be some difference in the handling of againframes, unfortunately the git history does not go back far enough to see why this was introduced...
There might be some difference in the handling of againframes, unfortunately the git history does not go back far enough to see why this was introduced...
You reading Till's commits ;)
There might be some difference in the handling of againframes, unfortunately the git history does not go back far enough to see why this was introduced...
You reading Till's commits ;)
The ones with *** empty log message ***
are the most helpful ones :)
Can you share your thoughts so far, please?
My thoughts so far are that it seems that there is a difference how again frames are treated, but I haven't yet found an example where this causes a problem.
My proposal would be to merge this into the main branch and keep testing it until after the TL24 code freeze.
@josephwright What do you think?
@josephwright What do you think?
Let me point out he thumbed up your response (Github doesn't send out notifications in such cases afaik).
Expanding the frame environment relies on one of the following macros:
\beamer@doseveralframes
handles the "common case"\beamer@doexternalframe
handles fragile frames, internally invoking the above macro when \frame is invoked recursively with fragile=false\beamer@dosingleframe
handles fragile=singleslide frames without writing an intermediate file, so it doesn't invoke @doseveralframes and the frame cannot be reused via \againframe\beamer@autobreakframe
handles allowframebreaks frames\beamer@donoframe
typesets the frame in a temporary box, which is then discardedBeamer used to choose between them by first branching on presence of a label, and when a label is NOT present, also by testing overlay specification to see if it yields no slides, via the following tree:
This structure is confusing and leads to bugs such as #872 (allowframebreaks is not handled in presence of a label) and #873 (labeled fragile=singleslide frame shown despite
<all:0>
ospec).It also uses \beamer@donoframe to suppress unlabeled slides, but it is inefficient (bug #866) compared to \beamer@doseveralframes which does not typeset the skipped content.
Use the following structure instead:
Fixes #866. Fixes #872. Fixes #873.