[export] Easy way to make children of Beamer frames generate list items?

[export] Easy way to make children of Beamer frames generate list items?

[Christoph LANGE]

Dear all,

here is another problem that I have with reusing old Beamer
presentations (Org version 7) with the new exporter.

The manual says that "all frame's children become `block' environments".

Is there a way of reverting to the default behaviour of the old
exporter, which by default exported frame's children as list items?
E.g. by setting a certain property on the frame's children?

Of course I would be able to manually change all lists to plain lists
within Org tree entries, but before starting to do this I would like to
make sure that there is no other way.

Cheers, and thanks in advance,

Christoph

-- 
Christoph Lange, School of Computer Science, University of Birmingham
http://cs.bham.ac.uk/~langec/, Skype duke4701

→ Mathematics in Computer Science Special Issue on “Enabling Domain
  Experts to use Formalised Reasoning”; submission until 31 October.
  http://cs.bham.ac.uk/research/projects/formare/pubs/mcs-doform/

Re: [export] Easy way to make children of Beamer frames generate list items?

[John Hendy]

On Sat, Sep 14, 2013 at 9:28 AM, Christoph LANGE
<math.semantic.web@gmail.com> wrote:
> Dear all,
>
> here is another problem that I have with reusing old Beamer
> presentations (Org version 7) with the new exporter.
>
> The manual says that "all frame's children become `block' environments".
>
> Is there a way of reverting to the default behaviour of the old
> exporter, which by default exported frame's children as list items?
> E.g. by setting a certain property on the frame's children?
>

Tricky problem, and I could see how this would be an issue. I guess I
always held to using unordered lists (- blah) for my lists vs. relying
on the nested headling functionality (** blah). I wonder if you could
tweak the beamer definition somehow to make a sort of "legacy beamer"
class for exporting these?

For example, I have the default template in my .emacs from the Beamer
setup instructions on Worg:

#+begin_src .emacs

(add-to-list 'org-latex-classes
             '("beamer"
               "\\documentclass\[presentation\]\{beamer\}"
               ("\\section\{%s\}" . "\\section*\{%s\}")
               ("\\subsection\{%s\}" . "\\subsection*\{%s\}")
               ("\\subsubsection\{%s\}" . "\\subsubsection*\{%s\}")))


#+end_src

Perhaps something there could be tweaked? I'm no lisp or org -> latex
mapping person, but perhaps others will have an idea of how you can
map something dynamically so that "One level below the H:number
setting gets converted to \itemize" (vs. the current conversion to
\begin{example} ?

Just a thought.


Sorry to not be more help to you!
John

> Of course I would be able to manually change all lists to plain lists
> within Org tree entries, but before starting to do this I would like to
> make sure that there is no other way.
>
> Cheers, and thanks in advance,
>
> Christoph
>
> --
> Christoph Lange, School of Computer Science, University of Birmingham
> http://cs.bham.ac.uk/~langec/, Skype duke4701
>
> → Mathematics in Computer Science Special Issue on “Enabling Domain
>   Experts to use Formalised Reasoning”; submission until 31 October.
>   http://cs.bham.ac.uk/research/projects/formare/pubs/mcs-doform/
>

Re: [export] Easy way to make children of Beamer frames generate list items?

[Suvayu Ali]

Hi Christoph and John,

I'll take an extreme view here.  So apologies in advance.

On Sat, Sep 14, 2013 at 09:40:50AM -0500, John Hendy wrote:
> On Sat, Sep 14, 2013 at 9:28 AM, Christoph LANGE
> <math.semantic.web@gmail.com> wrote:
> > Dear all,
> >
> > here is another problem that I have with reusing old Beamer
> > presentations (Org version 7) with the new exporter.
> >
> > The manual says that "all frame's children become `block' environments".
> >
> > Is there a way of reverting to the default behaviour of the old
> > exporter, which by default exported frame's children as list items?
> > E.g. by setting a certain property on the frame's children?
> >
> 
> Tricky problem, and I could see how this would be an issue. I guess I
> always held to using unordered lists (- blah) for my lists vs. relying
> on the nested headling functionality (** blah). I wonder if you could
> tweak the beamer definition somehow to make a sort of "legacy beamer"
> class for exporting these?

I think it is unwise to keep coming up with ways to support semantically
wrong behaviour just for the sake of backwards compatibility.  This was
changed with good reason and after a lot of discussions.  If you
continue on this path, you will have to keep maintaining this yourself
for all eternity (sorry about the hyperbole :-p).  It's a lot of work
for a long time just to avoid some annoying work now.

> For example, I have the default template in my .emacs from the Beamer
> setup instructions on Worg:
> 
> #+begin_src .emacs
> 
> (add-to-list 'org-latex-classes
>              '("beamer"
>                "\\documentclass\[presentation\]\{beamer\}"
>                ("\\section\{%s\}" . "\\section*\{%s\}")
>                ("\\subsection\{%s\}" . "\\subsection*\{%s\}")
>                ("\\subsubsection\{%s\}" . "\\subsubsection*\{%s\}")))
> 
> 
> #+end_src
> 
> Perhaps something there could be tweaked? I'm no lisp or org -> latex
> mapping person, but perhaps others will have an idea of how you can
> map something dynamically so that "One level below the H:number
> setting gets converted to \itemize" (vs. the current conversion to
> \begin{example} ?

I think the answer is in your response; the template is for headlines up
to a depth n as specified by H:n.  The old (and new) behaviour was (is)
for all headlines deeper than n (n+1 and onwards).  This is
core-functionality, not something that is configurable.

That said, I think converting headlines to lists is not difficult.  You
should be able to define a keyboard macro to semi-automate it.  You can
mark a headline, C-c @, followed by C-c - to convert to a list.
Actually, I think it should be possible to write a custom function to
traverse a buffer and convert all headlines deeper than n to lists using
these same functions.

How about a combination of org-map-entries with a custom function which
does something like this (semi-pseudo-code):

  (lambda nil
    (if (> depth 3)  ; assuming n=3 in H:n
      (progn
        (org-mark-subtree)
        (org-ctrl-c-minus))))

I think you can get depth with something like this:

  (car (org-heading-components))

Hope this helps,

-- 
Suvayu

Open source is the future. It sets us free.

Re: [export] Easy way to make children of Beamer frames generate list items?

[James Harkins]

Suvayu Ali <fatkasuvayu+linux <at> gmail.com> writes:

> I think it is unwise to keep coming up with ways to support semantically
> wrong behaviour just for the sake of backwards compatibility.  This was
> changed with good reason and after a lot of discussions.  If you
> continue on this path, you will have to keep maintaining this yourself
> for all eternity (sorry about the hyperbole :-p).  It's a lot of work
> for a long time just to avoid some annoying work now.

FWIW, I hit this issue about half a year ago, and argued pretty strenuously
that breaking backward compatibility was a Terrible Terrible Thing. But,
having adapted to the new markup spec, I find it's more logically consistent
*and* easier to read while editing.

I still have a semester's worth of class slides to convert from the old
format, week by week, but it's worth it -- do it once per presentation, and
that's the end of it.

The new way really is better (I say this as someone who was horrified six
months ago to find that my old presentations were broken).

hjh

Re: [export] Easy way to make children of Beamer frames generate list items?

[John Hendy]

On Sat, Sep 14, 2013 at 9:16 PM, James Harkins <jamshark70@gmail.com> wrote:
> Suvayu Ali <fatkasuvayu+linux <at> gmail.com> writes:
>
>> I think it is unwise to keep coming up with ways to support semantically
>> wrong behaviour just for the sake of backwards compatibility.  This was
>> changed with good reason and after a lot of discussions.  If you
>> continue on this path, you will have to keep maintaining this yourself
>> for all eternity (sorry about the hyperbole :-p).  It's a lot of work
>> for a long time just to avoid some annoying work now.
>

I mostly agree, but as others are noting some of us had months and
months worth of presentations in the old format, so it's not always
trivial to update and old .org file and re-export. I don't think we
need to semantically (or syntactically?) support the old behavior (I
wouldn't say wrong), but it's worth coming up with solutions for those
who especially aren't using git or quasi-frequent snapshots.

Keep in mind that a majority of users may very well be using
distro-specific releases. I have no idea how, say, Ubuntu's releases
compare to Org's.

In any case, I'm mostly in agreement that Org's changed and thus the
file structure should change... but not all of us use the git and/or
snapshot Org version with regular frequency and thus I expect a fair
amount of trickling in of users surprised at the incompatibility.


John


> FWIW, I hit this issue about half a year ago, and argued pretty strenuously
> that breaking backward compatibility was a Terrible Terrible Thing. But,
> having adapted to the new markup spec, I find it's more logically consistent
> *and* easier to read while editing.
>
> I still have a semester's worth of class slides to convert from the old
> format, week by week, but it's worth it -- do it once per presentation, and
> that's the end of it.
>
> The new way really is better (I say this as someone who was horrified six
> months ago to find that my old presentations were broken).
>
> hjh
>
>

Re: [export] Easy way to make children of Beamer frames generate list items?

[Suvayu Ali]

On Sat, Sep 14, 2013 at 09:49:18PM -0500, John Hendy wrote:
> 
> In any case, I'm mostly in agreement that Org's changed and thus the
> file structure should change... but not all of us use the git and/or
> snapshot Org version with regular frequency and thus I expect a fair
> amount of trickling in of users surprised at the incompatibility.

As I outlined towards the end of my earlier message, it is not possible
(at least easily with some config magic) to get back the old behaviour
with the new exporter.  Maybe then we should have an FAQ stating so and
outlining how one could make the format switch (again, a possible path
provided in my previous message).

Do you think that would be a good idea?  If so, I'll add a short FAQ
with a pointer to this thread for now.  We can clean it up later.

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Re: [export] Easy way to make children of Beamer frames generate list items?

[Christoph LANGE]

Dear all,

many thanks for your extensive feedback.  You more than answered my
question: I conclude for myself that it is not a good idea to use Org
tree entries if one wants list items.  This was "accidentally" supported
by the old exporter, but with the new exporter it makes sense to
manually (or automatically, with some scripting or macro-recording)
convert tree entries to plain lists.  This is what I will now do with my
Beamer presentations.

Cheers,

Christoph

-- 
Christoph Lange, School of Computer Science, University of Birmingham
http://cs.bham.ac.uk/~langec/, Skype duke4701

→ Mathematics in Computer Science Special Issue on “Enabling Domain
  Experts to use Formalised Reasoning”; submission until 31 October.
  http://cs.bham.ac.uk/research/projects/formare/pubs/mcs-doform/

Re: [export] Easy way to make children of Beamer frames generate list items?

[Carsten Dominik]

[-- Attachment #1: Type: text/plain, Size: 1116 bytes --]


On 15.9.2013, at 13:07, Christoph LANGE <math.semantic.web@gmail.com> wrote:

> Dear all,
> 
> many thanks for your extensive feedback.  You more than answered my
> question: I conclude for myself that it is not a good idea to use Org
> tree entries if one wants list items.  This was "accidentally" supported
> by the old exporter, but with the new exporter it makes sense to
> manually (or automatically, with some scripting or macro-recording)
> convert tree entries to plain lists.  This is what I will now do with my
> Beamer presentations.

Dear Christopher,

thank you for this summary, which will help others to see
the balance that had to be struck with the new exporter.

Regards

- Carsten

> 
> Cheers,
> 
> Christoph
> 
> -- 
> Christoph Lange, School of Computer Science, University of Birmingham
> http://cs.bham.ac.uk/~langec/, Skype duke4701
> 
> → Mathematics in Computer Science Special Issue on “Enabling Domain
>  Experts to use Formalised Reasoning”; submission until 31 October.
>  http://cs.bham.ac.uk/research/projects/formare/pubs/mcs-doform/
> 


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [export] Easy way to make children of Beamer frames generate list items?

[Suvayu Ali]

Hi Christoph and others,

On Sun, Sep 15, 2013 at 01:41:32PM +0200, Carsten Dominik wrote:
> 
> On 15.9.2013, at 13:07, Christoph LANGE <math.semantic.web@gmail.com> wrote:
> 
> > Dear all,
> > 
> > many thanks for your extensive feedback.  You more than answered my
> > question: I conclude for myself that it is not a good idea to use Org
> > tree entries if one wants list items.  This was "accidentally" supported
> > by the old exporter, but with the new exporter it makes sense to
> > manually (or automatically, with some scripting or macro-recording)
> > convert tree entries to plain lists.  This is what I will now do with my
> > Beamer presentations.
> 
> Dear Christopher,
> 
> thank you for this summary, which will help others to see
> the balance that had to be struck with the new exporter.

I added these entries on Worg.  Do you think this helps future users
with similar questions?

<http://orgmode.org/worg/org-faq.html#sec-18-1>
<http://orgmode.org/worg/exporters/beamer/ox-beamer.html#migration>

Thanks,

-- 
Suvayu

Open source is the future. It sets us free.

Re: [export] Easy way to make children of Beamer frames generate list items?

[Christoph LANGE]

Hi Suvayu,

2013-09-15 14:42 Suvayu Ali:
> I added these entries on Worg.  Do you think this helps future users
> with similar questions?
>
> <http://orgmode.org/worg/org-faq.html#sec-18-1>
> <http://orgmode.org/worg/exporters/beamer/ox-beamer.html#migration>

Thanks for writing up these FAQ.  They look very helpful to me.

Cheers,

Christoph

-- 
Christoph Lange, School of Computer Science, University of Birmingham
http://cs.bham.ac.uk/~langec/, Skype duke4701

→ Mathematics in Computer Science Special Issue on “Enabling Domain
  Experts to use Formalised Reasoning”; submission until 31 October.
  http://cs.bham.ac.uk/research/projects/formare/pubs/mcs-doform/

Re: [export] Easy way to make children of Beamer frames generate list items?

[John Hendy]

On Sun, Sep 15, 2013 at 5:57 AM, Suvayu Ali <fatkasuvayu+linux@gmail.com> wrote:
> On Sat, Sep 14, 2013 at 09:49:18PM -0500, John Hendy wrote:
>>
>> In any case, I'm mostly in agreement that Org's changed and thus the
>> file structure should change... but not all of us use the git and/or
>> snapshot Org version with regular frequency and thus I expect a fair
>> amount of trickling in of users surprised at the incompatibility.
>
> As I outlined towards the end of my earlier message, it is not possible
> (at least easily with some config magic) to get back the old behaviour
> with the new exporter.  Maybe then we should have an FAQ stating so and
> outlining how one could make the format switch (again, a possible path
> provided in my previous message).
>

My response was geared toward "Is there a handy workaround in the mean
time so that Christoph can get quicker access to his materials" than
"Can we program Org-mode to handle all legacy forms of input to the
exporter." Sorry if it seemed that I was requesting an "official" fix.
It was more of a prompt for someone clever with LaTeX and/or the new
exporter guts to possibly give him some magic to convert lower
headlines to list while he changes over vs. simply saying, "No. You
can't do that."

Now I understand it really just isn't possible at all, and that's a
good answer to have as well :)

> Do you think that would be a good idea?  If so, I'll add a short FAQ
> with a pointer to this thread for now.  We can clean it up later.

I'm not sure on this. I was thinking about your answer some more, and
perhaps I'm trying to be empathetic with those who aren't subscribed
to the mailing list and thus weren't submerged in constant discussions
about the new exporter, opportunities to try it on an experimental
branch, tons of warnings that "it's coming," and so on. Then again, I
countered myself with realizing that it's not like extreme computer
novices are installing this on a daily basis -- each of us probably
had to stumble on it when looking for outlining program alternatives,
either already knew or endured Emacs to use Org (like me), and are
aware of things like mailing lists and StackOverflow.

So... maybe my concern is unfounded. Org users are most likely more
familiar than many with reading manuals/help files, seeking help, etc.
I think there's a decent amount out there about the new exporter, but
it can seem a bit scattered between the manual and Worg. When I wanted
to constantly refer back to the upgrade instructions page that
Bastien/Nicolas created, I was constantly googling "upgrade Org 8.0."
At the time, I don't think it worked with just "upgrade" and no
version. So things like that make me wonder how easy it is to find
these things without sort of knowing where they are.

Alright -- enough wind out of me. All that said, yes, more info and
references/links can't hurt. That's probably the most helpful thing
for newcomers/non-mailing-list people -- something smack-dab on the
Org-mode webpage about FAQs or troubleshooting.


Thanks for the explanations and dialog!
John

>
> Cheers,
>
> --
> Suvayu
>
> Open source is the future. It sets us free.
>