[ANN] Merge of new export framework on Wednesday

[ANN] Merge of new export framework on Wednesday

[Nicolas Goaziou]

                 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
                  ANNOUNCING THE NEW EXPORT FRAMEWORK
                 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━


Table of Contents
─────────────────

1 To Whom Used the Experimental Version
2 What’s New
.. 2.1 New Back-Ends
.. 2.2 Drawer Handling
.. 2.3 Special Blocks
.. 2.4 Improved Asynchronous Export
.. 2.5 Smart Quotes
.. 2.6 Cross Referencing
.. 2.7 Lists of Tables, Lists of Listings
3 Installation
4 Configuration
.. 4.1 Variables
.. 4.2 Hooks
.. 4.3 Filters
.. 4.4 Forking a Back-End
5 Caveats
6 Footnotes


      Hello,

  I will install the new export framework along with a set of back-ends
Wednesday evening (UTC).  Here are a few notes to help you make the
transition.


1 To Whom Used the Experimental Version
═══════════════════════════════════════

    The merge implies some renaming for symbols and files. More
  precisely, “e-” is removed from symbols like variable names, functions
  and back-ends and “org-e-” becomes “ox-” in files. To sum it up:

       ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
                  Old name                      New name         
       ───────────────────────────────────────────────────────────
                   e-latex                       latex           
                 org-e-latex                    ox-latex         
        org-export-latex-packages-alist  org-latex-packages-alist 
       ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

    Be sure to check filters and requires in your configuration files.


2 What’s New
════════════

    Even though the internals are completely different, the new exporter
  mostly behaves like its predecessor.  There are only a few noticeable
  changes.


2.1 New Back-Ends
─────────────────

    New back-ends come with the new export engine:

  • Markdown back-end (name: `md')
  • Texinfo back-end (name: `texinfo')
  • Man back-end (name: `man')

    Most of the other back-ends have been rewritten from scratch, too.


2.2 Drawer Handling
───────────────────

    By default, every drawer but “properties” and “logbook” has its
  contents exported.  See `org-export-with-drawers' variable.


2.3 Special Blocks
──────────────────

    The `org-special-blocks.el' library, which has been moved to
  “contrib/”, is obsolete since its features are included in the new
  export framework.


2.4 Improved Asynchronous Export
────────────────────────────────

    Export can be asynchronous independently on the type of the source
  or output (temporary buffer or file).  A special interface, called
  “The Export Stack”, is used to view the output.  See
  `org-export-in-background' variable.


2.5 Smart Quotes
────────────────

    All back-ends have support for “smart” quotes, according to
  `org-export-default-language' value or the `LANGUAGE' specifications
  in the buffer.  See `org-export-with-smart-quotes'.
    As of now, only “de”, “en”, “es” and “fr” languages are supported,
  but it’s easy to add more.  See `org-export-smart-quotes-alist'.  Do
  not hesitate to contribute more languages.


2.6 Cross Referencing
─────────────────────

    Export has now full support for cross references, through targets
  and `#+NAME' attributes[1].  Pay attention to the following example.

  ╭────
  │ #+CAPTION: A table
  │ #+NAME: table
  │ | a | b |
  │ 
  │ #+CAPTION: Another table
  │ #+NAME: other-table
  │ | c | d |
  │ 
  │ 1. <<itm>>item 1
  │ 2. item 2
  │ 
  │ Look at item [[itm]]! It happens after table [[other-table]].
  ╰────

    When exported, the last line will be displayed as:

  ╭────
  │ Look at item 1! It happens after table 2.
  ╰────

    It doesn’t depend on the back-end used.  It also references
  footnotes, headlines, LaTeX environments…


2.7 Lists of Tables, Lists of Listings
──────────────────────────────────────

    There is support for lists of tables and lists of listings in some
  back-ends with the following syntax:

  ╭────
  │ #+TOC: headlines
  ╰────

  ╭────
  │ #+TOC: tables
  ╰────

  ╭────
  │ #+TOC: listings
  ╰────


3 Installation
══════════════

    There are two ways to install export back-ends.

  1. You may customize `org-export-backends' variable.  It contains
     the list of back-ends that should always be available.

  2. You can also simply require the back-end libraries
     (e.g. `(require 'ox-icalendar)' for the iCalendar back-end).

    Note that with method 1, the back-ends will be loaded only when the
  export framework is used for the first time.


4 Configuration
═══════════════

    Previously, the export engine was configured through variables and
  numerous hooks.  Now, there are variables, only two hooks and
  filters. One can also easily fork a new export back-end from an
  existing one.


4.1 Variables
─────────────

    The easiest way to browse configurable variables should be through
  customize interface.  Though, the old export framework is still
  lurking in the Org shipped with Emacs.
    As a consequence, calling “customize” will also load previous export
  engine.  It can lead to confusion as variables in both frameworks
  share the same suffix.  You will have to be careful and double check
  the origin of each variable being considered.
    Anyway, if you still want to go through this, the following command
  will get you to the right starting point:

  ╭────
  │ M-x customize-group RET org-export RET
  ╰────

    However, I suggest to browse the source files and look after
  `defcustom' entries.


4.2 Hooks
─────────

    Two hooks are run during the first steps of the export process.  The
  first one, `org-export-before-processing-hook' is called before
  expanding macros, Babel code and include keywords in the buffer.  The
  second one, `org-export-before-parsing-hook', as its name suggests,
  happens just before parsing the buffer.
    Their main use is for heavy duties, that is duties involving
  structural modifications of the document.  For example, one may want
  to remove every headline in the buffer during export.  The following
  code can achieve this:

  ╭────
  │ 1  (defun my-headline-removal (backend)
  │ 2    "Remove all headlines in the current buffer.
  │ 3  BACKEND is the export back-end being used, as a symbol."
  │ 4    (org-map-entries
  │ 5     (lambda () (delete-region (point) (progn (forward-line) (point))))))
  │ 6  (add-hook 'org-export-before-parsing-hook 'my-headline-removal)
  ╰────

    Note that functions used in these hooks require a mandatory
  argument, as shown at line 1.


4.3 Filters
───────────

    Filters are lists of functions applied on a specific part of the
  output from a given back-end.  More explicitly, each time a back-end
  transforms an Org object or element into another language, all
  functions within a given filter type are called in turn on the string
  produced.  The string returned by the last function will be the one
  used in the final output.
    There are filters sets for each type of element or object, for plain
  text, for the parse tree, for the export options and for the final
  output.  They are all named after the same scheme:
  `org-export-filter-TYPE-functions', where `type' is the type targeted
  by the filter.
    For example, the following snippet allows me to use non-breaking
  spaces in the Org buffer and get them translated into LaTeX without
  using the `\nbsp' macro:

  ╭────
  │ 1  (defun ngz-latex-filter-nobreaks (text backend info)
  │ 2    "Ensure \" \" are properly handled in LaTeX export."
  │ 3    (when (org-export-derived-backend-p backend 'latex)
  │ 4          (replace-regexp-in-string " " "~" text)))
  │ 5  (add-to-list 'org-export-filter-plain-text-functions
  │ 6               'ngz-latex-filter-nobreaks)
  ╰────

    Three arguments must be provided to a fiter (line 1): the code being
  changed, the back-end used, and some information about the export
  process.  You can safely ignore the third argument for most purposes.
  Note (line 3) the use of `org-export-derived-backend-p', which ensures
  that the filter will only be applied when using `latex' back-end or
  any other back-end derived from it (i.e. `beamer').


4.4 Forking a Back-End
──────────────────────

    This is obviously the most powerful customization, since you work
  directly at the parser level.  Indeed, complete export back-ends are
  built as forks from other once (e.g. Markdown exporter is forked from
  the HTML one).
    Forking a back-end means that if an element type is not transcoded
  by the new back-end, it will be handled by the original one.  Hence
  you can extend specific parts of a back-end without too much work.
    As an example, imagine we want the `ascii' back-end to display the
  language used in a source block, when it is available, but only when
  some attribute is non-nil, like the following:

  ╭────
  │ #+ATTR_ASCII: :language t
  ╰────

    Because the `ascii' back-end is lacking in that area, we are going
  to create a new back-end, `my-ascii', that will do the job.

  ╭────
  │  1  (defun my-ascii-src-block (src-block contents info)
  │  2    "Transcode a SRC-BLOCK element from Org to ASCII.
  │  3  CONTENTS is nil.  INFO is a plist used as a communication
  │  4  channel."
  │  5    (let ((visiblep
  │  6           (org-export-read-attribute :attr_ascii src-block :language)))
  │  7      (if (not visiblep)
  │  8          (org-export-with-backend 'ascii src-block contents info)
  │  9        (let ((utf8p (eq (plist-get info :ascii-charset) 'utf-8)))
  │ 10          (concat
  │ 11           (format
  │ 12            (if utf8p "╭──[ %s ]──\n%s╰────" ",--[ %s ]--\n%s`----")
  │ 13            (org-element-property :language src-block)
  │ 14            (replace-regexp-in-string
  │ 15             "^" (if utf8p "│ " "| ")
  │ 16             (org-element-normalize-string
  │ 17              (org-export-format-code-default src-block info)))))))))
  │ 18  
  │ 19  (org-export-define-derived-backend my-ascii parent
  │ 20    :translate-alist ((src-block . my-ascii-src-block)))
  ╰────

    The `my-ascii-src-block' function looks at the attribute above the
  element (line 6).  If it isn’t true, it gives hand to the `ascii'
  back-end (line 8).  Otherwise, it creates a box around the code,
  leaving room for the language.  A fork of `ascii' back-end is then
  created (line 19).  It only changes its behaviour when translating
  `src-block' type element (line 20).  Now, all it takes to use the new
  back-end is calling the following on a buffer:

  ╭────
  │ (org-export-to-buffer 'my-ascii "*Org MY-ASCII Export*")
  ╰────

    It is obviously possible to write an interactive function for this,
  install it in the export dispatcher menu, and so on.


5 Caveats
═════════

  1. Although the old exporter files have been archived into
     “contrib/” directory, they are not usable anymore.  Org 7.9 will be
     the last release to provide it.

  2. As a consequence, three export back-ends are not available
     anymore: Taskjuggler, XOXO and Docbook.  About the latter, there is
     a new back-end that produces Texinfo files, which can then be
     converted into Docbook format with:

     ╭────
     │ makeinfo --docbook file.texi
     ╰────

  3. Export section from Org manual is now obsolete.  It is being
     rewritten, but until this task is completed, your best source of
     information will still be the ML or the source files.



Footnotes
─────────

[1] Though, it will expect a caption to be properly numbered.


Regards,

-- 
Nicolas Goaziou

Re: [ANN] Merge of new export framework on Wednesday

[François Allisson]

Le dimanche 3 février 2013 à 20h00, Nicolas Goaziou a écrit:
>   I will install the new export framework along with a set of back-ends
> Wednesday evening (UTC).  Here are a few notes to help you make the
> transition.

That's an exciting news! Thanks for all the job already done and to be
done. If the documentation is as good as this announcement, it will be
great!

Cheers,
François Allisson

Re: [ANN] Merge of new export framework on Wednesday

[Detlef Steuer]

Hi Nicolas!

Great news and I'm really looking forward using the new exporter, but:


> 
>   3. Export section from Org manual is now obsolete.  It is being
>      rewritten, but until this task is completed, your best source of
>      information will still be the ML or the source files.
> 
> 

I rely on orgmode for my homepage at work. If that stops just working
without helping documentation that's "no good", at least for me ... 

Is there already a draft of docs available? 

One point to pull me over from vim to emacs was the fantastic documentation of
orgmode. Now I'm sitting here a bit fearful of losing the great tool
for an undetermined period of time. 

If there are no docs at all I, as a simple user, would suggest to
postpone the release till after some usage notes are available. 

Alternatively keep the old exporter alive , please, till the new one
has documentation. (or the migration path has documentation) 

Anyway thanks for all your work!

Just 2c
Detlef

Re: [ANN] Merge of new export framework on Wednesday

[David Bjergaard]

Detlef Steuer <detlef.steuer@gmx.de> writes:

> Hi Nicolas!
>
> Great news and I'm really looking forward using the new exporter, but:
>
>
>> 
>>   3. Export section from Org manual is now obsolete.  It is being
>>      rewritten, but until this task is completed, your best source of
>>      information will still be the ML or the source files.
>> 
>> 
>
> I rely on orgmode for my homepage at work. If that stops just working
> without helping documentation that's "no good", at least for me ... 
>
> Is there already a draft of docs available? 
>
> One point to pull me over from vim to emacs was the fantastic documentation of
> orgmode. Now I'm sitting here a bit fearful of losing the great tool
> for an undetermined period of time. 
>
> If there are no docs at all I, as a simple user, would suggest to
> postpone the release till after some usage notes are available. 
>
> Alternatively keep the old exporter alive , please, till the new one
> has documentation. (or the migration path has documentation) 
>
> Anyway thanks for all your work!
>
> Just 2c
> Detlef

Hi Detlef,

If you rely on org-mode for some production-level things, wouldn't it be
most prudent to wait until the new exporter was shipped and fully tested
before migrating your work setup?  You'll still have all the
documentation for the older version in the mean time, and once the new
documentation is written, you'll be able to migrate with fewer
problems. 

This is the whole principle that drives Debian, Debian-testing, and
Debian-unstable.

    Dave

Re: [ANN] Merge of new export framework on Wednesday

[Suvayu Ali]

On Mon, Feb 04, 2013 at 08:49:28AM -0500, David Bjergaard wrote:
> 
> Detlef Steuer <detlef.steuer@gmx.de> writes:

[...]

> > If there are no docs at all I, as a simple user, would suggest to
> > postpone the release till after some usage notes are available. 
> >
> > Alternatively keep the old exporter alive , please, till the new one
> > has documentation. (or the migration path has documentation) 

[...]

> If you rely on org-mode for some production-level things, wouldn't it be
> most prudent to wait until the new exporter was shipped and fully tested
> before migrating your work setup?  You'll still have all the
> documentation for the older version in the mean time, and once the new
> documentation is written, you'll be able to migrate with fewer
> problems. 
> 

I would echo this sentiment.  Org mode from master has no business in a
production environment, just like any other software project.  You can
still keep using the latest stable release of Org (or even the tip of
the maint branch) in production.  And once everything is ready
(including docs) for the new exporter, it will be released and possibly
shipped with Emacs.  You can easily switch then.

Is there any particular reason for you to use master in production?

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Re: [ANN] Merge of new export framework on Wednesday

[Eric S Fraga]

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

[...]

> I would echo this sentiment.  Org mode from master has no business in a
> production environment, just like any other software project.

Although I agree, in principle, with this statement, life is not always
so straightforward.  I track org for my day to day use because I find
some of the new features that appear quite useful.  However, I do also
rely on some form of stability for certain tasks.  These are conflicting
desires and I realise that this is *my* problem!

However, I also am concerned at the move to the new exporter without
documentation.  This move appears premature if the documentation is not
yet ready, not even in a draft form.

I have been using the new exporter for many tasks but have not
completely moved over for two: generation of beamer presentations and
publishing of web pages.  The latter is probably not a major issue for
me but the former is.  I simply have no idea how to convert my old org
beamer files to the new exporter as there is no documentation at
all.  The source code (org-e-beamer.el) is of some help but not enough
for me to know how to convert, in particular, slides with blocks and
columns.

Maybe it will be trivial to convert.  However, I have been unsuccessful
in finding anything on the mailing list that describes how to.  This
could be my fault in not searching properly, of course, so I would
welcome any pointers to relevant emails.

My solution will be to not update org until that documentation is
available.  Not a major problem but frustrating nonetheless.

By the way, in case this email is taken the wrong way, I am in no way
upset or angry!  And I really appreciate all the work that has gone into
the new exporter: it works brilliantly for those aspects that I have
figured out and is a great step forward for org overall.

Thanks,
eric
-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org 7.9.3e-897-g787a07

Re: [ANN] Merge of new export framework on Wednesday

[Suvayu Ali]

Hi Eric,

On Tue, Feb 05, 2013 at 11:37:35AM +1030, Eric S Fraga wrote:
> 
> I have been using the new exporter for many tasks but have not
> completely moved over for two: generation of beamer presentations and
> publishing of web pages.  The latter is probably not a major issue for
> me but the former is.  I simply have no idea how to convert my old org
> beamer files to the new exporter as there is no documentation at
> all.  The source code (org-e-beamer.el) is of some help but not enough
> for me to know how to convert, in particular, slides with blocks and
> columns.
> 

I have used the beamer export quite a few times with the new exporter,
and I'm very pleased with it.  I believe there is one backwards
incompatible change, apart from that I think it's mostly feature
enhancements.  I have been trying to write some of the things down as a
Worg article as preliminary documentation, but lately I have been
incredibly busy to make any significant progress.  I started from the
old beamer tutorial as a template on how to structure it.

Usually I also keep an eye out on the mailing list for questions related
to the beamer export with the new exporter (although lately I have been
much less active for the same reasons).

Maybe I should put whatever I have on Worg so that others can work on
it.  I'll try to find some time in the coming two weeks.

Hopefully this is a little reassuring.

-- 
Suvayu

Open source is the future. It sets us free.

Re: [ANN] Merge of new export framework on Wednesday

[Eric S Fraga]

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

> Hi Eric,
>
> I have used the beamer export quite a few times with the new exporter,

I must admit I haven't actually tried any of my big beamer talks
(hundreds of slides)... I've been too intimidated to do so!  I have done
a short talk but one with no special blocks, columns, etc.  That worked
very well.  The only problem I had was figuring out how to tell the new
exporter what level of headlines corresponded to frames... and I can't
remember how I found out (#+OPTIONS: H:2)!

Maybe I should just suck it and see!

[...]

> Maybe I should put whatever I have on Worg so that others can work on
> it.  I'll try to find some time in the coming two weeks.

I think that would be great.  I would be happy to work on any such
document if it means getting some documentation in place.  If you want
to send me, offline, what you've got, I'd be happy to have a look.

Thanks,
eric
-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org 7.9.3e-898-gcb1386

Re: [ANN] Merge of new export framework on Wednesday

[Suvayu Ali]

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

Hi Eric,

On Tue, Feb 05, 2013 at 07:55:46PM +1030, Eric S Fraga wrote:
> Suvayu Ali <fatkasuvayu+linux@gmail.com> writes:
> 
> > Maybe I should put whatever I have on Worg so that others can work on
> > it.  I'll try to find some time in the coming two weeks.
> 
> I think that would be great.  I would be happy to work on any such
> document if it means getting some documentation in place.  If you want
> to send me, offline, what you've got, I'd be happy to have a look.
> 

I have attached a somewhat cleaned up version of what I had so far.  You
can apply the patch on top of Worg master.  If you think this is clean
enough for a starting point then I will push it to Worg.

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

[-- Attachment #2: 0001-Documentation-for-beamer-export-with-new-exporter.patch --]
[-- Type: text/plain, Size: 5961 bytes --]

From d7dfb6133bcea0127d0c386334a833e8ac64323e Mon Sep 17 00:00:00 2001
From: Suvayu Ali <fatkasuvayu+linux@gmail.com>
Date: Tue, 5 Feb 2013 10:21:23 +0100
Subject: [PATCH] Documentation for beamer export with new exporter

Start an article to serve as initial documentation for beamer export
using the new exporter.  This is also the working document for a
tutorial for the exporter.
---
 org-tutorials/org-beamer/org-e-beamer.org | 141 ++++++++++++++++++++++++++++++
 1 file changed, 141 insertions(+)
 create mode 100644 org-tutorials/org-beamer/org-e-beamer.org

diff --git a/org-tutorials/org-beamer/org-e-beamer.org b/org-tutorials/org-beamer/org-e-beamer.org
new file mode 100644
index 0000000..f857174
--- /dev/null
+++ b/org-tutorials/org-beamer/org-e-beamer.org
@@ -0,0 +1,141 @@
+#+TITLE:     Beamer presentations using the new export engine
+#+AUTHOR:    Suvayu Ali
+#+EMAIL:     fatkasuvayu+linux at gmail dot com
+#+DATE:      2013-02-05
+#+DESCRIPTION:
+#+KEYWORDS:
+#+LANGUAGE:  en
+#+OPTIONS:   H:3 num:t toc:t \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t
+#+OPTIONS:   TeX:t LaTeX:t skip:nil d:nil todo:t pri:nil tags:not-in-toc
+#+INFOJS_OPT: view:nil toc:nil ltoc:t mouse:underline buttons:0 path:http://orgmode.org/org-info.js
+#+EXPORT_SELECT_TAGS: export
+#+EXPORT_EXCLUDE_TAGS: noexport
+#+LINK_UP:
+#+LINK_HOME:
+
+#+startup: folded
+
+* Introduction
+This tutorial covers exporting org documents to LaTeX Beamer slides
+using the new export engine, =org-elements= and =org-export=, written
+by Nicolas Goaziou.
+
+_Note:_ It will not cover any of the basic features common with the
+old beamer exporter; it will only focus on the improvements, new
+additions and backwards incompatibilities.  It is also assumed that
+the reader is already acquainted with GNU Emacs and Org mode itself.
+Basic understanding of LaTeX and the Beamer package is also assumed.
+
+* Configuring export options
+Apart from the usual export options provided by the =OPTIONS= keyword,
+you can put additional beamer export options in the file header.  For
+a minimal beamer export, you have to specify the =LaTeX_CLASS= and the
+=LaTeX_CLASS_OPTIONS= keywords in the header of a file.  A preset
+export template can be inserted by calling the interactive function
+=org-e-beamer-insert-options-template=.  This can be further modified
+as per your needs.  You can also do a subtree export; in that case you
+can provide the keywords as =PROPERTIES=.  However the keyword names
+should be prepended with =EXPORT_=.  A list of supported
+keywords are,
+
+#+caption: Export option keywords and corresponding subtree properties.
+| File header keywords  | Subtree properties           |
+|-----------------------+------------------------------|
+| =OPTIONS=             | =EXPORT_OPTIONS=             |
+| =LaTeX_CLASS=         | =EXPORT_LaTeX_CLASS=         |
+| =LaTeX_CLASS_OPTIONS= | =EXPORT_LaTeX_CLASS_OPTIONS= |
+| =LaTeX_HEADER=        | =EXPORT_LaTeX_HEADER=        |
+| =BEAMER_THEME=        | =EXPORT_BEAMER_THEME=        |
+| =BEAMER_FONT_THEME=   | =EXPORT_BEAMER_FONT_THEME=   |
+| =BEAMER_INNER_THEME=  | =EXPORT_BEAMER_INNER_THEME=  |
+| =BEAMER_OUTER_THEME=  | =EXPORT_BEAMER_OUTER_THEME=  |
+
+For a subtree export, a few extra keywords are supported.  For example
+you can specify the exported filename with the =EXPORT_FILE_NAME=
+property.
+
+#+caption: Properties specific to subtree export
+| Subtree properties | Functionality    |
+|--------------------+------------------|
+| =EXPORT_TITLE=     | Export title     |
+| =EXPORT_AUTHOR=    | Export author    |
+| =EXPORT_DATE=      | Export date      |
+| =EXPORT_FILE_NAME= | Export file name |
+
+A simple file header might look like the example below.
+#+begin_example
+  ,#+LaTeX_CLASS: beamer
+  ,#+LaTeX_CLASS_OPTIONS: [smaller,presentation]
+  ,#+BEAMER_THEME: default
+#+end_example
+A corresponding subtree export should have properties as shown below.
+#+begin_example
+  ,* Exported title
+    :PROPERTIES:
+    :EXPORT_LaTeX_CLASS: beamer
+    :EXPORT_LaTeX_CLASS_OPTIONS: [presentation,smaller]
+    :EXPORT_BEAMER_THEME: default
+    :EXPORT_FILE_NAME: presentation.pdf
+    :END:
+#+end_example
+
+The export class is passed on to the =\documentclass= LaTeX command,
+and the options go in as the optional arguments.
+: \documentclass[smaller,presentation]{beamer}
+
+** TODO Export level
+- To export third level headlines as frames, use the following in the
+  file header.
+  : #+OPTIONS: H:3
+- Can be overridden with the =frame= beamer environment (maybe link to
+  new features section below).
+
+** TODO Filters to customise export
+
+* Structure editing and beamer environments
+All the usual Org mode structure editing commands work.  However there
+is also a minor mode called =org-e-beamer-mode=, that makes it very
+convenient to insert Beamer specific environments in an org-mode
+buffer.
+
+* New features available with the new exporter
+** TODO Beamer article
+Discuss that =EXPORT_LaTeX_CLASS= need not be beamer.  Useful to
+export =beamerarticle= document for slides.
+
+Email from Nicolas Goaziou discussing this feature:
+http://mid.gmane.org/87hapz3na9.fsf@gmail.com
+
+** TODO Ordered and unordered lists
+
+** TODO Images
+
+** TODO Tables
+
+** TODO Environments
+
+** TODO Overlays
+
+** TODO Example and source blocks
+
+* TODO Examples
+1) [ ] Sectioning and TOC (progress state between sections)
+2) [ ] Overlays
+3) [ ] Blocks
+   1. [ ] Normal blocks
+   2. [ ] Verbatim blocks
+   3. [ ] Source blocks
+4) [ ] Columns
+5) [ ] Text / LaTeX commands in between frames
+6) [ ] Images
+   + Centering
+   + Captions
+7) [ ] Footnotes and references
+8) [ ] Backup slides with =\appendix=
+9) [ ] Caveats about using alternate TeX binaries
+
+* TODO Migrating from the old to the new exporter
+- Backwards incompatible changes in the new exporter
+- Configuration:
+  1. variable name changes,
+  2. filters instead of hooks (except for two)
-- 
1.8.1

Re: [ANN] Merge of new export framework on Wednesday

[Eric S Fraga]

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

> Hi Eric,
>
> On Tue, Feb 05, 2013 at 07:55:46PM +1030, Eric S Fraga wrote:
>> Suvayu Ali <fatkasuvayu+linux@gmail.com> writes:
>> 
>> > Maybe I should put whatever I have on Worg so that others can work on
>> > it.  I'll try to find some time in the coming two weeks.
>> 
>> I think that would be great.  I would be happy to work on any such
>> document if it means getting some documentation in place.  If you want
>> to send me, offline, what you've got, I'd be happy to have a look.
>> 
>
> I have attached a somewhat cleaned up version of what I had so far.  You
> can apply the patch on top of Worg master.  If you think this is clean
> enough for a starting point then I will push it to Worg.
>
> Cheers,

Hi Suvayu,

I think it's definitely worth pushing to Worg.  There's obviously much
to do but having even the basics that you present in this document is
very helpful.  Just knowing that there is an org-e-beamer minor mode
made it worth reading.

If I get my original tutorial updated, the two documents together will
be sufficient for many people, I think.  I'm working on this now but I
have run into some very strange problems to do with frame
levels.  Everything else seems to be fine.

Thanks,
eric
-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org 7.9.3e-898-gcb1386

Re: [ANN] Merge of new export framework on Wednesday

[Suvayu Ali]

Hi Eric,

On Tue, Feb 05, 2013 at 11:20:18PM +1030, Eric S Fraga wrote:
> Suvayu Ali <fatkasuvayu+linux@gmail.com> writes:
> 
> > I have attached a somewhat cleaned up version of what I had so far.  You
> > can apply the patch on top of Worg master.  If you think this is clean
> > enough for a starting point then I will push it to Worg.
> >
> 
> I think it's definitely worth pushing to Worg.  There's obviously much
> to do but having even the basics that you present in this document is
> very helpful.  Just knowing that there is an org-e-beamer minor mode
> made it worth reading.

I pushed the commit, but I see the publishing failed.

remote: Publishing file
/home/emacs/git/worg/org-tutorials/org-beamer/org-e-beamer.org using
`org-publish-org-to-html'
remote: Exporting...
remote: Wrong type argument: stringp, nil
remote: worg publish process 16964 exited at 02/05/13@07:01:27

Not sure why though since I checked publishing to html before
committing.  Can someone take a look?

-- 
Suvayu

Open source is the future. It sets us free.

Re: [ANN] Merge of new export framework on Wednesday

[Suvayu Ali]

On Tue, Feb 05, 2013 at 02:07:50PM +0100, Suvayu Ali wrote:
> Hi Eric,
> 
> On Tue, Feb 05, 2013 at 11:20:18PM +1030, Eric S Fraga wrote:
> > Suvayu Ali <fatkasuvayu+linux@gmail.com> writes:
> > 
> > > I have attached a somewhat cleaned up version of what I had so far.  You
> > > can apply the patch on top of Worg master.  If you think this is clean
> > > enough for a starting point then I will push it to Worg.
> > >
> > 
> > I think it's definitely worth pushing to Worg.  There's obviously much
> > to do but having even the basics that you present in this document is
> > very helpful.  Just knowing that there is an org-e-beamer minor mode
> > made it worth reading.
> 
> I pushed the commit, but I see the publishing failed.
> 

I updated the article considerably.  Comments welcome.

<http://orgmode.org/cgit.cgi/worg.git/commit/?id=0b98d52bee82c856d46df7ce49bc7738fb9d2b4d>

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Re: [ANN] Merge of new export framework on Wednesday

[Bastien]

Hi Detlef and all,

Detlef Steuer <detlef.steuer@gmx.de> writes:

> If there are no docs at all I, as a simple user, would suggest to
> postpone the release till after some usage notes are available. 
>
> Alternatively keep the old exporter alive , please, till the new one
> has documentation. (or the migration path has documentation) 

To be clear (and I think Nicolas assumed it was clear), Org 8.0 
will not be release until the documentation is fully updated.

We will also make sure that Worg contains some useful tips to 
help with the migration, especially when it comes to use filters
instead of hooks -- and on how to use old exporters that will
live in contribs.  For those tasks, any help on Worg will be 
more than welcome!

-- 
 Bastien

Re: [ANN] Merge of new export framework on Wednesday

[Rasmus]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

>                  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>                   ANNOUNCING THE NEW EXPORT FRAMEWORK
>                  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Thanks Nicolas, this is much appreciated.  I have been looking forward
to this for a long time. 

Perhaps we should set up a Worg TODO page for documentation?  To make
it easier to contribute bits. 

Thanks,
Rasmus

-- 
Vote for proprietary math!

org export Taskjuggler (was: Re: [ANN] Merge of new export framework on Wednesday - )

[Giovanni Ridolfi]

----- Messaggio originale -----

> Da: Nicolas Goaziou <n.goaziou@gmail.com>
> Inviato: Domenica 3 Febbraio 2013 20:00
> 
>   2. As a consequence, three export back-ends are not available
>      anymore: Taskjuggler, XOXO and Docbook.  

Are there any plans to have a "taskjuggler export"
compatible with the new exoprt framework?

If not, is there a way I can help/contribute?

By the way, I tried to use the taskjuggler 
export with taskjugler 3.3.0, and it worked 
quite well, only I have not been able to get 
the "report" part of the tjp file working.
Anyway thank you, Christian an Yann for 
the work.

cheers,
Giovanni

Re: org export Taskjuggler

[Nicolas Goaziou]

Hello,

Giovanni Ridolfi <giovanni.ridolfi@yahoo.it> writes:

> ----- Messaggio originale -----
>
>> Da: Nicolas Goaziou <n.goaziou@gmail.com>
>> Inviato: Domenica 3 Febbraio 2013 20:00
>> 
>>   2. As a consequence, three export back-ends are not available
>>      anymore: Taskjuggler, XOXO and Docbook.  
>
> Are there any plans to have a "taskjuggler export"
> compatible with the new exoprt framework?

Yes. This one has a high priority tag put on it.

> If not, is there a way I can help/contribute?

I think, but I may be wrong, that Jambunathan has started something in
the area. You may get in touch with him.

If nothing has been started once the new export framework is installed
and the early bugs are fixed, I will do the port. But, obviously, I'll
appreciate if Someone beats me to it.


Regards,

-- 
Nicolas Goaziou

Re: org export Taskjuggler

[Christian Egli]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> If nothing has been started once the new export framework is installed
> and the early bugs are fixed, I will do the port.

I don't quite understand why we need to "port" anything. The taskjuggler
exporter is different than the other exporters in that it doesn't really
export the content of an org file. Instead it just goes through the
headlines (using the mapping API), takes some to be tasks and reads the
properties of these headlines to build the taskjuggler file. It pretty
much ignores any text that is between the headlines (see also the
commentary in org-taskjuggler.el). In essence it treats the org file as
a tree of nodes with properties that define the tasks, resources and
reports. It doesn't use any of the common (old) exporting
infrastructure. So woudn't a "ported" org-taskjuggler.el look exactly
like to one that we have today?

Thanks
Christian
-- 
Christian Egli
Swiss Library for the Blind, Visually Impaired and Print Disabled
Grubenstrasse 12, CH-8045 Zürich, Switzerland

Re: org export Taskjuggler

[Jambunathan K]

Christian Egli <christian.egli@sbs.ch> writes:

> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>
>> If nothing has been started once the new export framework is installed
>> and the early bugs are fixed, I will do the port.
>
> I don't quite understand why we need to "port" anything. The taskjuggler
> exporter is different than the other exporters in that it doesn't really
> export the content of an org file. Instead it just goes through the
> headlines (using the mapping API), takes some to be tasks and reads the
> properties of these headlines to build the taskjuggler file. It pretty
> much ignores any text that is between the headlines (see also the
> commentary in org-taskjuggler.el). In essence it treats the org file as
> a tree of nodes with properties that define the tasks, resources and
> reports. It doesn't use any of the common (old) exporting
> infrastructure. So woudn't a "ported" org-taskjuggler.el look exactly
> like to one that we have today?

I am not working on Taskjuggler exporter.  I do have a FreeMind exporter
in the works.  

That said, moving the TaskJuggler exporter to new org-export-* APIs -
Nicolas calls them tools - is "a good thing".  Each new exporter,
exercises or emphasizes different aspects of the export infrastructure.
I am sure "porting" TaskJuggler will further solidify the org-export
framework in terms of exposing existing bugs or adding new utilties or
APIs.

        http://orgmode.org/worg/dev/org-export-reference.html

If TaskJuggler exporter "just works", then it is good.  The porting task
can be done in an un-hurried manner.

> Thanks
> Christian

-- 

Re: org export Taskjuggler

[Nicolas Goaziou]

Hello,

Christian Egli <christian.egli@sbs.ch> writes:

> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>
>> If nothing has been started once the new export framework is installed
>> and the early bugs are fixed, I will do the port.
>
> I don't quite understand why we need to "port" anything. The taskjuggler
> exporter is different than the other exporters in that it doesn't really
> export the content of an org file. Instead it just goes through the
> headlines (using the mapping API), takes some to be tasks and reads the
> properties of these headlines to build the taskjuggler file. It pretty
> much ignores any text that is between the headlines (see also the
> commentary in org-taskjuggler.el). In essence it treats the org file as
> a tree of nodes with properties that define the tasks, resources and
> reports. 

What it really exports isn't important. ox.el is a framework to export
any part of an Org buffer (including non-contiguous parts like headlines
only) to another format that can be, at least during an intermediary
step, written as a string.

In a export back-end, you basically specify an export action for each
type of syntax. If nothing is provided, that the syntax will be ignored.
In this case, the taskjuggler back-end would only provide a function for
headlines.

> It doesn't use any of the common (old) exporting
> infrastructure. 

To be honest, I only gave it a cursory look, but it requires "org-exp"
and uses a few functions from from it, like, e.g.
`org-default-export-plist', `org-infile-export-plist',
`org-install-letbind'.

Some work needs to be done at this level.

> So woudn't a "ported" org-taskjuggler.el look exactly
> like to one that we have today?

Externally, it would, hopefully. Internally, some changes are required.
I also think it would much benefit from it, but I'm biased, obviously.


Regards,

-- 
Nicolas Goaziou

Re: [ANN] Merge of new export framework on Wednesday

[Jay Kerns]

Greetings,

The new exporter just arrived in my git repository and I wanted to say
"Congratulations!" but even more importantly, THANK YOU.  Kudos on a
job very well done, if not 100% complete yet.  I have been looking
forward to this for quite some time, now.

I would like to extend my Congratulations and THANK YOU to the rest of
the Org-mode community/team as well, not limited to Nicolas, though
this happens to be the occasion of the new exporter's release.

Org-mode (and GNU-Emacs more generally, and Free software more
generally than that) has changed my life, and by extension those who
live and work near me, in my view, for the better.  Cheers, and may we
share many good days ahead.

-- 
Jay Kerns



On Sun, Feb 3, 2013 at 2:00 PM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
>                  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>                   ANNOUNCING THE NEW EXPORT FRAMEWORK
>                  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>

Re: [ANN] Merge of new export framework on Wednesday

[Sean O'Halpin]

Great work on the new exporter!

One small point: as we're going to have to change the meta directive
"#+STYLE" to "#+HTML_STYLE", can we change the name to reflect what it
really does in the HTML backend, i.e. insert text verbatim into the
<head> element? I suggest we rename it to "#+HTML_HEAD".

Regards,
Sean

Re: [ANN] Merge of new export framework on Wednesday

[Sebastien Vauban]

Hi Sean,

"Sean O'Halpin" wrote:
> One small point: as we're going to have to change the meta directive
> "#+STYLE" to "#+HTML_STYLE", can we change the name to reflect what it
> really does in the HTML backend, i.e. insert text verbatim into the
> <head> element?

Why not...

> I suggest we rename it to "#+HTML_HEAD".

But I'd like to propose HTML_HEADER instead (?), to "mirror" what LaTeX_HEADER
does -- at least, if that one still exists, which I'm not sure about (not
enough played with the new exporter yet).

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [ANN] Merge of new export framework on Wednesday

[Sean O'Halpin]

On Fri, Feb 8, 2013 at 4:45 PM, Sebastien Vauban
<wxhgmqzgwmuf@spammotel.com> wrote:
>
> "Sean O'Halpin" wrote:
>>
>> I suggest we rename it to "#+HTML_HEAD".
>
> But I'd like to propose HTML_HEADER instead (?), to "mirror" what LaTeX_HEADER
> does -- at least, if that one still exists, which I'm not sure about (not
> enough played with the new exporter yet).
>

I'm going on the assumption that what comes after the =#+HTML_= prefix
is specific to the HTML back-end. Where LaTeX has a /conceptual/
header, HTML has a /concrete/ =<head>= element. There's nothing to
mirror =LaTeX_CLASS= for example because the concept of document class
does not exist in HTML.

This raises another question which is more about Org document export
headers in general: why do we have specific document headers for LaTeX
and HTML? Because we need to able to insert raw markup at specific
points in the exported document. (We also have =html-preamble= and
=html-postamble= which act on every document.) But what about other
exporter back-ends? Say we get a native org to docbook exporter. What
would be the mechanism for inserting markup into the =<artheader>=?
Would there be a =#+DOCBOOK_HEADER=?

Please forgive my meandering here. It's just struck me that we might
need a more general mechanism for document-level export directives
that will avoid multiplying the number of =#+HTML_= style directives
we already have. Perhaps something along the lines of:

#+BEGIN_SRC ORG
,#+EXPORT html head <style .../>
,#+EXPORT latex header \usepackage{xyz}
#+END_SRC

where =head= and =header= represent specific places in the exported
document that the exporter in question has defined as places you can
insert raw markup. So, Org would define the =#+EXPORT= protocol,
specific back-ends would define the names and places.

Regards,
Sean

Re: [ANN] Merge of new export framework on Wednesday

[Nicolas Goaziou]

Hello,

"Sean O'Halpin" <sean.ohalpin@gmail.com> writes:

> This raises another question which is more about Org document export
> headers in general: why do we have specific document headers for LaTeX
> and HTML? Because we need to able to insert raw markup at specific
> points in the exported document. (We also have =html-preamble= and
> =html-postamble= which act on every document.) But what about other
> exporter back-ends? Say we get a native org to docbook exporter. What
> would be the mechanism for inserting markup into the =<artheader>=?
> Would there be a =#+DOCBOOK_HEADER=?
>
> Please forgive my meandering here. It's just struck me that we might
> need a more general mechanism for document-level export directives
> that will avoid multiplying the number of =#+HTML_= style directives
> we already have. Perhaps something along the lines of:
>
>
> #+BEGIN_SRC ORG
> ,#+EXPORT html head <style .../>
> ,#+EXPORT latex header \usepackage{xyz}
> #+END_SRC
>
>
> where =head= and =header= represent specific places in the exported
> document that the exporter in question has defined as places you can
> insert raw markup. So, Org would define the =#+EXPORT= protocol,
> specific back-ends would define the names and places.

Not every back-end has a concept of "head" (think about Markdown
back-end). We don't need a general concept for something that isn't
general.

Also, completely unifying every back-end is close to impossible, unless
the same person writes every back-end[1]. Most of the options are
shared, that's the goal of ox.el, but in the end, each back-end decides
how it handles the others.


Regards,

[1] Even then, back-ends are so different that it would ultimately fail,
anyway.

-- 
Nicolas Goaziou

Re: [ANN] Merge of new export framework on Wednesday

[Sean O'Halpin]

On Sat, Feb 9, 2013 at 1:56 PM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> Hello,
>
> "Sean O'Halpin" <sean.ohalpin@gmail.com> writes:
>
>> This raises another question which is more about Org document export
>> headers in general: why do we have specific document headers for LaTeX
>> and HTML? Because we need to able to insert raw markup at specific
>> points in the exported document. (We also have =html-preamble= and
>> =html-postamble= which act on every document.) But what about other
>> exporter back-ends? Say we get a native org to docbook exporter. What
>> would be the mechanism for inserting markup into the =<artheader>=?
>> Would there be a =#+DOCBOOK_HEADER=?
>>
>> Please forgive my meandering here. It's just struck me that we might
>> need a more general mechanism for document-level export directives
>> that will avoid multiplying the number of =#+HTML_= style directives
>> we already have. Perhaps something along the lines of:
>>
>>
>> #+BEGIN_SRC ORG
>> ,#+EXPORT html head <style .../>
>> ,#+EXPORT latex header \usepackage{xyz}
>> #+END_SRC
>>
>>
>> where =head= and =header= represent specific places in the exported
>> document that the exporter in question has defined as places you can
>> insert raw markup. So, Org would define the =#+EXPORT= protocol,
>> specific back-ends would define the names and places.
>
> Not every back-end has a concept of "head" (think about Markdown
> back-end). We don't need a general concept for something that isn't
> general.

I haven't made myself clear. I'm not suggesting a general concept of
"head". What I am suggesting is that the back-ends handle these
back-end specific concepts themselves, rather than add more buffer
keywords for every new exporter. The general concept is that we want
to communicate document level information to the back-end, in this
case, bits of text to insert at specific places which are dependent on
the specific back-end in question.

> Also, completely unifying every back-end is close to impossible, unless
> the same person writes every back-end[1]. Most of the options are
> shared, that's the goal of ox.el, but in the end, each back-end decides
> how it handles the others.

This would not require unifying every back-end at all. In fact, quite
the opposite. All you would need would be for the generic exporter
framework to provide the back-end a dictionary of key value pairs,
such as ((:head "<script.../>") ...), which the back-end would
interpret. You would avoid having to add document level keywords such
as HTML_STYLE and MAN_CLASS_OPTIONS for new exporters. It would be the
back-end's responsibility to validate and document these options. My
suggestion is really not so different from what the new exporter does
anyway. Where we now have =#+HTML_LINK_UP: "..."=, I'm suggesting we
have =#+EXPORT: html link-up "..."=.

Perhaps I'm just expressing a preference for fewer buffer-level
keywords - feel free to ignore the suggestion.

Regards,
Sean

Re: [ANN] Merge of new export framework on Wednesday

[Nicolas Goaziou]

"Sean O'Halpin" <sean.ohalpin@gmail.com> writes:

> I haven't made myself clear. I'm not suggesting a general concept of
> "head". What I am suggesting is that the back-ends handle these
> back-end specific concepts themselves, rather than add more buffer
> keywords for every new exporter.

Each back-end adds its own keywords, define them, document them and
interpret them. So, basically, backends handle these concept themselves,
don't they?

> This would not require unifying every back-end at all. In fact, quite
> the opposite. All you would need would be for the generic exporter
> framework to provide the back-end a dictionary of key value pairs,
> such as ((:head "<script.../>") ...), which the back-end would
> interpret.

This is exactly what is happening.

> You would avoid having to add document level keywords such as
> HTML_STYLE and MAN_CLASS_OPTIONS for new exporters. It would be the
> back-end's responsibility to validate and document these options. My
> suggestion is really not so different from what the new exporter does
> anyway. Where we now have =#+HTML_LINK_UP: "..."=, I'm suggesting we
> have =#+EXPORT: html link-up "..."=.

Honestly, besides the syntax, I don't see any difference.


Regards,

-- 
Nicolas Goaziou

Re: [ANN] Merge of new export framework on Wednesday

[Nicolas Richard]

Nicolas Goaziou <n.goaziou@gmail.com> writes:
> "Sean O'Halpin" <sean.ohalpin@gmail.com> writes:
>> You would avoid having to add document level keywords such as
>> HTML_STYLE and MAN_CLASS_OPTIONS for new exporters. It would be the
>> back-end's responsibility to validate and document these options. My
>> suggestion is really not so different from what the new exporter does
>> anyway. Where we now have =#+HTML_LINK_UP: "..."=, I'm suggesting we
>> have =#+EXPORT: html link-up "..."=.
>
> Honestly, besides the syntax, I don't see any difference.

IIUC, the difference is that #+HTML_LINK_UP and friends are all direct
children of the document in the former case, and in the latter case all
exporter-related options are grouped. An intermediate solution would be
to group all options specific to one backend in #+EXPORT_<backend> (and
in this case, there could be a generic #+EXPORT: that could be used by
every backend). OTOH, most #+keywords statements are meant for the
exporter (there are exceptions) anyway, so this might sound like
premature or over-generalization.

I didn't read the whole thread and do not actually export very often so
might have completely missed the point.

-- 
Nico.

Re: [ANN] Merge of new export framework on Wednesday

[Bastien]

Hi Sean,

"Sean O'Halpin" <sean.ohalpin@gmail.com> writes:

> One small point: as we're going to have to change the meta directive
> "#+STYLE" to "#+HTML_STYLE", can we change the name to reflect what it
> really does in the HTML backend, i.e. insert text verbatim into the
> <head> element? I suggest we rename it to "#+HTML_HEAD".

Done.  You can now use HTML_HEAD instead of HTML_STYLE.

Some variables were also renamed, check the details here:
http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=2752ef

Best,

-- 
 Bastien

Re: [ANN] Merge of new export framework on Wednesday

[Sebastien Vauban]

Hi Bastien,

Bastien wrote:
> "Sean O'Halpin" <sean.ohalpin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>
>> One small point: as we're going to have to change the meta directive
>> "#+STYLE" to "#+HTML_STYLE", can we change the name to reflect what it
>> really does in the HTML backend, i.e. insert text verbatim into the
>> <head> element? I suggest we rename it to "#+HTML_HEAD".
>
> Done.  You can now use HTML_HEAD instead of HTML_STYLE.
>
> Some variables were also renamed, check the details here:
> http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=2752ef

Isn't it peculiar to rename STYLE into HEAD, in all affected vars but one?

- html-STYLE-include-default -> html-STYLE-include-default (unchanged)
- html-STYLE-include-scripts -> html-HEAD-include-scripts
- org-html-STYLE-include-default -> org-html-HEAD-include-default-STYLE
- org-html-STYLE-include-scripts -> org-html-HEAD-include-scripts

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [ANN] Merge of new export framework on Wednesday

[Bastien]

Hi Sébastien,

"Sebastien Vauban"
<wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:

> - html-STYLE-include-default -> html-STYLE-include-default
> (unchanged)

Fixed, thanks.

-- 
 Bastien

Re: [ANN] Merge of new export framework on Wednesday

[Sean O'Halpin]

On Sat, Mar 2, 2013 at 6:14 PM, Bastien <bzg@altern.org> wrote:
> Hi Sean,
>
> "Sean O'Halpin" <sean.ohalpin@gmail.com> writes:
>
>> One small point: as we're going to have to change the meta directive
>> "#+STYLE" to "#+HTML_STYLE", can we change the name to reflect what it
>> really does in the HTML backend, i.e. insert text verbatim into the
>> <head> element? I suggest we rename it to "#+HTML_HEAD".
>
> Done.  You can now use HTML_HEAD instead of HTML_STYLE.
>
> Some variables were also renamed, check the details here:
> http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=2752ef
>
> Best,
>
> --
>  Bastien

Thanks! It will now feel less hacky to use it for other <head> elements :)

Also, it's just struck me - wouldn't it be more consistent if
ATTR_HTML were HTML_ATTR, ATTR_LATEX were LATEX_ATTR, etc.? But I
suppose if you go down that route of everything export backend related
being prefixed with the export type, you'd really have to change
BEGIN_HTML to HTML_BEGIN, etc. Perhaps going too far...

Regards,
Sean

Re: [ANN] Merge of new export framework on Wednesday

[Bastien]

Hi Sean,

"Sean O'Halpin" <sean.ohalpin@gmail.com> writes:

> Also, it's just struck me - wouldn't it be more consistent if
> ATTR_HTML were HTML_ATTR, ATTR_LATEX were LATEX_ATTR, etc.?

I don't really think so -- ATTR_HTML is more like BEGIN_HTML than
#+HTML_HEAD, which is a global option, not a local setting or an
environment... and we can't break all .org files like this :)

-- 
 Bastien

Re: [ANN] Merge of new export framework on Wednesday

[Rick Frankel]

Bastien-

On Sat, Mar 02, 2013 at 07:14:07PM +0100, Bastien wrote:
> Done.  You can now use HTML_HEAD instead of HTML_STYLE.
> 
> Some variables were also renamed, check the details here:
> http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=2752ef

In trying to migrate these changes to the slide exporters, i noticed
some confusion w/ the migration of html-style vs. html-style-extra:

-   (:html-style nil nil org-html-style)
-   (:html-style-extra "HTML_STYLE" nil org-html-style-extra newline)
-   (:html-style-include-default nil nil org-html-style-include-default)
-   (:html-style-include-scripts nil nil org-html-style-include-scripts)
+   (:html-head "HTML_HEAD" nil org-html-head newline)
+   (:html-style-include-default nil nil org-html-head-include-default-style)
+   (:html-head-include-scripts nil nil org-html-head-include-scripts)
...
-		    exp-plist :html-style-extra
-		    (concat (or (plist-get exp-plist :html-style-extra) "")
+		    exp-plist :html-head-extra
+		    (concat (or (plist-get exp-plist :html-head-extra) "")
 			    "\n"
 			    style)))))
Specifically,

        - :html-style was renamed to :html-head (ok), but the
        in-buffer property HTML_HEAD was added to this export
        property.

        - :html-style-extra was (which was associated w/t the
        in-buffer property HTML_STYLE) was removed from the export
        prop list (but is referenced later in the code.
        - `org-html-head-extra' is mentioned in a doc string but never
        defined.

I think this is a bug/typo. Wouldn't the following be closer to a
straight renaming:

         (:html-head nil nil org-html-head newline)
         (:html-head-extra HTML_HEAD nil org-html-head-extra newline)

or should {org-,:}html-head-extra be dropped entirely?

Also, shouldn't :html-style-include-default be
:html-head-include-default?

rick

Re: [ANN] Merge of new export framework on Wednesday

[Bastien]

Hi Rick,

please check against the latest ox-html.el, I updated it yesterday
with some modifications in this area, fixing typos and reintroducing
`org-html-head-extra'.

(I'm in a rush right now and need to leave.)

Thanks in advance,

-- 
 Bastien

Re: [ANN] Merge of new export framework on Wednesday

[T.F. Torrey]

Hello,

Rick Frankel <rick@rickster.com> writes:

> Also, shouldn't :html-style-include-default be
> :html-head-include-default?

The variable and this property should stay html-style-include-default,
or at worst become html-head-include-default-style.

The intent of changing things from "html-style..." to "html-head..." was
to make it clear that the use is for anything in the head, not merely
style.

It is still appropriate for variables that actually refer to style to
have the word "style" in them.

IMHO,
Terry
-- 
T.F. Torrey

Re: [ANN] Merge of new export framework on Wednesday

[Mike McLean]

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

On Saturday, March 2, 2013, Bastien wrote:

> Hi Sean,
>
> "Sean O'Halpin" <sean.ohalpin@gmail.com <javascript:;>> writes:
>
> > One small point: as we're going to have to change the meta directive
> > "#+STYLE" to "#+HTML_STYLE", can we change the name to reflect what it
> > really does in the HTML backend, i.e. insert text verbatim into the
> > <head> element? I suggest we rename it to "#+HTML_HEAD".
>
> Done.  You can now use HTML_HEAD instead of HTML_STYLE.
>
> Some variables were also renamed, check the details here:
> http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=2752ef
>

I am on commit 40fc98e so I think I have all of the fixes to this change.

I noticed that it no longer concatenates multiple lines from the file
header. I used to have multiple #+HTML_STYLE: lines in my Org files that
layered in different CSS. The nice thing about designing my CSS this way is
that I have a base style and could change individual documents as needed by
just adding a new HTML_STYLE line that loads a small, simple override CSS.
I would get one <link style sheet /> line to match each HTML_STYLE line.
Now it appears that only the last line is exported to the HTML file.

[-- Attachment #2: Type: text/html, Size: 1665 bytes --]

Re: [ANN] Merge of new export framework on Wednesday

[Nicolas Goaziou]

Hello,

Mike McLean <mike.mclean@pobox.com> writes:

> I noticed that it no longer concatenates multiple lines from the file
> header. I used to have multiple #+HTML_STYLE: lines in my Org files that
> layered in different CSS. The nice thing about designing my CSS this way is
> that I have a base style and could change individual documents as needed by
> just adding a new HTML_STYLE line that loads a small, simple override CSS.
> I would get one <link style sheet /> line to match each HTML_STYLE line.
> Now it appears that only the last line is exported to the HTML file.

This should be fixed.

Thank you for reporting it.


Regards,

-- 
Nicolas Goaziou

Re: [ANN] Merge of new export framework on Wednesday

[Mike McLean]

[-- Attachment #1.1: Type: text/plain, Size: 1386 bytes --]

On Mon, Mar 4, 2013 at 10:24 AM, Nicolas Goaziou <n.goaziou@gmail.com>wrote:

> Hello,
>
> Mike McLean <mike.mclean@pobox.com> writes:
>
> > I noticed that it no longer concatenates multiple lines from the file
> > header. I used to have multiple #+HTML_STYLE: lines in my Org files that
> > layered in different CSS. The nice thing about designing my CSS this way
> is
> > that I have a base style and could change individual documents as needed
> by
> > just adding a new HTML_STYLE line that loads a small, simple override
> CSS.
> > I would get one <link style sheet /> line to match each HTML_STYLE line.
> > Now it appears that only the last line is exported to the HTML file.
>
> This should be fixed.
>

It doesn't seem to be. I have put together a ECM. I have two CSS files,
representing a “base” style and an optional “override” style. I have two
versions of an org test file that differ only in the first 2 lines of the
file. One “works” (loads both style sheets and displays the text as
described in the document), one does not.

This is a minimal ECM. In my actual setup I have the equivalent of the base
CSS file in a file named ~org-options.txt~ that I include into every single
Org file I ever create via ~#+SETUPFILE"~. I load my override CSS on a
per-document basis in the document header below the ~#+SETUPFILE:~
directive.

[-- Attachment #1.2: Type: text/html, Size: 1806 bytes --]

[-- Attachment #2: test-org-export-base-style.css --]
[-- Type: text/css, Size: 71 bytes --]

a, h1, h2, h3, h4, h5, h6 {
	  color: red;
    margin-bottom: 0.5em;
}

[-- Attachment #3: test-org-export-not-works.org --]
[-- Type: application/octet-stream, Size: 2100 bytes --]

#+HTML_HEAD_EXTRA: <link rel="stylesheet" type="text/css" href="test-org-export-base-style.css" />
#+HTML_HEAD_EXTRA: <link rel="stylesheet" type="text/css" href="test-org-export-override-style.css" />


* Hello this H1 Should display in red
The exporter should include file ~test-org-export-base-style.css~ from the first
~#+HTML_HEAD_EXTRA:~. In fact if this test file includes only that line, the  exporter
works correctly and the ~H1~ displays in red.

This text should display in blue because the second style sheet includes a definition for
HTML paragraphs. The block quote blow should display nicely formatted on the right from
the second style sheet also.

#+begin_html
  <blockquote>
    <i>
      &ldquo;Security is mostly a superstition. It does not
      exist in nature, nor do the children of men as a whole experience
      it. Avoiding danger is no safer in the long run than outright
      exposure. Life is either a daring adventure, or nothing. To keep our
      faces toward change and behave like free spirits in the presence of
      fate is strength undefeatable.&rdquo;
    </i>
    <br />
    <b>
      Helen Keller
    </b>
  </blockquote>
#+end_html

* Notes
** Works
If I combine the ~html_head_extra~ lines like below, I get the desired result.

#+begin_example
#+HTML_HEAD_EXTRA: <link rel="stylesheet" type="text/css" href="test-org-export-base-style.css" /> <link rel="stylesheet" type="text/css" href="test-org-export-override-style.css" />
#+end_example
** Doesn't Work
If I have the ~html_head_extra~ on two lines like below, I get just a ~<link
rel="stylesheet" type="text/css" href="test-org-export-base-style.css">~ line in the
output. I don't get an include for the ~test-org-export-override-style.css~ style sheet
and therefore the HTML text display in default black and the ~<blockquote>~ does not
display neatly on the right.
#+begin_example
#+HTML_HEAD_EXTRA: <link rel="stylesheet" type="text/css" href="test-org-export-base-style.css" />
#+HTML_HEAD_EXTRA: <link rel="stylesheet" type="text/css" href="test-org-export-override-style.css" />
#+end_example

[-- Attachment #4: test-org-export-override-style.css --]
[-- Type: text/css, Size: 314 bytes --]

/*
 * CSS Overrides for documents that should display in blue and have blockquotes
 */

p {
    color: blue;
}

blockquote {
    float:right;
    width:160px;
    font-size:90%;
    margin:0 0 0 10px;
    padding:15px;
    font-family:Georgia, "Times New Roman", Times, serif;
    border-left:solid 3px #DEDEDE;
}

[-- Attachment #5: test-org-export-works.org --]
[-- Type: application/octet-stream, Size: 2081 bytes --]

#+HTML_HEAD_EXTRA: <link rel="stylesheet" type="text/css" href="test-org-export-base-style.css" /> <link rel="stylesheet" type="text/css" href="test-org-export-override-style.css" />


* Hello this H1 Should display in red
The exporter should include file ~test-org-export-base-style.css~ from the first
~#+HTML_HEAD_EXTRA:~. In fact if this test file includes only that line, the  exporter
works correctly and the ~H1~ displays in red.

This text should display in blue because the second style sheet includes a definition for
HTML paragraphs. The block quote blow should display nicely formatted on the right from
the second style sheet also.

#+begin_html
  <blockquote>
    <i>
      &ldquo;Security is mostly a superstition. It does not
      exist in nature, nor do the children of men as a whole experience
      it. Avoiding danger is no safer in the long run than outright
      exposure. Life is either a daring adventure, or nothing. To keep our
      faces toward change and behave like free spirits in the presence of
      fate is strength undefeatable.&rdquo;
    </i>
    <br />
    <b>
      Helen Keller
    </b>
  </blockquote>
#+end_html

* Notes
** Works
If I combine the ~html_head_extra~ lines like below, I get the desired result.

#+begin_example
#+HTML_HEAD_EXTRA: <link rel="stylesheet" type="text/css" href="test-org-export-base-style.css" /> <link rel="stylesheet" type="text/css" href="test-org-export-override-style.css" />
#+end_example
** Doesn't Work
If I have the ~html_head_extra~ on two lines like below, I get just a ~<link
rel="stylesheet" type="text/css" href="test-org-export-base-style.css">~ line in the
output. I don't get an include for the ~test-org-export-override-style.css~ style sheet
and therefore the HTML text display in default black and the ~<blockquote>~ does not
display neatly on the right.
#+begin_example
#+HTML_HEAD_EXTRA: <link rel="stylesheet" type="text/css" href="test-org-export-base-style.css" />
#+HTML_HEAD_EXTRA: <link rel="stylesheet" type="text/css" href="test-org-export-override-style.css" />
#+end_example

Re: [ANN] Merge of new export framework on Wednesday

[Nicolas Goaziou]

Mike McLean <mike.mclean@pobox.com> writes:

> On Mon, Mar 4, 2013 at 10:24 AM, Nicolas Goaziou <n.goaziou@gmail.com>wrote:
>
>> Hello,
>>
>> Mike McLean <mike.mclean@pobox.com> writes:
>>
>> > I noticed that it no longer concatenates multiple lines from the file
>> > header. I used to have multiple #+HTML_STYLE: lines in my Org files that
>> > layered in different CSS. The nice thing about designing my CSS this way
>> is
>> > that I have a base style and could change individual documents as needed
>> by
>> > just adding a new HTML_STYLE line that loads a small, simple override
>> CSS.
>> > I would get one <link style sheet /> line to match each HTML_STYLE line.
>> > Now it appears that only the last line is exported to the HTML file.
>>
>> This should be fixed.
>>
>
> It doesn't seem to be.

Indeed. I overlooked some code typo. Could you try again (a restart may
be required)?

Thank you.


Regards,

-- 
Nicolas Goaziou

Re: [ANN] Merge of new export framework on Wednesday

[Mike McLean]

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

On Monday, March 4, 2013, Nicolas Goaziou wrote:

> Mike McLean <mike.mclean@pobox.com <javascript:;>> writes:
>
> > On Mon, Mar 4, 2013 at 10:24 AM, Nicolas Goaziou <n.goaziou@gmail.com<javascript:;>
> >wrote:
> >
> >> Hello,
> >>
> >> Mike McLean <mike.mclean@pobox.com <javascript:;>> writes:
> >>
> >> > I noticed that it no longer concatenates multiple lines from the file
> >> > header. I used to have multiple #+HTML_STYLE: lines in my Org files
> that
> >> > layered in different CSS. The nice thing about designing my CSS this
> way
> >> is
> >> > that I have a base style and could change individual documents as
> needed
> >> by
> >> > just adding a new HTML_STYLE line that loads a small, simple override
> >> CSS.
> >> > I would get one <link style sheet /> line to match each HTML_STYLE
> line.
> >> > Now it appears that only the last line is exported to the HTML file.
> >>
> >> This should be fixed.
> >>
> >
> > It doesn't seem to be.
>
> Indeed. I overlooked some code typo. Could you try again (a restart may
> be required)?


That did it. Thank you. Overall I'm loving the new exporter, BTW. Awesome
job!!!

[-- Attachment #2: Type: text/html, Size: 1766 bytes --]

Re: [ANN] Merge of new export framework on Wednesday

[Suvayu Ali]

Hi Bastien,

On Sat, Mar 02, 2013 at 07:14:07PM +0100, Bastien wrote:
> Hi Sean,
> 
> "Sean O'Halpin" <sean.ohalpin@gmail.com> writes:
> 
> > One small point: as we're going to have to change the meta directive
> > "#+STYLE" to "#+HTML_STYLE", can we change the name to reflect what it
> > really does in the HTML backend, i.e. insert text verbatim into the
> > <head> element? I suggest we rename it to "#+HTML_HEAD".
> 
> Done.  You can now use HTML_HEAD instead of HTML_STYLE.
> 
> Some variables were also renamed, check the details here:
> http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=2752ef
> 

It seems to me a few files in contrib needs to be updated, and also the
manual of course.

$ git grep -i html_style
contrib/lisp/ox-deck.el:   (:html-style-extra "HTML_STYLE" nil org-html-style-extra newline)
contrib/lisp/ox-s5.el:   (:html-style-extra "HTML_STYLE" nil org-html-style-extra newline)
doc/org.texi:@cindex #+HTML_STYLE
doc/org.texi:#+HTML_STYLE: <link rel="stylesheet" type="text/css" href="stylesheet.css" />
doc/org.texi:@itemx #+LaTeX_HEADER:, #+HTML_STYLE:, #+HTML_LINK_UP:, #+HTML_LINK_HOME:,

I updated the FAQ entry on Worg for new exporter switch.

<http://orgmode.org/cgit.cgi/worg.git/commit/?id=b137e931edd6cddfdcf4df40d29e93f01ad59242>

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Re: [ANN] Merge of new export framework on Wednesday

[Bastien]

Hi Suvayu,

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

> $ git grep -i html_style
> contrib/lisp/ox-deck.el:   (:html-style-extra "HTML_STYLE" nil org-html-style-extra newline)
> contrib/lisp/ox-s5.el:   (:html-style-extra "HTML_STYLE" nil org-html-style-extra newline)
> doc/org.texi:@cindex #+HTML_STYLE
> doc/org.texi:#+HTML_STYLE: <link rel="stylesheet" type="text/css" href="stylesheet.css" />
> doc/org.texi:@itemx #+LaTeX_HEADER:, #+HTML_STYLE:, #+HTML_LINK_UP:, #+HTML_LINK_HOME:,

Fixed, thanks!  

And thanks for fixing this in Worg, that helps a lot.

Best,

-- 
 Bastien

Re: [ANN] Merge of new export framework on Wednesday

[Achim Gratz]

Nicolas Goaziou writes:
[…]

Nicolas, moving the old exporter files to contrib/lisp/ will create
problems for the org-plus-contrib ELPA archive.  Can I move them to
contrib/oldexp/ instead?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [ANN] Merge of new export framework on Wednesday

[Nicolas Goaziou]

Hello,

Achim Gratz <Stromeko@nexgo.de> writes:

> Nicolas Goaziou writes:
> […]
>
> Nicolas, moving the old exporter files to contrib/lisp/ will create
> problems for the org-plus-contrib ELPA archive.  Can I move them to
> contrib/oldexp/ instead?

As far as I am concerned, you can. Bastien (CC'ed) might have another
plan for these files, though.


Regards,

-- 
Nicolas Goaziou

Re: [ANN] Merge of new export framework on Wednesday

[Bastien]

Achim Gratz <Stromeko@nexgo.de> writes:

> Nicolas, moving the old exporter files to contrib/lisp/ will create
> problems for the org-plus-contrib ELPA archive.  Can I move them to
> contrib/oldexp/ instead?

Yes, please go ahead.

Thanks,

-- 
 Bastien

Re: [ANN] Merge of new export framework on Wednesday

[Achim Gratz]

Bastien writes:
>> Nicolas, moving the old exporter files to contrib/lisp/ will create
>> problems for the org-plus-contrib ELPA archive.  Can I move them to
>> contrib/oldexp/ instead?
>
> Yes, please go ahead.

Done, please check that I didn't miss any file.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [ANN] Merge of new export framework on Wednesday

[Nicolas Goaziou]

Achim Gratz <Stromeko@nexgo.de> writes:

> Done, please check that I didn't miss any file.

org2rem.el and org-export-generic.el both require org-exp.el. Shouldn't
they go into oldexp, too?


Regards,

-- 
Nicolas Goaziou

Re: [ANN] Merge of new export framework on Wednesday

[Bastien]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Achim Gratz <Stromeko@nexgo.de> writes:
>
>> Done, please check that I didn't miss any file.
>
> org2rem.el and org-export-generic.el both require org-exp.el. Shouldn't
> they go into oldexp, too?

Indeed, done.

-- 
 Bastien

Re: [ANN] Merge of new export framework on Wednesday

[Jambunathan K]

Achim Gratz <Stromeko@nexgo.de> writes:

> Nicolas Goaziou writes:
> […]
>
> Nicolas, moving the old exporter files to contrib/lisp/ will create
> problems for the org-plus-contrib ELPA archive.  Can I move them to
> contrib/oldexp/ instead?

I recommend contrib/obsolete/ or contrib/attic/.

>
>
> Regards,
> Achim.

-- 

Re: compilation issues of new export framework

[Achim Gratz]

Hi Nicolas,

an oddity occurs since the new exporter moved into core (I don't think I
had seen this before, so maybe you can relate to what is different now):

--8<---------------cut here---------------start------------->8---
Compiling /lisp/org-mode/lisp/org.el...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
Loading org-element...
--8<---------------cut here---------------end--------------->8---

This only happens when using byte-recompile-directory, which means
org-element has already been loaded in that session and is present as a
byte-compiled file.  I haven't yet found where in org.el these loads are
triggered, but it seems that this might be related to macro expansion.
In any case, the resulting org.elc file therefore depends on the
compilation method, which is highly undesirable.  I haven't been able to
analyse this further.

Another sticky point is your use of declare-function: some of these are
actually defsubst, not defun:

org-element-{contents,nested-p,element-property,put-property}

I don't think they will be inlined unless their definition has been
interned, declaration alone will not suffice.  I don't see an easy way
to factor out those parts from org-element that are needed by org, but I
suggest that we should find one.


There are more errors when doing a "make ORGCM=slint2 compile" in the
last pass.  These files are probably all just missing an

(eval-when-compile (require 'cl))

but I only checked ox-md.

--8<---------------cut here---------------start------------->8---
Compiling single /lisp/org-mode/lisp/ox-beamer.el...
In end of data:
ox-beamer.el:1250:1:Warning: the following functions are not known to be
    defined: case, action, defaction, option, otherwise, headline, target
Wrote /lisp/org-mode/lisp/ox-beamer.elc
Compiling single /lisp/org-mode/lisp/ox-icalendar.el...

In org-icalendar-entry:
ox-icalendar.el:504:44:Warning: `(quote t)' is a malformed function
ox-icalendar.el:504:44:Warning: `(quote t)' is a malformed function
ox-icalendar.el:504:44:Warning: `(quote t)' is a malformed function

In end of data:
ox-icalendar.el:974:1:Warning: the following functions are not known to be
    defined: case, category, todo-state, local-tags, all-tags, incf, all,
    unblocked, hour, day, week, month, year
Wrote /lisp/org-mode/lisp/ox-icalendar.elc
Compiling single /lisp/org-mode/lisp/ox-jsinfo.el...

In end of data:
ox-jsinfo.el:261:1:Warning: the following functions are not known to be
    defined: case, path, sdepth, tdepth, otherwise
Compiling single /lisp/org-mode/lisp/ox-md.el...

In end of data:
ox-md.el:494:1:Warning: the following functions are not known to be defined:
    case, on, trans, off
--8<---------------cut here---------------end--------------->8---


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: compilation issues of new export framework

[Nicolas Goaziou]

Hello,

Achim Gratz <Stromeko@nexgo.de> writes:

> an oddity occurs since the new exporter moved into core (I don't think I
> had seen this before, so maybe you can relate to what is different now):
>
> Compiling /lisp/org-mode/lisp/org.el...
> Loading org-element...
> Loading org-element...
> Loading org-element...
> Loading org-element...
> Loading org-element...
> Loading org-element...
> Loading org-element...
> Loading org-element...
> Loading org-element...
> Loading org-element...
> Loading org-element...
> Loading org-element...
> Loading org-element...
> Loading org-element...
> Loading org-element...
> Loading org-element...
> Loading org-element...
> Loading org-element...
> Loading org-element...

Yes, I noticed this one too, but I don't know yet from where it could
come from.

> This only happens when using byte-recompile-directory, which means
> org-element has already been loaded in that session and is present as a
> byte-compiled file.  I haven't yet found where in org.el these loads are
> triggered, but it seems that this might be related to macro expansion.
> In any case, the resulting org.elc file therefore depends on the
> compilation method, which is highly undesirable.  I haven't been able to
> analyse this further.
>
> Another sticky point is your use of declare-function: some of these are
> actually defsubst, not defun:
>
> org-element-{contents,nested-p,element-property,put-property}
>
> I don't think they will be inlined unless their definition has been
> interned, declaration alone will not suffice.

I don't know either how inline functions behave in this situation.

> I don't see an easy way to factor out those parts from org-element
> that are needed by org, but I suggest that we should find one.

It is always possible to make them regular functions. Some profiling may
be necessary, though.

> There are more errors when doing a "make ORGCM=slint2 compile" in the
> last pass.  These files are probably all just missing an
>
> (eval-when-compile (require 'cl))
>
> but I only checked ox-md.

Indeed. Fixed. Thank you.


Regards,

-- 
Nicolas Goaziou

Re: compilation issues of new export framework

[Achim Gratz]

Nicolas Goaziou writes:
> Yes, I noticed this one too, but I don't know yet from where it could
> come from.

Hmm.  If you don't know, then this is even more worrysome.  Can't spend
more time on this now, unfortunately.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: compilation issues of new export framework

[Achim Gratz]

Nicolas Goaziou writes:
> Yes, I noticed this one too, but I don't know yet from where it could
> come from.

It comes from the two autoloads, or probably only the second one as the
first is later declare-function'ed anyway.  If you declare these, then
the defsubst get sometimes compiled as function calls and sometimes as
inlined functions (the normal mode of compilation inlines them).

--8<---------------cut here---------------start------------->8---
diff --git a/lisp/org.el b/lisp/org.el
index 2bfca4e..c679c5d 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -137,9 +137,6 @@ (defvar org-heading-regexp "^\\(\\*+\\)\\(?: +\\(.*?\\)\\)?[ \t]*$"
 (declare-function org-table-maybe-eval-formula "org-table" ())
 (declare-function org-table-maybe-recalculate-line "org-table" ())
 
-(autoload 'org-element-at-point "org-element")
-(autoload 'org-element-type "org-element")
-
 (declare-function org-element--parse-objects "org-element"
                  (beg end acc restriction))
 (declare-function org-element-at-point "org-element" (&optional keep-trail))
@@ -152,6 +149,7 @@ (defvar org-heading-regexp "^\\(\\*+\\)\\(?: +\\(.*?\\)\\)?[ \t]*$"
 (declare-function org-element-nested-p "org-element" (elem-a elem-b))
 (declare-function org-element-parse-buffer "org-element"
                  (&optional granularity visible-only))
+(declare-function org-element-type "org-element" (element))
 (declare-function org-element-property "org-element" (property element))
 (declare-function org-element-put-property "org-element"
                  (element property value))
--8<---------------cut here---------------end--------------->8---

If instead you really want them always replaced with the definition of
the defsubst (on the assumption that this is indeed faster than a
function call or permits better optimization by the bytecompiler), then
these would need to be moved to org.el and their declarations removed.
Alternatively the defsubsts could go into a separate file that is then
required from both org.el and org-element.el None of these options solve
the larger problem of the circular dependencies.


PS:
If compiled single, four Babel tests fail; three of them with an
"(invalid-function org-export-with-buffer-copy)".  The function it
complains about is actually a macro in ox.el that is used in
org-export-as before its definition.  Not cool, it must be moved before
org-export-as.  The tests then pass with a single-compiled version of
org.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: compilation issues of new export framework

[Nicolas Goaziou]

Achim Gratz <Stromeko@nexgo.de> writes:

> It comes from the two autoloads, or probably only the second one as the
> first is later declare-function'ed anyway.  If you declare these, then
> the defsubst get sometimes compiled as function calls and sometimes as
> inlined functions (the normal mode of compilation inlines them).

Strange, these autoloads were already there before the merge.

> If instead you really want them always replaced with the definition of
> the defsubst (on the assumption that this is indeed faster than a
> function call or permits better optimization by the bytecompiler), then
> these would need to be moved to org.el and their declarations removed.

Speed is the whole point, indeed. A quick profiling with and without
defsubst gives me:

| defsubst | org-element-parse-buffer | 10 | 16.252699 |    1.6252699 |
| defun    | org-element-parse-buffer | 10 | 19.812426 | 1.9812425999 |

It is about 20 % faster.

> Alternatively the defsubsts could go into a separate file that is then
> required from both org.el and org-element.el None of these options solve
> the larger problem of the circular dependencies.

Moving `org-element-type' and al. into org.el would be out of context.
We may be able to require org-element from the beginning of org.el, but
I think there's some serious work involved.

> PS:
> If compiled single, four Babel tests fail; three of them with an
> "(invalid-function org-export-with-buffer-copy)".  The function it
> complains about is actually a macro in ox.el that is used in
> org-export-as before its definition.  Not cool, it must be moved before
> org-export-as.  The tests then pass with a single-compiled version of
> org.

Fixed. Thank you.


Regards,

-- 
Nicolas Goaziou

Re: compilation issues of new export framework

[Nicolas Goaziou]

Completing myself,

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Speed is the whole point, indeed. A quick profiling with and without
> defsubst gives me:
>
> | defsubst | org-element-parse-buffer | 10 | 16.252699 |    1.6252699 |
> | defun    | org-element-parse-buffer | 10 | 19.812426 | 1.9812425999 |
>
> It is about 20 % faster.

On the other hand, `org-element-type' and al. from org.el are called
less often. So, it is not a problem if they are compiled as function
calls.

Eventually, I'd say that the situation is fine as it is.


Regards,

-- 
Nicolas Goaziou

Re: compilation issues of new export framework

[Achim Gratz]

Nicolas Goaziou <n.goaziou <at> gmail.com> writes:
> On the other hand, `org-element-type' and al. from org.el are called
> less often. So, it is not a problem if they are compiled as function
> calls.

They are normally not compiled as function calls, only in single mode.

Regarding commit 6b7101b91, did you intend to demote org-element-nested-p to a
defun or was this just a leftover from the earlier experiment?


Regards,
Achim

Re: compilation issues of new export framework

[Nicolas Goaziou]

Achim Gratz <Stromeko@NexGo.DE> writes:

> Nicolas Goaziou <n.goaziou <at> gmail.com> writes:
>> On the other hand, `org-element-type' and al. from org.el are called
>> less often. So, it is not a problem if they are compiled as function
>> calls.
>
> They are normally not compiled as function calls, only in single mode.
>
> Regarding commit 6b7101b91, did you intend to demote org-element-nested-p to a
> defun or was this just a leftover from the earlier experiment?

I found that inlining it was an overkill. So the change is intentional.


Regards,

-- 
Nicolas Goaziou

Re: compilation issues of new export framework

[Achim Gratz]

Nicolas Goaziou writes:
> I found that inlining it was an overkill. So the change is intentional.

Thanks for the confirmation.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada