From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Price Subject: standardizing slideshow outpout, a la pandoc Date: Tue, 22 Sep 2015 16:26:50 -0400 Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e01538ab6619c0f05205bd1ca Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:39270) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZeU9N-0006sF-4m for emacs-orgmode@gnu.org; Tue, 22 Sep 2015 16:26:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZeU9L-0001lO-8Q for emacs-orgmode@gnu.org; Tue, 22 Sep 2015 16:26:53 -0400 Received: from mail-ig0-x236.google.com ([2607:f8b0:4001:c05::236]:37829) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZeU9L-0001lA-3y for emacs-orgmode@gnu.org; Tue, 22 Sep 2015 16:26:51 -0400 Received: by igbni9 with SMTP id ni9so16852342igb.0 for ; Tue, 22 Sep 2015 13:26:50 -0700 (PDT) List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Org Mode --089e01538ab6619c0f05205bd1ca Content-Type: text/plain; charset=UTF-8 Hi everyone, I'm co-teaching a class this term and my co-instructor is a markdown user, so I am getting to know a little bit about pandoc. One feature I really love is the unified slideshow export: http://pandoc.org/demo/example19/Producing-slide-shows-with-Pandoc.html All the export filters use the same syntax for slide divisions, slide "builds" (dynamic appearance of slide contents), and sub-slides (reveal.js creates two-dimensional slideshows), as well as for speaker notes. The use of standard markdown features also makes the writing process very convenient. By contrast, some of these features can be a little confusing in Org, and moving from one export format to another can take a certain amount of work. If I want a "build" to work properly in both deck.js and reveal.js, for instance, I need both a properties drawer and an #+ATTR_HTML line. In pandoc I need neither. Does anyone else think it would be worthwhile to standardize some of these features within org itself -- either by adding new syntax/options, or by interpreting existing syntax in a uniform way across export filters? The first option is less invasive, I think, while the second option would be slightly more convenient going forward (for new users at least). Pandoc chooses the second option -- new slides are indicated by a horizontal rule, for instance. If other people like the idea I would be willing to draw up a more complete proposal and write some preliminary code for the export back-ends I'm familiar with. I am unfortunately a slow coder though, so a positive resolution would still be a ways away. Looking forward to hearing what you all think. Thanks! Matt --089e01538ab6619c0f05205bd1ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi everyone,

I'm=20 co-teaching a class this term and my co-instructor is a markdown user,=20 so I am getting to know a little bit about pandoc.=C2=A0 One feature I real= ly love is the unified slideshow export:

http://pandoc.org/d= emo/example19/Producing-slide-shows-with-Pandoc.html

All the exp= ort filters use the same syntax for slide divisions, slide "builds&quo= t; (dynamic appearance of slide contents), and sub-slides (reveal.js create= s two-dimensional=20 slideshows), as well as for speaker notes.=C2=A0 The use of standard markdo= wn features also makes the writing process very convenient.=C2=A0
<= br>
By contrast, some of these features can be a little confusing in Org, and=20 moving from one export format to another can take a certain amount of=20 work.=C2=A0 If I want a "build" to work properly in both deck.js = and=20 reveal.js, for instance, I need both a properties drawer and an=20 #+ATTR_HTML line.=C2=A0 In pandoc I need neither.=C2=A0

Does = anyone=20 else think it would be worthwhile to standardize some of these features=20 within org itself -- either by adding new syntax/options, or by=20 interpreting existing syntax in a uniform way across export filters?=C2=A0= =20 The first option is less invasive, I think, while the second option=20 would be slightly more convenient going forward (for new users at=20 least).=C2=A0 Pandoc chooses the second option -- new slides are indicated = by a horizontal rule, for instance.=C2=A0

If other people like= =20 the idea I would be willing to draw up a more complete proposal and=20 write some preliminary code for the export back-ends I'm familiar with.= =C2=A0 I am unfortunately a slow coder though, so a positive resolution would=20 still be a ways away.=C2=A0

Looking forward to hearing w= hat you all think.
Thanks!
Matt


--089e01538ab6619c0f05205bd1ca--