From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Price Subject: feature request: best practices for speaker notes and incremental lists/elements Date: Fri, 23 Oct 2015 20:56:10 -0400 Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113fb200aa60fa0522cf31b0 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:46466) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zpn80-0003F1-6z for emacs-orgmode@gnu.org; Fri, 23 Oct 2015 20:56:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zpn7z-0000rq-71 for emacs-orgmode@gnu.org; Fri, 23 Oct 2015 20:56:12 -0400 Received: from mail-io0-x22f.google.com ([2607:f8b0:4001:c06::22f]:36323) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zpn7z-0000rm-23 for emacs-orgmode@gnu.org; Fri, 23 Oct 2015 20:56:11 -0400 Received: by ioll68 with SMTP id l68so141087910iol.3 for ; Fri, 23 Oct 2015 17:56:10 -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 --001a113fb200aa60fa0522cf31b0 Content-Type: text/plain; charset=UTF-8 In writing ox-md-pandoc, I ad occasion to translate org-reveal's spearker note syntax into html . It revived an older concern of mine, that ox-reveal and ox-deck have different ways of representing near-identical features within org. ** Speaker notes Speaker notes are represented thus for export to reveal.js: #+BEGIN_NOTES Here are my awesome notes #+END_NOTES and for export to deck.js: * Notes :note: Here are my awesome notes ------------- ** incremental lists/elements incrementally-shown elements are produced thus in reveal: ** My Slide Header #+ATTR_REVEAL: :frag (appear) - list 1 is one click away - list 2 is two clicks away and in deck: * My Slide Header :Properties: :STEP: t :END: - list 1 is one click away - list 2 is two clicks away ------------ I think the two exporters should use the same syntax! I especially think that any future exporters should use a single, unified syntax, and that the older exporters should eventualyl be changed to support that new syntax. And finally, I think the new syntax should be as simple as humanly possible. So I'd like to suggest that the community decide on the best way forward. I don't really have an opinion as to which method is better; in fact, I imagine there's probably a method tjat is better and simpler than any that have been developed thus far. Certianly I think what he have right now is pretty awkward But I think it's worth figuring out what we want to do, and then implementing it. And once we've done that, it wil lbe easier for me to add the proper functionality to the md-pandoc exporter, too. Thanks, Matt --001a113fb200aa60fa0522cf31b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In writing ox-md-pandoc, I ad occasion to translate org-reveal&= #39;s spearker note syntax into html .=C2=A0 It revived an older concern of= mine, that ox-reveal and ox-deck have different ways of representing near-= identical features within org.=C2=A0

** Speaker notes

=
Speaker notes are represented thus for export to reveal.js:

#+BEGIN_NOTES
Here are my awesome notes
#+END_NOTES
and for export to deck.js:

* Notes :note:
Here are my awesome notes

-------------

** increm= ental lists/elements

incrementally-shown elements are pro= duced thus in reveal:

** My Slide Header
#+= ATTR_REVEAL: :frag (appear)
- list 1 is one click away
- list 2 is two clicks away

and in deck:
* My Slide Header
:Properties:
:STE= P: t
:END:
- list 1 is one click away
=
- list 2 is two clicks away

------------

I think the two exporters should use the same syntax! I especially think = that any future exporters should use a single, unified syntax, and that the= older exporters should eventualyl be changed to support that new syntax.= =C2=A0 And finally, I think the new syntax should be as simple as humanly p= ossible.=C2=A0 So I'd like to suggest that the community decide on the = best way forward.=C2=A0

I don't really have an opinion as= to which method is better; in fact, I imagine there's probably a metho= d tjat is better and simpler than any that have been developed thus far.=C2= =A0 Certianly I think what he have right now is pretty awkward=C2=A0 But I = think it's worth figuring out what we want to do, and then implementing= it.=C2=A0

And once we've done that, it wil lbe easier fo= r me to add the proper functionality to the md-pandoc exporter, too.
Thanks,

Matt


--001a113fb200aa60fa0522cf31b0--