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 

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

[Tommy Kelly]

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 similar to '%\N' that can be used to backref
‘%^{PROP}p’ prompts

thx.

Experimental public branch for inline special blocks

[Juan Manuel Macías]

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 complete,
although of course it can still be perfected. Recapitulating the
necessary information:

The new element can be nested and supports other elements such as links,
macros, emphasis marks, etc.

The basic syntax:

┌
│ {lorem ipsum dolor}
└

produces in LaTeX:

┌
│ \foo{lorem ipsum dolor}
└

and in HTML:

┌
│ lorem ipsum dolor
└

There is also an anonymous variant:

┌
│ &_{lorem ipsum dolor}
└

Optional attributes in square brackets are supported. There are a series
of 'universal' attributes, common to each backend. At the moment:
`:lang', `:color' and `:smallcaps'. Example:

┌
│ [:color red :smallcaps t :lang it]{lorem ipsum dolor}
└

Specific to the LaTeX backend we have the `:prelatex' and `:postlatex'
attributes (which introduce arbitrary code before and after the content)
and `:latex-command', which overrides the exported command.
`:latex-command nocommand' does not export a command flag. Examples:

┌
│ [:prelatex [bar] :postlatex {baz} :lang it :latex-command blah]{lorem 
ipsum dolor}
└

==>

┌
│ \foreignlanguage{italian}{\blah[bar]{lorem ipsum dolor}{baz}}
└

┌
│ &_[:prelatex \foo{bar} :color red]{lorem ipsum dolor}
└

==>

┌
│ {\color{red}\foo{bar}lorem ipsum dolor}
└

Likewise, for HTML we have the `:html-tag' and `:html-class' attributes
(which override the tags and the class name) and another one, more
generic, `:html', which introduces arbitrary code, such as
`style="..."'.

We can group lists of attributes as aliases. The syntax waould be:

┌
│ !{text}
└

and we can also combine aliases with more single attributes:

┌
│ ![more-attributes]{text}
└

An example: let's imagine that we want a specific block for short quotes
in Latin and italics (it is normative in some typographical traditions
that quotes in classical Latin are put in italics instead of quotation
marks):

┌
│ #+options: inline-special-block-aliases:(("latin" :lang "la" :latex-command 
"textit" :html-tag "em"))
│ 
│ Caesar's famous quote: !{Alea iacta est}
│ 
│ Caesar's famous quote: ![:smallcaps t :color blue]{Alea iacta est}
└

==> LaTeX:

┌
│ Caesar's famous quote: \foreignlanguage{latin}{\textit{Alea iacta est}}
│ 
│ Caesar's famous quote: 
{\scshape{}\color{blue}\foreignlanguage{latin}{\textit{Alea iacta est}}}
└

== HTML:

┌
│ Caesar's famous quote: Alea iacta est
│ 
│ Caesar's famous quote: Alea iacta est
└


Best regards,

Juan Manuel 

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño 
editorial y ortotipografía

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

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

[Philip Kaludercic]

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.


This just popped up in my *Warnings* buffer:

--8<---cut here---start->8---
⛔ Warning (org-element-cache): org-element--cache: Org parser error in 
.links.org::29638. Resetting.
 The error was: (wrong-type-argument integer-or-marker-p nil)
 Backtrace:
"  (backtrace-to-string nil)
  (org-element-at-point)
  (org-back-to-heading t)
  (org-back-to-heading-or-point-min t)
  (org-fold-show-entry)
  (org-fold-show-set-visibility lineage)
  (org-fold-reveal)
  (#f(compiled-function () #))
  (occur-mode-goto-occurrence)
  (occur-next-error 1 nil)
  (next-error nil)
  (funcall-interactively next-error nil)
  (command-execute next-error)
"
 Please report this to Org mode mailing list (M-x org-submit-bug-report).
--8<---cut here---end--->8---

I was editing a file through occur over TRAMP, but otherwise I don't
think anything special was going on.

Emacs  : GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.41, 
cairo version 1.18.0)
 of 2024-02-26
Package: Org mode version 9.6.15 (release_9.6.15 @ 
/home/phi/Source/emacs/lisp/org/)

current state:
==
(setq
 org-persist-before-write-hook '(org-element--cache-persist-before-write)
 org-html-format-headline-function 'org-html-format-headline-default-function
 org-html-format-drawer-function #[514 "\207" [] 3 
("/home/phi/Source/emacs/lisp/org/ox-html.elc" . 22340)]
 org-preview-latex-image-directory "/tmp/ltxpng/"
 org-latex-format-inlinetask-function 
'org-latex-format-inlinetask-default-function
 org-speed-command-hook '(org-speed-command-activate
  org-babel-speed-command-activate)
 org-persist-after-read-hook '(org-element--cache-persist-after-read)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-latex-format-headline-function 'org-latex-format-headline-default-function
 org-latex-format-drawer-function #[514 "\207" [] 3 
("/home/phi/Source/emacs/lisp/org/ox-latex.elc" . 31158)]
 org-mode-hook '(#[0 "\301\211\207"
   [imenu-create-index-function org-imenu-get-tree] 2]
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-fold-show-all
append local]
   5]
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook
org-babel-show-result-all append local]
   5]
 org-babel-result-hide-spec org-babel-hide-all-hashes
 site/org-check-language)
 outline-minor-mode-cycle-filter '(closure (t) nil
   (and
(not (looking-at-p "^[[:space:]]+"))
(bolp) (outline-on-heading-p))
   )
 org-use-speed-commands t
 org-confirm-shell-link-function 'yes-or-no-p
 org-export-dispatch-use-expert-ui t
 org-odt-format-headline-function 'org-odt-format-headline-default-function
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 outline-minor-mode-cycle t
 org-occur-hook '(org-first-headline-recenter)
 org-html-format-inlinetask-function 
'org-html-format-inlinetask-default-function
 org-ascii-format-drawer-function #[771 "\207" [] 4 
("/home/phi/Source/emacs/lisp/org/ox-ascii.elc" . 11831)]
 outline-minor-mode-prefix "
"
 org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 "\n\n(fn 
ENTRY)"]
 org-link-parameters '(("attachment" :follow org-attach-follow
:complete org-attach-complete-link)
   ("id" :follow org-id-open)
   ("eww" :follow org-eww-open :store
org-eww-store-link)
   ("rmail" :follow org-rmail-open :store
org-rmail-store-link)
   ("mhe" :follow org-mhe-open :store
org-mhe-store-link)
   ("irc" :follow org-irc-visit :store
org-irc-store-link :export org-irc-export)
   ("info" :follow org-info-open :export
org-info-export :store org-info-store-link
:insert-description
org-info-description-as-command)
   ("gnus" :follow org-gnus-open :store
org-gnus-store-link)
   ("docview" :follow org-docview-open :export
org-docview-export :store
org-docview-store-link)
   ("bibtex" :follow 

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