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

[Ihor Radchenko]

Leo Butler  writes:

> Attached is the updated patch. In addition, I have written three
> regression tests that are attached in a separate patch.

Thanks!
Applied, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=80615195c
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=46909a54e

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

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

[Leo Butler]

On Sun, Mar 17 2024, Ihor Radchenko  wrote:

> Leo Butler  writes:
>
 I'd prefer to keep this information in the INFO channel.
 It will be more consistent.
>>
>> Apologies, I messed up the patch in the previous email.
>>
>> Attached is a patch that compiles cleanly and uses INFO.
>
> Thanks!
>
>> + (frame (let ((selection
>> +   (or (and fragilep
>> +(or (string-search "\\begin{frame}" 
>> contents)
>> +(string-search "\\end{frame}" contents))
>
> Please use `string-match-p'. `string-search' is not available in Emacs
> 27, which we still support.

Done.

>
>> +org-beamer-frame-environment)
>> +   "frame")))
>> +  (unless (string= selection "frame")
>> +(setq info (plist-put info :define-frame t)))
>
> Let's use "beamer" prefix to indicate that this plist entry is
> beamer backend-specific. Something like :beamer-define-frame.

Done.

Attached is the updated patch. In addition, I have written three
regression tests that are attached in a separate patch.

Leo

From 3b10e0013ba98cbc2b441507da359996e3d8701c Mon Sep 17 00:00:00 2001
From: Leo Butler 
Date: Tue, 12 Mar 2024 15:11:27 -0500
Subject: [PATCH 1/2] lisp/ox-beamer.el: constrain use of
 org-beamer-frame-environment

* lisp/ox-beamer.el (org-beamer--format-frame, org-beamer-template):
Only use `org-beamer-frame-environment' when a frame is marked as
fragile and the frame's contents include either \begin{frame} or
\end{frame}.  When `org-beamer-frame-environment' is used and not
equal to "frame", add the property :beamer-define-frame to INFO and
set it to t.  When that property is t, `org-beamer-template' emits a
definition of the alternative frame environment.

Refs: https://list.orgmode.org/orgmode/87bk7jeik8.fsf@localhost/
https://list.orgmode.org/87a5nux3zr@t14.reltub.ca/T/
---
 lisp/ox-beamer.el | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/lisp/ox-beamer.el b/lisp/ox-beamer.el
index 4fad37b59..8bae93c11 100644
--- a/lisp/ox-beamer.el
+++ b/lisp/ox-beamer.el
@@ -429,8 +429,21 @@ used as a communication channel."
 	  ;; among `org-beamer-verbatim-elements'.
 	  (org-element-map headline org-beamer-verbatim-elements 'identity
 			   info 'first-match))
- (frame (or (and fragilep org-beamer-frame-environment)
-"frame")))
+ ;; If FRAGILEP is non-nil and CONTENTS contains an occurrence
+ ;; of \begin{frame} or \end{frame}, then set the FRAME
+ ;; environment to be `org-beamer-frame-environment';
+ ;; otherwise, use "frame". If the selected environment is not
+ ;; "frame", then add the property :beamer-define-frame to
+ ;; INFO and set it to t.
+ (frame (let ((selection
+   (or (and fragilep
+(or (string-match-p "begin{frame}" contents)
+(string-match-p "end{frame}" contents))
+org-beamer-frame-environment)
+   "frame")))
+  (unless (string= selection "frame")
+(setq info (plist-put info :beamer-define-frame t)))
+  selection)))
 (concat "\\begin{" frame "}"
 	;; Overlay specification, if any. When surrounded by
 	;; square brackets, consider it as a default
@@ -851,8 +864,8 @@ holding export options."
  (org-latex--insert-compiler info)
  ;; Document class and packages.
  (org-latex-make-preamble info)
- ;; Define the alternative frame environment.
- (unless (equal "frame" org-beamer-frame-environment)
+ ;; Define the alternative frame environment, if needed.
+ (when (plist-get info :beamer-define-frame)
(format "\\newenvironment<>{%s}[1][]{\\begin{frame}#2[environment=%1$s,#1]}{\\end{frame}}\n"
org-beamer-frame-environment))
  ;; Insert themes.
-- 
2.43.0

From 4377c4a55d1fe879b92f268edebcf03d72821703 Mon Sep 17 00:00:00 2001
From: Leo Butler 
Date: Sun, 17 Mar 2024 08:14:54 -0500
Subject: [PATCH 2/2] testing/lisp/test-ox-beamer.el: New regression tests for
 ox-beamer.

* testing/lisp/test-ox-beamer.el (ox-beamer/orgframe,
ox-beamer/orgframe-in-example, ox-beamer/orgframe-in-one-example): New
file.  Regression tests for ox-beamer.  Test that the
`org-beamer-frame-environment' is defined only when used.
---
 testing/lisp/test-ox-beamer.el | 110 +
 1 file changed, 110 insertions(+)
 create mode 100644 testing/lisp/test-ox-beamer.el

diff --git a/testing/lisp/test-ox-beamer.el b/testing/lisp/test-ox-beamer.el
new file mode 100644
index 0..be83b12e0
--- /dev/null
+++ b/testing/lisp/test-ox-beamer.el
@@ -0,0 +1,110 @@
+;;; test-ox-beamer.el --- tests for ox-beamer.el   -*- lexical-binding: t; -*-
+
+;; Copyright (C) 2024  Leo 

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

[Ihor Radchenko]

Leo Butler  writes:

>>> I'd prefer to keep this information in the INFO channel.
>>> It will be more consistent.
>
> Apologies, I messed up the patch in the previous email.
>
> Attached is a patch that compiles cleanly and uses INFO.

Thanks!

> + (frame (let ((selection
> +   (or (and fragilep
> +(or (string-search "\\begin{frame}" contents)
> +(string-search "\\end{frame}" contents))

Please use `string-match-p'. `string-search' is not available in Emacs
27, which we still support.

> +org-beamer-frame-environment)
> +   "frame")))
> +  (unless (string= selection "frame")
> +(setq info (plist-put info :define-frame t)))

Let's use "beamer" prefix to indicate that this plist entry is
beamer backend-specific. Something like :beamer-define-frame.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

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

[Leo Butler]

On Sat, Mar 16 2024, Leo Butler  wrote:

> On Fri, Mar 15 2024, Ihor Radchenko  wrote:
>
>> Leo Butler  writes:
>>
 Leo, may you improve the patch to avoid defining
 `org-beamer-frame-environment' when it is not used in all the frames?
>>>
>>> "all the" should be "any of" in that last sentence.
>>
>> Indeed.
>>
>>> How about the attached patch?
>>> ...
>>> +(defvar org-beamer--frame-environment-used nil
>>> +  "Nil unless `org-beamer-frame-environment' is used.
>>> +See `org-beamer--frame-environment'.")
>>
>> I'd prefer to keep this information in the INFO channel.
>> It will be more consistent.

Apologies, I messed up the patch in the previous email.

Attached is a patch that compiles cleanly and uses INFO.

Leo

From 003cf1d417fe8f5d1a9f8fe20980f7f4b7c5d3c4 Mon Sep 17 00:00:00 2001
From: Leo Butler 
Date: Tue, 12 Mar 2024 15:11:27 -0500
Subject: [PATCH] lisp/ox-beamer.el: constrain use of
 org-beamer-frame-environment

* lisp/ox-beamer.el (org-beamer--format-frame, org-beamer-template):
Only use `org-beamer-frame-environment' when a frame is marked as
fragile and the frame's contents include either \begin{frame} or
\end{frame}.  When `org-beamer-frame-environment' is used and not
equal to "frame", add the property :define-frame to INFO and set it to
t.  When that property is t, `org-beamer-template' emits a definition
of the alternative frame environment.

Refs: https://list.orgmode.org/orgmode/87bk7jeik8.fsf@localhost/
https://list.orgmode.org/87a5nux3zr@t14.reltub.ca/T/
---
 lisp/ox-beamer.el | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/lisp/ox-beamer.el b/lisp/ox-beamer.el
index 4fad37b59..090d3d9ab 100644
--- a/lisp/ox-beamer.el
+++ b/lisp/ox-beamer.el
@@ -429,8 +429,21 @@ used as a communication channel."
 	  ;; among `org-beamer-verbatim-elements'.
 	  (org-element-map headline org-beamer-verbatim-elements 'identity
 			   info 'first-match))
- (frame (or (and fragilep org-beamer-frame-environment)
-"frame")))
+ ;; If FRAGILEP is non-nil and CONTENTS contains an occurrence
+ ;; of \begin{frame} or \end{frame}, then set the FRAME
+ ;; environment to be `org-beamer-frame-environment';
+ ;; otherwise, use "frame". If the selected environment is not
+ ;; "frame", then add the property :define-frame to INFO and
+ ;; set it to t.
+ (frame (let ((selection
+   (or (and fragilep
+(or (string-search "\\begin{frame}" contents)
+(string-search "\\end{frame}" contents))
+org-beamer-frame-environment)
+   "frame")))
+  (unless (string= selection "frame")
+(setq info (plist-put info :define-frame t)))
+  selection)))
 (concat "\\begin{" frame "}"
 	;; Overlay specification, if any. When surrounded by
 	;; square brackets, consider it as a default
@@ -851,8 +864,8 @@ holding export options."
  (org-latex--insert-compiler info)
  ;; Document class and packages.
  (org-latex-make-preamble info)
- ;; Define the alternative frame environment.
- (unless (equal "frame" org-beamer-frame-environment)
+ ;; Define the alternative frame environment, if needed.
+ (when (plist-get info :define-frame)
(format "\\newenvironment<>{%s}[1][]{\\begin{frame}#2[environment=%1$s,#1]}{\\end{frame}}\n"
org-beamer-frame-environment))
  ;; Insert themes.
-- 
2.43.0

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

[Leo Butler]

On Fri, Mar 15 2024, Ihor Radchenko  wrote:

> Leo Butler  writes:
>
>>> Leo, may you improve the patch to avoid defining
>>> `org-beamer-frame-environment' when it is not used in all the frames?
>>
>> "all the" should be "any of" in that last sentence.
>
> Indeed.
>
>> How about the attached patch?
>> ...
>> +(defvar org-beamer--frame-environment-used nil
>> +  "Nil unless `org-beamer-frame-environment' is used.
>> +See `org-beamer--frame-environment'.")
>
> I'd prefer to keep this information in the INFO channel.
> It will be more consistent.

See attached.

Leo

From 1df8520f2a4cfc7a7d8d971adc82cbd95d97735c Mon Sep 17 00:00:00 2001
From: Leo Butler 
Date: Tue, 12 Mar 2024 15:11:27 -0500
Subject: [PATCH 1/2] lisp/ox-beamer.el: constrain use of
 org-beamer-frame-environment

* lisp/ox-beamer.el (org-beamer--format-frame, org-beamer-template):
Only use `org-beamer-frame-environment' when a frame is marked as
fragile and the frame's contents include either \begin{frame} or
\end{frame}.  When `org-beamer-frame-environment' is used and not
equal to "frame", add the property :define-frame to INFO and set it to
t.  When that property is t, `org-beamer-template' emits a definition
of the alternative frame environment.

Refs: https://list.orgmode.org/orgmode/87bk7jeik8.fsf@localhost/
https://list.orgmode.org/87a5nux3zr@t14.reltub.ca/T/
---
 lisp/ox-beamer.el | 22 ++
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/lisp/ox-beamer.el b/lisp/ox-beamer.el
index 4fad37b59..713978477 100644
--- a/lisp/ox-beamer.el
+++ b/lisp/ox-beamer.el
@@ -429,8 +429,21 @@ used as a communication channel."
 	  ;; among `org-beamer-verbatim-elements'.
 	  (org-element-map headline org-beamer-verbatim-elements 'identity
 			   info 'first-match))
- (frame (or (and fragilep org-beamer-frame-environment)
-"frame")))
+ ;; If FRAGILEP is non-nil and CONTENTS contains an occurrence
+ ;; of \begin{frame} or \end{frame}, then set the FRAME
+ ;; environment to be `org-beamer-frame-environment';
+ ;; otherwise, use "frame". If the selected environment is not
+ ;; "frame", then add the property :define-frame to INFO and
+ ;; set it to t.
+ (frame (let ((selection
+   (or (and fragilep
+(or (string-search "\\begin{frame}" contents)
+(string-search "\\end{frame}" contents))
+org-beamer-frame-environment)
+   "frame")))
+  (unless (string= selection "frame")
+(setq into (plist-put info :define-frame t)))
+  selection)))
 (concat "\\begin{" frame "}"
 	;; Overlay specification, if any. When surrounded by
 	;; square brackets, consider it as a default
@@ -851,8 +864,9 @@ holding export options."
  (org-latex--insert-compiler info)
  ;; Document class and packages.
  (org-latex-make-preamble info)
- ;; Define the alternative frame environment.
- (unless (equal "frame" org-beamer-frame-environment)
+ ;; Define the alternative frame environment, if needed.
+ (when (plist-get info :define-frame)
+   (setq org-beamer--frame-environment-used nil)
(format "\\newenvironment<>{%s}[1][]{\\begin{frame}#2[environment=%1$s,#1]}{\\end{frame}}\n"
org-beamer-frame-environment))
  ;; Insert themes.
-- 
2.43.0

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

[Ihor Radchenko]

Leo Butler  writes:

>> Leo, may you improve the patch to avoid defining
>> `org-beamer-frame-environment' when it is not used in all the frames?
>
> "all the" should be "any of" in that last sentence.

Indeed.

> How about the attached patch?
> ...
> +(defvar org-beamer--frame-environment-used nil
> +  "Nil unless `org-beamer-frame-environment' is used.
> +See `org-beamer--frame-environment'.")

I'd prefer to keep this information in the INFO channel.
It will be more consistent.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

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

[Leo Butler]

On Wed, Mar 13 2024, Ihor Radchenko  wrote:

> Pedro Andres Aranda Gutierrez  writes:
>
>> I really don't have anything to object to the original patch. I support the
>> need to circumvent the "\begin-or-end{frame} inside frame" problem and
>> using orgframe is a clean way of doing so.
>> My only concern is the _default_ value for `org-beamer-frame-environment'.
>> If we set it to "frame", we only need to customise it in the file local
>> variables in files where it needs to be changed and we catch all flies in a
>> stroke:
>>
>> Situation 1: presentation has no "\begin-or-end{frame} inside frame" -> no
>> extra stuff in file local variables AND newenvironment is not generated AND
>> frames are between \begin{frame} and \end{frame}
>> Situation 2: presentation needs to circumvent "\begin-or-end{frame} inside
>> frame" -> set local variable in file AND newenvironment is generated AND
>> frame is changed where it is strictly necessary,
>
> I do not like that users would need to do manual action in situation 2.
> For situation 1, Leo's patch will ensure that all the frames are between
> \begin{frame}..\end{frame}, but newenvironment is still generated.
>
> Leo, may you improve the patch to avoid defining
> `org-beamer-frame-environment' when it is not used in all the frames?

"all the" should be "any of" in that last sentence.

--

How about the attached patch?

The previous org file exports in the same way, and exporting just the
final heading shows that no newenvironment is emitted.

Leo

From 22d829089fc2ca153f1541abe1d5415d311b33d3 Mon Sep 17 00:00:00 2001
From: Leo Butler 
Date: Tue, 12 Mar 2024 15:11:27 -0500
Subject: [PATCH] lisp/ox-beamer.el: constrain use of
 org-beamer-frame-environment

* lisp/ox-beamer.el (org-beamer--format-frame, org-beamer-template):
Only use `org-beamer-frame-environment' when a frame is marked as
fragile and the frame's contents include either \begin{frame} or
\end{frame}.  When `org-beamer-frame-environment' is used and not
equal to "frame", set `org-beamer--frame-environment-used' to t.  When
`org-beamer--frame-environment-used' is t, `org-beamer-template' emits
a definition of the alternative frame environment.

* lisp/ox-beamer.el (org-beamer--frame-environment-used): New
variable.

Refs: https://list.orgmode.org/orgmode/87bk7jeik8.fsf@localhost/
https://list.orgmode.org/87a5nux3zr@t14.reltub.ca/T/
---
 lisp/ox-beamer.el | 26 ++
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/lisp/ox-beamer.el b/lisp/ox-beamer.el
index 4fad37b59..a79490194 100644
--- a/lisp/ox-beamer.el
+++ b/lisp/ox-beamer.el
@@ -167,6 +167,10 @@ used inside beamer slides."
 
 ;;; Internal Variables
 
+(defvar org-beamer--frame-environment-used nil
+  "Nil unless `org-beamer-frame-environment' is used.
+See `org-beamer--frame-environment'.")
+
 (defconst org-beamer-column-widths
   "0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 0.0 :ETC"
   "The column widths that should be installed as allowed property values.")
@@ -429,8 +433,21 @@ used as a communication channel."
 	  ;; among `org-beamer-verbatim-elements'.
 	  (org-element-map headline org-beamer-verbatim-elements 'identity
 			   info 'first-match))
- (frame (or (and fragilep org-beamer-frame-environment)
-"frame")))
+ ;; If FRAGILEP is non-nil and CONTENTS contains an occurrence
+ ;; of \begin{frame} or \end{frame}, then set the FRAME
+ ;; environment to be `org-beamer-frame-environment';
+ ;; otherwise, use "frame". If the selected environment is not
+ ;; "frame", then set `org-beamer--frame-environment-used' to
+ ;; t.
+ (frame (let ((selection
+   (or (and fragilep
+(or (string-search "\\begin{frame}" contents)
+(string-search "\\end{frame}" contents))
+org-beamer-frame-environment)
+   "frame")))
+  (unless (string= selection "frame")
+(setq org-beamer--frame-environment-used t))
+  selection)))
 (concat "\\begin{" frame "}"
 	;; Overlay specification, if any. When surrounded by
 	;; square brackets, consider it as a default
@@ -851,8 +868,9 @@ holding export options."
  (org-latex--insert-compiler info)
  ;; Document class and packages.
  (org-latex-make-preamble info)
- ;; Define the alternative frame environment.
- (unless (equal "frame" org-beamer-frame-environment)
+ ;; Define the alternative frame environment, if needed.
+ (when org-beamer--frame-environment-used
+   (setq org-beamer--frame-environment-used nil)
(format "\\newenvironment<>{%s}[1][]{\\begin{frame}#2[environment=%1$s,#1]}{\\end{frame}}\n"
org-beamer-frame-environment))
  ;; Insert themes.
-- 
2.43.0

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

[Ihor Radchenko]

Pedro Andres Aranda Gutierrez  writes:

> I really don't have anything to object to the original patch. I support the
> need to circumvent the "\begin-or-end{frame} inside frame" problem and
> using orgframe is a clean way of doing so.
> My only concern is the _default_ value for `org-beamer-frame-environment'.
> If we set it to "frame", we only need to customise it in the file local
> variables in files where it needs to be changed and we catch all flies in a
> stroke:
>
> Situation 1: presentation has no "\begin-or-end{frame} inside frame" -> no
> extra stuff in file local variables AND newenvironment is not generated AND
> frames are between \begin{frame} and \end{frame}
> Situation 2: presentation needs to circumvent "\begin-or-end{frame} inside
> frame" -> set local variable in file AND newenvironment is generated AND
> frame is changed where it is strictly necessary,

I do not like that users would need to do manual action in situation 2.
For situation 1, Leo's patch will ensure that all the frames are between
\begin{frame}..\end{frame}, but newenvironment is still generated.

Leo, may you improve the patch to avoid defining
`org-beamer-frame-environment' when it is not used in all the frames?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

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

[Pedro Andres Aranda Gutierrez]

Hi Leo,

I really don't have anything to object to the original patch. I support the
need to circumvent the "\begin-or-end{frame} inside frame" problem and
using orgframe is a clean way of doing so.
My only concern is the _default_ value for `org-beamer-frame-environment'.
If we set it to "frame", we only need to customise it in the file local
variables in files where it needs to be changed and we catch all flies in a
stroke:

Situation 1: presentation has no "\begin-or-end{frame} inside frame" -> no
extra stuff in file local variables AND newenvironment is not generated AND
frames are between \begin{frame} and \end{frame}
Situation 2: presentation needs to circumvent "\begin-or-end{frame} inside
frame" -> set local variable in file AND newenvironment is generated AND
frame is changed where it is strictly necessary,

Cheers, /PA

On Tue, 12 Mar 2024 at 21:32, Leo Butler  wrote:

> On Tue, Mar 12 2024, Ihor Radchenko  wrote:
>
> > Pedro Andres Aranda Gutierrez  writes:
> >
> >> Jup, of course. If you look in org-lint.el, one of the cases that would
> >> trigger a message is when the frame environment uses "frame" directly
> and
> >> there is a \begin{frame} in the org.
> >> Line 1522 onwards in org-lint.el
> >
> > (1)
> > Sure, but we should not demand users to run org-lint. Ideally, exporting
> > any valid Org file should work.
> > The fact that the presence of \begin{frame} breaks beamer is a technical
> > detail users should better not be bothered with. That's why we added the
> > orgframe construct.
> >
> > (2)
> > On the other hand, it is clear that Org mode users are unwilling to
> > tolerate too much of machine generated latex output. So, going further
> > and trying to generate unique orgframe environments might not be ideal.
> >
> > The current approach is a balance between the above considerations.
> >
> > AFAIU, what you propose is reverting the orgframe code; that goes
> > against the first point.
>
> Current git HEAD allows a user like Pedro to effectively turn off the
> orgframe code via
>
> (setq org-beamer-frame-environment "frame")
>
> or an equivalent.
>
> >
> > What I proposed is to reduce the amount of machine-generated code by
> > using `org-beamer-frame-environment' only when strictly necessary.
>
> Attached is a patch that limits the use of
> `org-beamer-frame-environment' to those frames that contain either
> \begin{frame} or \end{frame} in their body.
>
> This has the nice side-effect that one can include example frames
> generated by Org without causing an error (previously, Org exported
> latex that would not compile). See the attachments.
>
> Leo
>
>

-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

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

[Leo Butler]

On Tue, Mar 12 2024, Ihor Radchenko  wrote:

> Pedro Andres Aranda Gutierrez  writes:
>
>> Jup, of course. If you look in org-lint.el, one of the cases that would
>> trigger a message is when the frame environment uses "frame" directly and
>> there is a \begin{frame} in the org.
>> Line 1522 onwards in org-lint.el
>
> (1)
> Sure, but we should not demand users to run org-lint. Ideally, exporting
> any valid Org file should work.
> The fact that the presence of \begin{frame} breaks beamer is a technical
> detail users should better not be bothered with. That's why we added the
> orgframe construct.
>
> (2)
> On the other hand, it is clear that Org mode users are unwilling to
> tolerate too much of machine generated latex output. So, going further
> and trying to generate unique orgframe environments might not be ideal.
>
> The current approach is a balance between the above considerations.
>
> AFAIU, what you propose is reverting the orgframe code; that goes
> against the first point.

Current git HEAD allows a user like Pedro to effectively turn off the
orgframe code via

(setq org-beamer-frame-environment "frame")

or an equivalent. 

>
> What I proposed is to reduce the amount of machine-generated code by
> using `org-beamer-frame-environment' only when strictly necessary.

Attached is a patch that limits the use of
`org-beamer-frame-environment' to those frames that contain either
\begin{frame} or \end{frame} in their body.

This has the nice side-effect that one can include example frames
generated by Org without causing an error (previously, Org exported
latex that would not compile). See the attachments.

Leo

From cab7cd149868be86f80d2c7bb52e2c09c028d4b1 Mon Sep 17 00:00:00 2001
From: Leo Butler 
Date: Tue, 12 Mar 2024 15:11:27 -0500
Subject: [PATCH] lisp/ox-beamer.el: constrain use of
 org-beamer-frame-environment

* lisp/ox-beamer.el (org-beamer--format-frame): Only use
`org-beamer-frame-environment' when a frame is marked as fragile and
the frame's contents include either \begin{frame} or \end{frame}.

Refs: https://list.orgmode.org/orgmode/87bk7jeik8.fsf@localhost/
https://list.orgmode.org/87a5nux3zr@t14.reltub.ca/T/
---
 lisp/ox-beamer.el | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lisp/ox-beamer.el b/lisp/ox-beamer.el
index 4fad37b59..f7e39dde4 100644
--- a/lisp/ox-beamer.el
+++ b/lisp/ox-beamer.el
@@ -429,7 +429,10 @@ used as a communication channel."
 	  ;; among `org-beamer-verbatim-elements'.
 	  (org-element-map headline org-beamer-verbatim-elements 'identity
 			   info 'first-match))
- (frame (or (and fragilep org-beamer-frame-environment)
+ (frame (or (and fragilep
+ (or (string-search "\\begin{frame}" contents)
+ (string-search "\\end{frame}" contents))
+ org-beamer-frame-environment)
 "frame")))
 (concat "\\begin{" frame "}"
 	;; Overlay specification, if any. When surrounded by
-- 
2.43.0

#+startup: beamer
#+LaTeX_CLASS: beamer

* A frame with =orgframe= sample code
#+begin_example
\begin{orgframe}
  Here is a beamer frame.
\end{orgframe}
#+end_example
This is exported in a =frame= environment, although it is marked as fragile.

* A frame with =frame= sample code
#+begin_example
\begin{frame}
  Here is a beamer frame.
\end{frame}
#+end_example
This is exported in an =orgframe= environment, since contains =\begin{frame}= and =\end{frame}=.

* An ordinary frame
\[ z^n = x^n + y^n \]
This is exported in a =frame= environment.

% Created 2024-03-12 Tue 15:28
% Intended LaTeX compiler: pdflatex
\documentclass[presentation]{beamer}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{capt-of}
\usepackage{hyperref}
\newenvironment<>{orgframe}[1][]{\begin{frame}#2[environment=orgframe,#1]}{\end{frame}}
\usetheme{default}
\date{\today}
\title{}
\hypersetup{
 pdfauthor={},
 pdftitle={},
 pdfkeywords={},
 pdfsubject={},
 pdfcreator={Emacs 29.1 (Org mode 9.7-pre)}, 
 pdflang={English}}
\begin{document}

\begin{frame}{Outline}
\tableofcontents
\end{frame}

\begin{frame}[label={sec:org5fbeeef},fragile]{A frame with \texttt{orgframe} sample code}
 \begin{verbatim}
\begin{orgframe}
  Here is a beamer frame.
\end{orgframe}
\end{verbatim}
This is exported in a \texttt{frame} environment, although it is marked as fragile.
\end{frame}
\begin{orgframe}[label={sec:org500e0c5},fragile]{A frame with \texttt{frame} sample code}
 \begin{verbatim}
\begin{frame}
  Here is a beamer frame.
\end{frame}
\end{verbatim}
This is exported in an \texttt{orgframe} environment, since contains \texttt{\textbackslash{}begin\{frame\}} and \texttt{\textbackslash{}end\{frame\}}.
\end{orgframe}
\begin{frame}[label={sec:orga2d3f31},fragile]{An ordinary frame}
 \[ z^n = x^n + y^n \]
This is exported in a 

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

[Ihor Radchenko]

Pedro Andres Aranda Gutierrez  writes:

> Jup, of course. If you look in org-lint.el, one of the cases that would
> trigger a message is when the frame environment uses "frame" directly and
> there is a \begin{frame} in the org.
> Line 1522 onwards in org-lint.el

(1)
Sure, but we should not demand users to run org-lint. Ideally, exporting
any valid Org file should work.
The fact that the presence of \begin{frame} breaks beamer is a technical
detail users should better not be bothered with. That's why we added the
orgframe construct.

(2)
On the other hand, it is clear that Org mode users are unwilling to
tolerate too much of machine generated latex output. So, going further
and trying to generate unique orgframe environments might not be ideal.

The current approach is a balance between the above considerations.

AFAIU, what you propose is reverting the orgframe code; that goes
against the first point.

What I proposed is to reduce the amount of machine-generated code by
using `org-beamer-frame-environment' only when strictly necessary.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

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

[Pedro Andres Aranda Gutierrez]

Jup, of course. If you look in org-lint.el, one of the cases that would
trigger a message is when the frame environment uses "frame" directly and
there is a \begin{frame} in the org.
Line 1522 onwards in org-lint.el

Best, /PA


On Mon, 4 Mar 2024 at 12:06, Ihor Radchenko  wrote:

> Pedro Andres Aranda Gutierrez  writes:
>
> > Org-lint will signal that… IHvHO that’s more than enough
>
> May you elaborate?
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>


-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

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

[Ihor Radchenko]

Pedro Andres Aranda Gutierrez  writes:

> Org-lint will signal that… IHvHO that’s more than enough 

May you elaborate?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

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

[Pedro Andres Aranda Gutierrez]

Org-lint will signal that… IHvHO that’s more than enough 

Enviado desde mi iPhone

> El 2 mar 2024, a las 13:18, Ihor Radchenko  escribió:
> 
> Pedro Andres Aranda Gutierrez  writes:
> 
>> My question to the list is what is more frequent: slides with an \end{frame}
>> that needs to be appear in the slide
>> or slides w/o it.
>> This should guide the final call on the default value for
>> org-beamer-frame-environment.
> 
> We may further constrain `org-beamer-frame-environment' to be used only
> when frame contents actually contains \end{frame}.
> Will it make sense?
> 
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 

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

[Ihor Radchenko]

Pedro Andres Aranda Gutierrez  writes:

> My question to the list is what is more frequent: slides with an \end{frame}
> that needs to be appear in the slide
> or slides w/o it.
> This should guide the final call on the default value for
> org-beamer-frame-environment.

We may further constrain `org-beamer-frame-environment' to be used only
when frame contents actually contains \end{frame}.
Will it make sense?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

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

[Ihor Radchenko]

Pedro Andres Aranda Gutierrez  writes:

> 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= org-beamer-frame-environment "frame") ... )
> so we are protected against people like me ;-)

Makes sense.
Done in 
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=ca061cfac

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

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

[Ihor Radchenko]

Leo Butler  writes:

> Attached is an org file that appears to exercise the patch and show that
> it is doing the right thing. Could you confirm this, please?

Applied, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=60ddec482
Fixed. (the bug is fixed, but we may still continue the discussion)

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

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

[Pedro Andres Aranda Gutierrez]

Hi again,

Or, if you feel more comfortable with

(if (string= org-beamer-frame-environment "frame") ""
   ... )

My question to the list is what is more frequent: slides with an \end{frame}
that needs to be appear in the slide
or slides w/o it.
This should guide the final call on the default value for
org-beamer-frame-environment.

Thx again for the patience,
Best, /PA

On Sat, 2 Mar 2024 at 07:39, Pedro Andres Aranda Gutierrez <
paag...@gmail.com> wrote:

> 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= org-beamer-frame-environment "frame") ... )
> so we are protected against people like me ;-)
>
> Best, /PA
>
> On Sat, 2 Mar 2024 at 07:24, Pedro Andres Aranda Gutierrez <
> paag...@gmail.com> wrote:
>
>> 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
>> org or orgframe is something we can debate.
>>
>> Best, /PA
>>
>> On Sat, 2 Mar 2024 at 00:12, Leo Butler  wrote:
>>
>>> 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 confirm this, please?
>>>
>>> 
>>> Incidentally, I did propose that we introduce a BEAMER_FRAME property so
>>> that it could be manually set, but Ihor did not like that idea so it got
>>> scrapped.
>>>
>>> Thanks,
>>> Leo
>>>
>>>
>>
>> --
>> Fragen sind nicht da, um beantwortet zu werden,
>> Fragen sind da um gestellt zu werden
>> Georg Kreisler
>>
>> Headaches with a Juju log:
>> unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should
>> run a leader-deposed hook here, but we can't yet
>>
>>
>
> --
> Fragen sind nicht da, um beantwortet zu werden,
> Fragen sind da um gestellt zu werden
> Georg Kreisler
>
> Headaches with a Juju log:
> unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
> a leader-deposed hook here, but we can't yet
>
>

-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

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

[Pedro Andres Aranda Gutierrez]

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= org-beamer-frame-environment "frame") ... )
so we are protected against people like me ;-)

Best, /PA

On Sat, 2 Mar 2024 at 07:24, Pedro Andres Aranda Gutierrez <
paag...@gmail.com> wrote:

> 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
> org or orgframe is something we can debate.
>
> Best, /PA
>
> On Sat, 2 Mar 2024 at 00:12, Leo Butler  wrote:
>
>> 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 confirm this, please?
>>
>> 
>> Incidentally, I did propose that we introduce a BEAMER_FRAME property so
>> that it could be manually set, but Ihor did not like that idea so it got
>> scrapped.
>>
>> Thanks,
>> Leo
>>
>>
>
> --
> Fragen sind nicht da, um beantwortet zu werden,
> Fragen sind da um gestellt zu werden
> Georg Kreisler
>
> Headaches with a Juju log:
> unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
> a leader-deposed hook here, but we can't yet
>
>

-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

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

[Pedro Andres Aranda Gutierrez]

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
org or orgframe is something we can debate.

Best, /PA

On Sat, 2 Mar 2024 at 00:12, Leo Butler  wrote:

> 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 confirm this, please?
>
> 
> Incidentally, I did propose that we introduce a BEAMER_FRAME property so
> that it could be manually set, but Ihor did not like that idea so it got
> scrapped.
>
> Thanks,
> Leo
>
>

-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

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

[Leo Butler]

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 confirm this, please?


Incidentally, I did propose that we introduce a BEAMER_FRAME property so
that it could be manually set, but Ihor did not like that idea so it got
scrapped.

Thanks,
Leo

From 4fef88ac31272a39e948fcd334bee28e444a7535 Mon Sep 17 00:00:00 2001
From: Leo Butler 
Date: Fri, 1 Mar 2024 17:06:57 -0600
Subject: [PATCH] lisp/ox-beamer.el: fix orgframe environment definition

* (org-beamer-template):  pass the frame overlay specification to the
frame in the definition of the orgframe environment.

Bug reported by Pedro Andres Aranda Gutierrez.

Ref: https://list.orgmode.org/orgmode/cf58e7a4-233d-4f9d-bbe2-fc1a67e31...@gmail.com/T/
---
 lisp/ox-beamer.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/ox-beamer.el b/lisp/ox-beamer.el
index 998810a28..56e7e06ed 100644
--- a/lisp/ox-beamer.el
+++ b/lisp/ox-beamer.el
@@ -852,7 +852,7 @@ holding export options."
  ;; Document class and packages.
  (org-latex-make-preamble info)
  ;; Define the alternative frame environment.
- (format "\\newenvironment<>{%s}[1][]{\\begin{frame}[environment=%1$s,#1]}{\\end{frame}}\n"
+ (format "\\newenvironment<>{%s}[1][]{\\begin{frame}#2[environment=%1$s,#1]}{\\end{frame}}\n"
  org-beamer-frame-environment)
  ;; Insert themes.
  (let ((format-theme
-- 
2.43.0

#+STARTUP: beamer

* Slide A
:PROPERTIES:
:BEAMER_act: 
:END:

I use
#+begin_example
:PROPERTIES:
:BEAMER_act: 
:END:
#+end_example

For slides I only want in the presentation and

* Handout
:PROPERTIES:
:BEAMER_act: 
:END:

For slides I only want in the handout. With the new orgframe
environment as of now, the argument between the <> is not passed to
the frame and therefore lost.

* Slide B
I don’t know how often the orgframe is needed (I haven’t needed it in
the last years of making my presentations with org-mode), but wouldn’t
it be more sensible to write
#+begin_example
:PROPERTIES:
:BEAMER_env: orgframe
:END:
#+end_example
When you really do need it?

* Slide C
:PROPERTIES:
:BEAMER_act: 
:END:

This slide is included, too.

* Handout
:PROPERTIES:
:BEAMER_act: 
:END:

This frame is exported as an =orgframe= with the correct =BEAMER_act=:

#+begin_example
:PROPERTIES:
:BEAMER_act: 
:END:
#+end_example
% Created 2024-03-01 Fri 17:06
% Intended LaTeX compiler: pdflatex
\documentclass[presentation]{beamer}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{capt-of}
\usepackage{hyperref}
\newenvironment<>{orgframe}[1][]{\begin{frame}#2[environment=orgframe,#1]}{\end{frame}}
\usetheme{default}
\date{\today}
\title{}
\hypersetup{
 pdfauthor={},
 pdftitle={},
 pdfkeywords={},
 pdfsubject={},
 pdfcreator={Emacs 29.1 (Org mode 9.7-pre)}, 
 pdflang={English}}
\begin{document}

\begin{frame}{Outline}
\tableofcontents
\end{frame}

\begin{orgframe}[label={sec:org0d8497b},fragile]{Slide A}
 I use
\begin{verbatim}
:PROPERTIES:
:BEAMER_act: 
:END:
\end{verbatim}

For slides I only want in the presentation and
\end{orgframe}
\begin{frame}[label={sec:org50260e7}]{Handout}
For slides I only want in the handout. With the new orgframe
environment as of now, the argument between the <> is not passed to
the frame and therefore lost.
\end{frame}
\begin{orgframe}[label={sec:org79072fa},fragile]{Slide B}
 I don’t know how often the orgframe is needed (I haven’t needed it in
the last years of making my presentations with org-mode), but wouldn’t
it be more sensible to write
\begin{verbatim}
:PROPERTIES:
:BEAMER_env: orgframe
:END:
\end{verbatim}
When you really do need it?
\end{orgframe}
\begin{frame}[label={sec:org3036752}]{Slide C}
This slide is included, too.
\end{frame}
\begin{orgframe}[label={sec:org3be6ccc},fragile]{Handout}
 This frame is exported as an \texttt{orgframe} with the correct \texttt{BEAMER\_act}:

\begin{verbatim}
:PROPERTIES:
:BEAMER_act: 
:END:
\end{verbatim}
\end{orgframe}
\end{document}


ox-beamer-bug.pdf
Description: ox-beamer-bug.pdf


On Fri, Mar 01 2024, Pedro Andres Aranda Gutierrez  wrote:

> 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:
>:BEAMER_act: 
>:END:
>
> For slides I only want in the handout. With the new orgframe
> environment as of now, the argument between the <> is not passed to
> the frame and therefore lost.
>
> I don’t 

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

[Pedro Andres Aranda Gutierrez]

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 data


0003-Document-new-org-beamer-frame-environment.patch
Description: Binary data


> El 1 mar 2024, a las 17:03, Fraga, Eric  escribió:
> 
> 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 do similar and hadn't realised that there had been any breaking
> changes as, I guess, I haven't had to create a new slides since the
> orgframe change came through.  This is a rather serious breaking change
> and would affect hundreds of slides for me (two modules I teach not to
> mention research talks).
> 
>> I don’t know how often the orgframe is needed (I haven’t needed it in
>> the last years of making my presentations with org-mode), but wouldn’t
>> it be more sensible to write
>> 
>> ** Title
>>   :PROPERTIES:
>>   :BEAMER_env: orgframe
>>   :END:
> 
> This sounds reasonable (to me).  I didn't follow the orgframe discussion
> closely so cannot say whether this would achieve what motivated the
> changes.
> 
> -- 
> : Eric S Fraga, with org release_9.6.19-1215-g67d937 in Emacs 30.0.50

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

[Pedro Andres Aranda Gutierrez]

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 this discussion is whether we want 
org-beamer-frame-environment
To be “orgbeamer” or “beamer" by default. The first meaning most of us would 
need to customize it
or redefine it in a local variable. The second would mean that whenever there 
are ‘weird’ slides
you set the value to “orgframe” or whatever, and that would be it. With a big 
CAVEAT: you
Will not be able to do the / trick on them.

Best, /PA


> El 1 mar 2024, a las 17:03, Fraga, Eric  escribió:
> 
> 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 do similar and hadn't realised that there had been any breaking
> changes as, I guess, I haven't had to create a new slides since the
> orgframe change came through.  This is a rather serious breaking change
> and would affect hundreds of slides for me (two modules I teach not to
> mention research talks).
> 
>> I don’t know how often the orgframe is needed (I haven’t needed it in
>> the last years of making my presentations with org-mode), but wouldn’t
>> it be more sensible to write
>> 
>> ** Title
>>   :PROPERTIES:
>>   :BEAMER_env: orgframe
>>   :END:
> 
> This sounds reasonable (to me).  I didn't follow the orgframe discussion
> closely so cannot say whether this would achieve what motivated the
> changes.
> 
> -- 
> : Eric S Fraga, with org release_9.6.19-1215-g67d937 in Emacs 30.0.50

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

[Fraga, Eric]

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 do similar and hadn't realised that there had been any breaking
changes as, I guess, I haven't had to create a new slides since the
orgframe change came through.  This is a rather serious breaking change
and would affect hundreds of slides for me (two modules I teach not to
mention research talks).

> I don’t know how often the orgframe is needed (I haven’t needed it in
> the last years of making my presentations with org-mode), but wouldn’t
> it be more sensible to write
>
> ** Title
>:PROPERTIES:
>:BEAMER_env: orgframe
>:END:

This sounds reasonable (to me).  I didn't follow the orgframe discussion
closely so cannot say whether this would achieve what motivated the
changes.

-- 
: Eric S Fraga, with org release_9.6.19-1215-g67d937 in Emacs 30.0.50

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

[Pedro Andres Aranda Gutierrez]

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:
   :BEAMER_act: 
   :END:

For slides I only want in the handout. With the new orgframe environment as of 
now, the argument between the <> is not passed to the frame and therefore lost.

I don’t know how often the orgframe is needed (I haven’t needed it in the last 
years of making my presentations with org-mode), but wouldn’t it be more 
sensible to write

** Title
   :PROPERTIES:
   :BEAMER_env: orgframe
   :END:

When you really do need it?

Just asking… /PA