Re: [BUG] Re: The orgframe construct in the Beamer exporter as a default needs a rethink

To continue... my first reaction to the bug was to (setq org-beamer-frame-environment "frame") to test. That resulted in \newenvironment<>{frame}[1][]{\begin{frame}[environment=frame,#1]}{\end{frame}} which is somehow weird and wrong. This is why I propose to wrap the code in an (unless (string=

Re: [BUG] Re: The orgframe construct in the Beamer exporter as a default needs a rethink

Hi Leo, Wouldn't it be wiser to combine you fix with mine. I still think that setting org-beamer-frame-environment to "frame" when you don't need the fix and not emitting the extra newenvironment code in that case makes the generated LaTeX easier to read. Whether the default value should be frame

[BUG] Re: The orgframe construct in the Beamer exporter as a default needs a rethink

Hello, Thanks for the bug report. The definition of the orgframe environment did not pass the overlay spec to the underlying frame environment. I believe the attached patch fixes that. Attached is an org file that appears to exercise the patch and show that it is doing the right thing. Could you

In capture, is there a back-reference form for property prompts?

In capture, ‘%\N’ provides back-references to the value entered in response to the Nth prompt of the form ‘%^{PROMPT}’. But from what I can see, when figuring out which prompt is the Nth, capture does not consider *property* prompts; i.e. those of the form ‘%^{PROP}p’. So is there anything

Experimental public branch for inline special blocks

Hi, Finally, I have made public on GitLab my experimental branch for the new (possible) inline-special-block element: The code incorporates fixes and modifications and I have also added some ideas from Maxim Nikulin. The LaTeX and HTML backends are

Re: The orgframe construct in the Beamer exporter as a default needs a rethink

A possible way to preserve the feature (which has its merits in some cases) would be the patches attached. Best, /PA 0001-Don-t-create-new-environment-if-org-beamer-frame-env.patch Description: Binary data 0002-Set-default-value-of-org-beamer-frame-environment-to.patch Description: Binary

Re: The orgframe construct in the Beamer exporter as a default needs a rethink

HI Eric, Neither did I, until I had to do my slide decks ;-) Anyhow, since this feature solves issues, we could think about another approach. A quick and dirty fix would be to check whether org-beamer-frame-environment is “frame” and if so, not redefine the environment. The second step in

Re: The orgframe construct in the Beamer exporter as a default needs a rethink

On Friday, 1 Mar 2024 at 12:33, Pedro Andres Aranda Gutierrez wrote: > I needed to go back to stock org-mode (as included in Emacs) because > the ‘orgframe’ as defined right now kills my slide decks. > I have been using the construct > > ** Title >:PROPERTIES: >:BEAMER_act: >:END: I

[BUG] (wrong-type-argument integer-or-marker-p nil) [9.6.15 (release_9.6.15 @ /home/phi/Source/emacs/lisp/org/)]

Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See https://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list.

The orgframe construct in the Beamer exporter as a default needs a rethink

Hi, I needed to go back to stock org-mode (as included in Emacs) because the ‘orgframe’ as defined right now kills my slide decks. I have been using the construct ** Title :PROPERTIES: :BEAMER_act: :END: For slides I only want in the presentation and ** Title :PROPERTIES: