* [ANN] Merge of new export framework on Wednesday
@ 2013-02-03 19:00 Nicolas Goaziou
2013-02-03 20:59 ` François Allisson
` (6 more replies)
0 siblings, 7 replies; 58+ messages in thread
From: Nicolas Goaziou @ 2013-02-03 19:00 UTC (permalink / raw)
To: Org Mode List
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-02-03 19:00 [ANN] Merge of new export framework on Wednesday Nicolas Goaziou
@ 2013-02-03 20:59 ` François Allisson
2013-02-04 9:17 ` Detlef Steuer
` (5 subsequent siblings)
6 siblings, 0 replies; 58+ messages in thread
From: François Allisson @ 2013-02-03 20:59 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Org Mode List
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-02-03 19:00 [ANN] Merge of new export framework on Wednesday Nicolas Goaziou
2013-02-03 20:59 ` François Allisson
@ 2013-02-04 9:17 ` Detlef Steuer
2013-02-04 13:49 ` David Bjergaard
2013-02-04 23:05 ` Bastien
2013-02-04 13:35 ` Rasmus
` (4 subsequent siblings)
6 siblings, 2 replies; 58+ messages in thread
From: Detlef Steuer @ 2013-02-04 9:17 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-02-03 19:00 [ANN] Merge of new export framework on Wednesday Nicolas Goaziou
2013-02-03 20:59 ` François Allisson
2013-02-04 9:17 ` Detlef Steuer
@ 2013-02-04 13:35 ` Rasmus
2013-02-05 16:30 ` org export Taskjuggler (was: Re: [ANN] Merge of new export framework on Wednesday - ) Giovanni Ridolfi
` (3 subsequent siblings)
6 siblings, 0 replies; 58+ messages in thread
From: Rasmus @ 2013-02-04 13:35 UTC (permalink / raw)
To: emacs-orgmode
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!
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-02-04 9:17 ` Detlef Steuer
@ 2013-02-04 13:49 ` David Bjergaard
2013-02-04 21:56 ` Suvayu Ali
2013-02-04 23:05 ` Bastien
1 sibling, 1 reply; 58+ messages in thread
From: David Bjergaard @ 2013-02-04 13:49 UTC (permalink / raw)
To: Detlef Steuer; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-02-04 13:49 ` David Bjergaard
@ 2013-02-04 21:56 ` Suvayu Ali
2013-02-05 1:07 ` Eric S Fraga
0 siblings, 1 reply; 58+ messages in thread
From: Suvayu Ali @ 2013-02-04 21:56 UTC (permalink / raw)
To: emacs-orgmode
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.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-02-04 9:17 ` Detlef Steuer
2013-02-04 13:49 ` David Bjergaard
@ 2013-02-04 23:05 ` Bastien
1 sibling, 0 replies; 58+ messages in thread
From: Bastien @ 2013-02-04 23:05 UTC (permalink / raw)
To: Detlef Steuer; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-02-04 21:56 ` Suvayu Ali
@ 2013-02-05 1:07 ` Eric S Fraga
2013-02-05 7:41 ` Suvayu Ali
0 siblings, 1 reply; 58+ messages in thread
From: Eric S Fraga @ 2013-02-05 1:07 UTC (permalink / raw)
To: Suvayu Ali; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-02-05 1:07 ` Eric S Fraga
@ 2013-02-05 7:41 ` Suvayu Ali
2013-02-05 9:25 ` Eric S Fraga
0 siblings, 1 reply; 58+ messages in thread
From: Suvayu Ali @ 2013-02-05 7:41 UTC (permalink / raw)
To: emacs-orgmode
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.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-02-05 7:41 ` Suvayu Ali
@ 2013-02-05 9:25 ` Eric S Fraga
2013-02-05 11:18 ` Suvayu Ali
0 siblings, 1 reply; 58+ messages in thread
From: Eric S Fraga @ 2013-02-05 9:25 UTC (permalink / raw)
To: Suvayu Ali; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-02-05 9:25 ` Eric S Fraga
@ 2013-02-05 11:18 ` Suvayu Ali
2013-02-05 12:50 ` Eric S Fraga
0 siblings, 1 reply; 58+ messages in thread
From: Suvayu Ali @ 2013-02-05 11:18 UTC (permalink / raw)
To: emacs-orgmode
[-- 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
^ permalink raw reply related [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-02-05 11:18 ` Suvayu Ali
@ 2013-02-05 12:50 ` Eric S Fraga
2013-02-05 13:07 ` Suvayu Ali
0 siblings, 1 reply; 58+ messages in thread
From: Eric S Fraga @ 2013-02-05 12:50 UTC (permalink / raw)
To: Suvayu Ali; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-02-05 12:50 ` Eric S Fraga
@ 2013-02-05 13:07 ` Suvayu Ali
2013-03-04 15:20 ` Suvayu Ali
0 siblings, 1 reply; 58+ messages in thread
From: Suvayu Ali @ 2013-02-05 13:07 UTC (permalink / raw)
To: emacs-orgmode
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.
^ permalink raw reply [flat|nested] 58+ messages in thread
* org export Taskjuggler (was: Re: [ANN] Merge of new export framework on Wednesday - )
2013-02-03 19:00 [ANN] Merge of new export framework on Wednesday Nicolas Goaziou
` (2 preceding siblings ...)
2013-02-04 13:35 ` Rasmus
@ 2013-02-05 16:30 ` Giovanni Ridolfi
2013-02-05 17:59 ` org export Taskjuggler Nicolas Goaziou
2013-02-07 0:14 ` [ANN] Merge of new export framework on Wednesday Jay Kerns
` (2 subsequent siblings)
6 siblings, 1 reply; 58+ messages in thread
From: Giovanni Ridolfi @ 2013-02-05 16:30 UTC (permalink / raw)
To: Nicolas Goaziou, Org Mode List; +Cc: Christian Egli, Yann Hodique
----- 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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: org export Taskjuggler
2013-02-05 16:30 ` org export Taskjuggler (was: Re: [ANN] Merge of new export framework on Wednesday - ) Giovanni Ridolfi
@ 2013-02-05 17:59 ` Nicolas Goaziou
2013-02-07 10:21 ` Christian Egli
0 siblings, 1 reply; 58+ messages in thread
From: Nicolas Goaziou @ 2013-02-05 17:59 UTC (permalink / raw)
To: Giovanni Ridolfi; +Cc: Christian Egli, Yann Hodique, Org Mode List
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-02-03 19:00 [ANN] Merge of new export framework on Wednesday Nicolas Goaziou
` (3 preceding siblings ...)
2013-02-05 16:30 ` org export Taskjuggler (was: Re: [ANN] Merge of new export framework on Wednesday - ) Giovanni Ridolfi
@ 2013-02-07 0:14 ` Jay Kerns
2013-02-08 15:53 ` Sean O'Halpin
2013-02-09 8:03 ` Achim Gratz
6 siblings, 0 replies; 58+ messages in thread
From: Jay Kerns @ 2013-02-07 0:14 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Org Mode List
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
> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: org export Taskjuggler
2013-02-05 17:59 ` org export Taskjuggler Nicolas Goaziou
@ 2013-02-07 10:21 ` Christian Egli
2013-02-07 10:43 ` Jambunathan K
2013-02-07 13:13 ` Nicolas Goaziou
0 siblings, 2 replies; 58+ messages in thread
From: Christian Egli @ 2013-02-07 10:21 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Yann Hodique, Org Mode List
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: org export Taskjuggler
2013-02-07 10:21 ` Christian Egli
@ 2013-02-07 10:43 ` Jambunathan K
2013-02-07 13:13 ` Nicolas Goaziou
1 sibling, 0 replies; 58+ messages in thread
From: Jambunathan K @ 2013-02-07 10:43 UTC (permalink / raw)
To: Christian Egli; +Cc: Yann Hodique, Org Mode List, Nicolas Goaziou
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
--
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: org export Taskjuggler
2013-02-07 10:21 ` Christian Egli
2013-02-07 10:43 ` Jambunathan K
@ 2013-02-07 13:13 ` Nicolas Goaziou
1 sibling, 0 replies; 58+ messages in thread
From: Nicolas Goaziou @ 2013-02-07 13:13 UTC (permalink / raw)
To: Christian Egli; +Cc: Org Mode List, Yann Hodique
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-02-03 19:00 [ANN] Merge of new export framework on Wednesday Nicolas Goaziou
` (4 preceding siblings ...)
2013-02-07 0:14 ` [ANN] Merge of new export framework on Wednesday Jay Kerns
@ 2013-02-08 15:53 ` Sean O'Halpin
2013-02-08 16:45 ` Sebastien Vauban
2013-03-02 18:14 ` Bastien
2013-02-09 8:03 ` Achim Gratz
6 siblings, 2 replies; 58+ messages in thread
From: Sean O'Halpin @ 2013-02-08 15:53 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Org Mode List
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-02-08 15:53 ` Sean O'Halpin
@ 2013-02-08 16:45 ` Sebastien Vauban
2013-02-09 13:20 ` Sean O'Halpin
2013-03-02 18:14 ` Bastien
1 sibling, 1 reply; 58+ messages in thread
From: Sebastien Vauban @ 2013-02-08 16:45 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-02-03 19:00 [ANN] Merge of new export framework on Wednesday Nicolas Goaziou
` (5 preceding siblings ...)
2013-02-08 15:53 ` Sean O'Halpin
@ 2013-02-09 8:03 ` Achim Gratz
2013-02-09 8:21 ` Nicolas Goaziou
` (3 more replies)
6 siblings, 4 replies; 58+ messages in thread
From: Achim Gratz @ 2013-02-09 8:03 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-02-09 8:03 ` Achim Gratz
@ 2013-02-09 8:21 ` Nicolas Goaziou
2013-02-09 9:26 ` Bastien
` (2 subsequent siblings)
3 siblings, 0 replies; 58+ messages in thread
From: Nicolas Goaziou @ 2013-02-09 8:21 UTC (permalink / raw)
To: Achim Gratz; +Cc: Bastien Guerry, emacs-orgmode
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-02-09 8:03 ` Achim Gratz
2013-02-09 8:21 ` Nicolas Goaziou
@ 2013-02-09 9:26 ` Bastien
2013-02-09 10:33 ` Achim Gratz
2013-02-09 15:01 ` Jambunathan K
2013-02-09 17:16 ` compilation issues of new export framework Achim Gratz
3 siblings, 1 reply; 58+ messages in thread
From: Bastien @ 2013-02-09 9:26 UTC (permalink / raw)
To: Achim Gratz; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-02-09 9:26 ` Bastien
@ 2013-02-09 10:33 ` Achim Gratz
2013-02-09 10:44 ` Nicolas Goaziou
0 siblings, 1 reply; 58+ messages in thread
From: Achim Gratz @ 2013-02-09 10:33 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-02-09 10:33 ` Achim Gratz
@ 2013-02-09 10:44 ` Nicolas Goaziou
2013-02-09 10:49 ` Bastien
0 siblings, 1 reply; 58+ messages in thread
From: Nicolas Goaziou @ 2013-02-09 10:44 UTC (permalink / raw)
To: Achim Gratz; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-02-09 10:44 ` Nicolas Goaziou
@ 2013-02-09 10:49 ` Bastien
0 siblings, 0 replies; 58+ messages in thread
From: Bastien @ 2013-02-09 10:49 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Achim Gratz, emacs-orgmode
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-02-08 16:45 ` Sebastien Vauban
@ 2013-02-09 13:20 ` Sean O'Halpin
2013-02-09 13:56 ` Nicolas Goaziou
0 siblings, 1 reply; 58+ messages in thread
From: Sean O'Halpin @ 2013-02-09 13:20 UTC (permalink / raw)
To: Sebastien Vauban; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-02-09 13:20 ` Sean O'Halpin
@ 2013-02-09 13:56 ` Nicolas Goaziou
2013-02-09 18:14 ` Sean O'Halpin
0 siblings, 1 reply; 58+ messages in thread
From: Nicolas Goaziou @ 2013-02-09 13:56 UTC (permalink / raw)
To: Sean O'Halpin; +Cc: Sebastien Vauban, emacs-orgmode
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-02-09 8:03 ` Achim Gratz
2013-02-09 8:21 ` Nicolas Goaziou
2013-02-09 9:26 ` Bastien
@ 2013-02-09 15:01 ` Jambunathan K
2013-02-09 17:16 ` compilation issues of new export framework Achim Gratz
3 siblings, 0 replies; 58+ messages in thread
From: Jambunathan K @ 2013-02-09 15:01 UTC (permalink / raw)
To: Achim Gratz; +Cc: emacs-orgmode
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.
--
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: compilation issues of new export framework
2013-02-09 8:03 ` Achim Gratz
` (2 preceding siblings ...)
2013-02-09 15:01 ` Jambunathan K
@ 2013-02-09 17:16 ` Achim Gratz
2013-02-09 17:50 ` Nicolas Goaziou
3 siblings, 1 reply; 58+ messages in thread
From: Achim Gratz @ 2013-02-09 17:16 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: compilation issues of new export framework
2013-02-09 17:16 ` compilation issues of new export framework Achim Gratz
@ 2013-02-09 17:50 ` Nicolas Goaziou
2013-02-09 18:02 ` Achim Gratz
2013-02-10 10:44 ` Achim Gratz
0 siblings, 2 replies; 58+ messages in thread
From: Nicolas Goaziou @ 2013-02-09 17:50 UTC (permalink / raw)
To: Achim Gratz; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: compilation issues of new export framework
2013-02-09 17:50 ` Nicolas Goaziou
@ 2013-02-09 18:02 ` Achim Gratz
2013-02-10 10:44 ` Achim Gratz
1 sibling, 0 replies; 58+ messages in thread
From: Achim Gratz @ 2013-02-09 18:02 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-02-09 13:56 ` Nicolas Goaziou
@ 2013-02-09 18:14 ` Sean O'Halpin
2013-02-09 18:49 ` Nicolas Goaziou
0 siblings, 1 reply; 58+ messages in thread
From: Sean O'Halpin @ 2013-02-09 18:14 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Sebastien Vauban, emacs-orgmode
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-02-09 18:14 ` Sean O'Halpin
@ 2013-02-09 18:49 ` Nicolas Goaziou
2013-02-09 20:55 ` Nicolas Richard
0 siblings, 1 reply; 58+ messages in thread
From: Nicolas Goaziou @ 2013-02-09 18:49 UTC (permalink / raw)
To: Sean O'Halpin; +Cc: Sebastien Vauban, emacs-orgmode
"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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-02-09 18:49 ` Nicolas Goaziou
@ 2013-02-09 20:55 ` Nicolas Richard
0 siblings, 0 replies; 58+ messages in thread
From: Nicolas Richard @ 2013-02-09 20:55 UTC (permalink / raw)
To: emacs-orgmode
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.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: compilation issues of new export framework
2013-02-09 17:50 ` Nicolas Goaziou
2013-02-09 18:02 ` Achim Gratz
@ 2013-02-10 10:44 ` Achim Gratz
2013-02-10 12:53 ` Nicolas Goaziou
1 sibling, 1 reply; 58+ messages in thread
From: Achim Gratz @ 2013-02-10 10:44 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply related [flat|nested] 58+ messages in thread
* Re: compilation issues of new export framework
2013-02-10 10:44 ` Achim Gratz
@ 2013-02-10 12:53 ` Nicolas Goaziou
2013-02-10 15:53 ` Nicolas Goaziou
0 siblings, 1 reply; 58+ messages in thread
From: Nicolas Goaziou @ 2013-02-10 12:53 UTC (permalink / raw)
To: Achim Gratz; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: compilation issues of new export framework
2013-02-10 12:53 ` Nicolas Goaziou
@ 2013-02-10 15:53 ` Nicolas Goaziou
2013-02-11 7:49 ` Achim Gratz
0 siblings, 1 reply; 58+ messages in thread
From: Nicolas Goaziou @ 2013-02-10 15:53 UTC (permalink / raw)
To: Achim Gratz; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: compilation issues of new export framework
2013-02-10 15:53 ` Nicolas Goaziou
@ 2013-02-11 7:49 ` Achim Gratz
2013-02-11 20:18 ` Nicolas Goaziou
0 siblings, 1 reply; 58+ messages in thread
From: Achim Gratz @ 2013-02-11 7:49 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: compilation issues of new export framework
2013-02-11 7:49 ` Achim Gratz
@ 2013-02-11 20:18 ` Nicolas Goaziou
2013-02-11 20:30 ` Achim Gratz
0 siblings, 1 reply; 58+ messages in thread
From: Nicolas Goaziou @ 2013-02-11 20:18 UTC (permalink / raw)
To: Achim Gratz; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: compilation issues of new export framework
2013-02-11 20:18 ` Nicolas Goaziou
@ 2013-02-11 20:30 ` Achim Gratz
0 siblings, 0 replies; 58+ messages in thread
From: Achim Gratz @ 2013-02-11 20:30 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-02-08 15:53 ` Sean O'Halpin
2013-02-08 16:45 ` Sebastien Vauban
@ 2013-03-02 18:14 ` Bastien
2013-03-02 21:11 ` Sebastien Vauban
` (4 more replies)
1 sibling, 5 replies; 58+ messages in thread
From: Bastien @ 2013-03-02 18:14 UTC (permalink / raw)
To: Sean O'Halpin; +Cc: Org Mode List, Nicolas Goaziou
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-03-02 18:14 ` Bastien
@ 2013-03-02 21:11 ` Sebastien Vauban
2013-03-03 5:35 ` Bastien
2013-03-03 12:25 ` Sean O'Halpin
` (3 subsequent siblings)
4 siblings, 1 reply; 58+ messages in thread
From: Sebastien Vauban @ 2013-03-02 21:11 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-03-02 21:11 ` Sebastien Vauban
@ 2013-03-03 5:35 ` Bastien
0 siblings, 0 replies; 58+ messages in thread
From: Bastien @ 2013-03-03 5:35 UTC (permalink / raw)
To: Sebastien Vauban; +Cc: public-emacs-orgmode-mXXj517/zsQ
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-03-02 18:14 ` Bastien
2013-03-02 21:11 ` Sebastien Vauban
@ 2013-03-03 12:25 ` Sean O'Halpin
2013-03-03 17:09 ` Bastien
2013-03-04 1:50 ` Rick Frankel
` (2 subsequent siblings)
4 siblings, 1 reply; 58+ messages in thread
From: Sean O'Halpin @ 2013-03-03 12:25 UTC (permalink / raw)
To: Bastien; +Cc: Org Mode List, Nicolas Goaziou
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-03-03 12:25 ` Sean O'Halpin
@ 2013-03-03 17:09 ` Bastien
0 siblings, 0 replies; 58+ messages in thread
From: Bastien @ 2013-03-03 17:09 UTC (permalink / raw)
To: Sean O'Halpin; +Cc: Nicolas Goaziou, Org Mode List
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-03-02 18:14 ` Bastien
2013-03-02 21:11 ` Sebastien Vauban
2013-03-03 12:25 ` Sean O'Halpin
@ 2013-03-04 1:50 ` Rick Frankel
2013-03-04 6:57 ` Bastien
2013-03-04 9:09 ` T.F. Torrey
2013-03-04 15:19 ` Mike McLean
2013-03-04 15:28 ` Suvayu Ali
4 siblings, 2 replies; 58+ messages in thread
From: Rick Frankel @ 2013-03-04 1:50 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-03-04 1:50 ` Rick Frankel
@ 2013-03-04 6:57 ` Bastien
2013-03-04 9:09 ` T.F. Torrey
1 sibling, 0 replies; 58+ messages in thread
From: Bastien @ 2013-03-04 6:57 UTC (permalink / raw)
To: Rick Frankel; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-03-04 1:50 ` Rick Frankel
2013-03-04 6:57 ` Bastien
@ 2013-03-04 9:09 ` T.F. Torrey
1 sibling, 0 replies; 58+ messages in thread
From: T.F. Torrey @ 2013-03-04 9:09 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-03-02 18:14 ` Bastien
` (2 preceding siblings ...)
2013-03-04 1:50 ` Rick Frankel
@ 2013-03-04 15:19 ` Mike McLean
2013-03-04 15:24 ` Nicolas Goaziou
2013-03-04 15:28 ` Suvayu Ali
4 siblings, 1 reply; 58+ messages in thread
From: Mike McLean @ 2013-03-04 15:19 UTC (permalink / raw)
To: Bastien; +Cc: Nicolas Goaziou, Org Mode List
[-- 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 --]
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-02-05 13:07 ` Suvayu Ali
@ 2013-03-04 15:20 ` Suvayu Ali
0 siblings, 0 replies; 58+ messages in thread
From: Suvayu Ali @ 2013-03-04 15:20 UTC (permalink / raw)
To: emacs-orgmode
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.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-03-04 15:19 ` Mike McLean
@ 2013-03-04 15:24 ` Nicolas Goaziou
2013-03-04 16:12 ` Mike McLean
0 siblings, 1 reply; 58+ messages in thread
From: Nicolas Goaziou @ 2013-03-04 15:24 UTC (permalink / raw)
To: Mike McLean; +Cc: Bastien, Org Mode List
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-03-02 18:14 ` Bastien
` (3 preceding siblings ...)
2013-03-04 15:19 ` Mike McLean
@ 2013-03-04 15:28 ` Suvayu Ali
2013-03-04 17:44 ` Bastien
4 siblings, 1 reply; 58+ messages in thread
From: Suvayu Ali @ 2013-03-04 15:28 UTC (permalink / raw)
To: emacs-orgmode
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.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-03-04 15:24 ` Nicolas Goaziou
@ 2013-03-04 16:12 ` Mike McLean
2013-03-04 16:30 ` Nicolas Goaziou
0 siblings, 1 reply; 58+ messages in thread
From: Mike McLean @ 2013-03-04 16:12 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Bastien, Org Mode List
[-- 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>
“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.”
</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>
“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.”
</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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-03-04 16:12 ` Mike McLean
@ 2013-03-04 16:30 ` Nicolas Goaziou
2013-03-04 16:44 ` Mike McLean
0 siblings, 1 reply; 58+ messages in thread
From: Nicolas Goaziou @ 2013-03-04 16:30 UTC (permalink / raw)
To: Mike McLean; +Cc: Bastien, Org Mode List
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-03-04 16:30 ` Nicolas Goaziou
@ 2013-03-04 16:44 ` Mike McLean
0 siblings, 0 replies; 58+ messages in thread
From: Mike McLean @ 2013-03-04 16:44 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Bastien, Org Mode List, 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 --]
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [ANN] Merge of new export framework on Wednesday
2013-03-04 15:28 ` Suvayu Ali
@ 2013-03-04 17:44 ` Bastien
0 siblings, 0 replies; 58+ messages in thread
From: Bastien @ 2013-03-04 17:44 UTC (permalink / raw)
To: Suvayu Ali; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 58+ messages in thread
end of thread, other threads:[~2013-03-04 17:55 UTC | newest]
Thread overview: 58+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-02-03 19:00 [ANN] Merge of new export framework on Wednesday Nicolas Goaziou
2013-02-03 20:59 ` François Allisson
2013-02-04 9:17 ` Detlef Steuer
2013-02-04 13:49 ` David Bjergaard
2013-02-04 21:56 ` Suvayu Ali
2013-02-05 1:07 ` Eric S Fraga
2013-02-05 7:41 ` Suvayu Ali
2013-02-05 9:25 ` Eric S Fraga
2013-02-05 11:18 ` Suvayu Ali
2013-02-05 12:50 ` Eric S Fraga
2013-02-05 13:07 ` Suvayu Ali
2013-03-04 15:20 ` Suvayu Ali
2013-02-04 23:05 ` Bastien
2013-02-04 13:35 ` Rasmus
2013-02-05 16:30 ` org export Taskjuggler (was: Re: [ANN] Merge of new export framework on Wednesday - ) Giovanni Ridolfi
2013-02-05 17:59 ` org export Taskjuggler Nicolas Goaziou
2013-02-07 10:21 ` Christian Egli
2013-02-07 10:43 ` Jambunathan K
2013-02-07 13:13 ` Nicolas Goaziou
2013-02-07 0:14 ` [ANN] Merge of new export framework on Wednesday Jay Kerns
2013-02-08 15:53 ` Sean O'Halpin
2013-02-08 16:45 ` Sebastien Vauban
2013-02-09 13:20 ` Sean O'Halpin
2013-02-09 13:56 ` Nicolas Goaziou
2013-02-09 18:14 ` Sean O'Halpin
2013-02-09 18:49 ` Nicolas Goaziou
2013-02-09 20:55 ` Nicolas Richard
2013-03-02 18:14 ` Bastien
2013-03-02 21:11 ` Sebastien Vauban
2013-03-03 5:35 ` Bastien
2013-03-03 12:25 ` Sean O'Halpin
2013-03-03 17:09 ` Bastien
2013-03-04 1:50 ` Rick Frankel
2013-03-04 6:57 ` Bastien
2013-03-04 9:09 ` T.F. Torrey
2013-03-04 15:19 ` Mike McLean
2013-03-04 15:24 ` Nicolas Goaziou
2013-03-04 16:12 ` Mike McLean
2013-03-04 16:30 ` Nicolas Goaziou
2013-03-04 16:44 ` Mike McLean
2013-03-04 15:28 ` Suvayu Ali
2013-03-04 17:44 ` Bastien
2013-02-09 8:03 ` Achim Gratz
2013-02-09 8:21 ` Nicolas Goaziou
2013-02-09 9:26 ` Bastien
2013-02-09 10:33 ` Achim Gratz
2013-02-09 10:44 ` Nicolas Goaziou
2013-02-09 10:49 ` Bastien
2013-02-09 15:01 ` Jambunathan K
2013-02-09 17:16 ` compilation issues of new export framework Achim Gratz
2013-02-09 17:50 ` Nicolas Goaziou
2013-02-09 18:02 ` Achim Gratz
2013-02-10 10:44 ` Achim Gratz
2013-02-10 12:53 ` Nicolas Goaziou
2013-02-10 15:53 ` Nicolas Goaziou
2013-02-11 7:49 ` Achim Gratz
2013-02-11 20:18 ` Nicolas Goaziou
2013-02-11 20:30 ` Achim Gratz
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).