fancier and less fancy export

fancier and less fancy export

[Scott Otterson]

My biggest use of org-mode export is spitting out simple ASCII lists 
that I paste into emails.  Even so, I have picky export enhancement 
requests:

1.) Add org-export-visible-as-ascii:  org-export-copy-visible creates a 
new org file containing the visible text.  The problem for me is that 
it's still an org-file, with all the leading *'s, linking text and so 
on.  So, I'd like to clean it up by running org-export-as-ascii over the 
export-visible file but

 - this is an extra step
 - when I try to do this, I get the error message:      
     Wrong type argument: stringp, nil

2.) Export with simple leading characters instead of section numbers.  
Maybe there's already a way to do this, but I'd like to see an option 
for exporting headlines with leading '*' ,'o', '-'' and so on, instead 
of with long section numbers like 3.4.2.1.   For html export, this could 
be just the standard itemized list characters; for ascii, it could be 
something similar.  This could be done with a customization variable, a 
prefix, or very long commands like org-export-visible-as-ascii-simple...

Also, a general question:  There's been discussion of adapting muse-mode 
so that org-mode can eventually make use of its many export 
capabilities.   At that same time, we've got very interesting xoxo 
export capability and the nice new code written by David O'Toole.   This 
is great stuff but to a new user, these multiple and somewhat 
overlapping choices are bound to be confusing.  Will all this good code 
eventually get merged into a unified org-mode exporting system?

Thanks,

Scott

Re: fancier and less fancy export

[Nic]

Scott Otterson <scotto@u.washington.edu> writes:

> Also, a general question:  There's been discussion of adapting muse-mode 
> so that org-mode can eventually make use of its many export 
> capabilities.   At that same time, we've got very interesting xoxo 
> export capability and the nice new code written by David O'Toole.   This 
> is great stuff but to a new user, these multiple and somewhat 
> overlapping choices are bound to be confusing.  Will all this good code 
> eventually get merged into a unified org-mode exporting system?

I think the problem is we're all just trying out org-mode and working
out what we think it's good for and stretching it in new ways.

To some people it seems it's a plain organizational outliner.

To other people it seems it's a document construction outliner.

To many people it looks like it might be a blogging tool.

All these different things need different export. 


Having said that, if I have time to clean up the XOXO output I think
that might consolidate some things because it will be simple clean
HTML which people can parse and transform in other ways.


Nic Ferrier

Re: fancier and less fancy export

[David O'Toole]

I plan on continuing to write and support org-publish.el and its
extensions. Because it was designed to be format-agnostic at both
input and output stages (via plugin functions), I think it has a good
chance of working with the XOXO stuff and other extensions people want
to make. Furthermore, it currently publishes all my files, whether
they're e-scripts, elisp code, or .org files. 

From what I understand, it is not a trivial matter to get Muse
publishing other markup formats than the one it was designed
around. It's something of an overhaul for the next major version, not
a few tweaks. Since muse until recently lacked support for nested
bullet lists (which always drove me nuts) I am not holding my breath
waiting for Muse to fully support Org files, upload attachments, and
format other types of files, the way org-publish does. :-)

Whereas, I think org-publish.el is already a "unified" org-mode
exporting system. I've never had such an easy time authoring an entire
website as when using org.el and org-publish.el, and I can speak from
several years experience with planner, emacswiki, and muse. 

Org-publish.el does not currently support things like LaTeX output,
but I have volunteered to work on it. 


Scott Otterson <scotto@u.washington.edu> writes:

> Also, a general question:  There's been discussion of adapting
> muse-mode so that org-mode can eventually make use of its many export
> capabilities.   At that same time, we've got very interesting xoxo
> export capability and the nice new code written by David O'Toole.
> This is great stuff but to a new user, these multiple and somewhat
> overlapping choices are bound to be confusing.  Will all this good
> code eventually get merged into a unified org-mode exporting system?



-- 
Dave O'Toole
dto@gnu.org

Re: fancier and less fancy export

[Carsten Dominik]

On May 8, 2006, at 18:43, Scott Otterson wrote:

> My biggest use of org-mode export is spitting out simple ASCII lists 
> that I paste into emails.  Even so, I have picky export enhancement 
> requests:
>
> 1.) Add org-export-visible-as-ascii:  org-export-copy-visible creates 
> a new org file containing the visible text.  The problem for me is 
> that it's still an org-file, with all the leading *'s, linking text 
> and so on.  So, I'd like to clean it up by running org-export-as-ascii 
> over the export-visible file but
>
> - this is an extra step
> - when I try to do this, I get the error message:          Wrong type 
> argument: stringp, nil


I will take a look.  My guess is that it would be sufficient to turn on 
org-mode for that new file and save it under a different name before 
exporting.  But yes, this can and should be easier.

>
> 2.) Export with simple leading characters instead of section numbers.  
> Maybe there's already a way to do this, but I'd like to see an option 
> for exporting headlines with leading '*' ,'o', '-'' and so on, instead 
> of with long section numbers like 3.4.2.1.   For html export, this 
> could be just the standard itemized list characters; for ascii, it 
> could be something similar.  This could be done with a customization 
> variable, a prefix, or very long commands like 
> org-export-visible-as-ascii-simple...

This is already there, all you need to do is to change the level at 
which the exporter switches from headlines to itemized lists.  You can 
do this using the H switch in the #+OPTIONS line, or simply using a 
prefix argument to the exporter command.

For example

    C-1 M-x org-export-as-html

will only make headlines of level one headlines, and do level two and 
up as itemize lists.

Nothing stops you from setting this to 0, to get lists only.  For 
example

#+OPTIONS: H:0

>
> Also, a general question:  There's been discussion of adapting 
> muse-mode so that org-mode can eventually make use of its many export 
> capabilities.   At that same time, we've got very interesting xoxo 
> export capability and the nice new code written by David O'Toole.   
> This is great stuff but to a new user, these multiple and somewhat 
> overlapping choices are bound to be confusing.  Will all this good 
> code eventually get merged into a unified org-mode exporting system?

The way I see this is the following.

- The Muse maintainer Michael Olsen has talked about making Muse 
understand org-mode syntax.  While some time ago I had been considering 
to export org-mode files to Muse syntax, this is currently not on my 
TODO list.  It makes more sense to do this on the Muse side, so I will 
leave this to them.

- David O'Toole has been pushing to make Org-mode more publishing 
friendly, and I fully support his org-publish.el.  This code will 
become an integral part of org.el soon - but I want to wait until a few 
people have tested it, and I can only put it into org.el once David has 
signed the papers with the FSF so that I can install this code into 
Emaccs.  My expectation is that Emacs 22.1 will role without 
org-publish, but as of 22.2 it will be part of it.  I have no idea what 
will happen to blogging, e-scripts etc, this is beyond my horizon at 
the moment.  And I agree that this has to be carefully sorted out or we 
will get a mess.  I don't want org to become like planner, a beast 
tweaked for really everything and in the process loosing its 
consistency. org-publish.el is just an extension of the existing HTML 
exporter and in this way a very logical step.

- There has been some talk about LaTeX export - I personally don't see 
this as important and I would probably not use it.  The LaTeX 
environment in Emacs is so excellent that I clearly prefer this to 
produce my LaTeX files.  For my organization files I see little use of 
printing them through LaTeX.

- Finally there is the XML backend which may be a gateway to more 
flexible export.  I am by no means an expert on this.  So I will help 
when needed, but not implement this myself.

So for the time being I am putting my money on a limited set of 
exporting code inside org-mode.  Hope this clarifies things a bit.

- Carsten

Re: fancier and less fancy export

[Nic]

Carsten Dominik <carsten.dominik@gmail.com> writes:

> - Finally there is the XML backend which may be a gateway to more 
> flexible export.  I am by no means an expert on this.  So I will help 
> when needed, but not implement this myself.

Small correction. The XOXO stuff is not an XML backend. XOXO is
HTML. It's just semantic only HTML.

I'm interested in making a semantic, microformat HTML based exporter
for org-mode extending what I've already provided with the XOXO stuff.


Nic

Re: fancier and less fancy export

[Carsten Dominik]

On May 8, 2006, at 18:43, Scott Otterson wrote:

> My biggest use of org-mode export is spitting out simple ASCII lists 
> that I paste into emails.  Even so, I have picky export enhancement 
> requests:
>
> 1.) Add org-export-visible-as-ascii:  org-export-copy-visible creates 
> a new org file containing the visible text.  The problem for me is 
> that it's still an org-file, with all the leading *'s, linking text 
> and so on.  So, I'd like to clean it up by running org-export-as-ascii 
> over the export-visible file but

In the next version, this is going to work as follows:

The command org-export-copy-visible no longer exists.

Instead there is a new command org-export-visible, bound to C-c C-x v.
When using this command, you are prompted for another key, to specify 
the true export command.  Org-mode will then make a temporary buffer 
containing the visible part of the current buffer only, and export this 
buffer to ascii, html, xoxo.

- Carsten

Re: fancier and less fancy export

[Scott Otterson]

Carsten Dominik (05/12/2006 12:57 AM) wrote:
> In the next version, this is going to work as follows:
> 
> The command org-export-copy-visible no longer exists.
> 
> Instead there is a new command org-export-visible, bound to C-c C-x v.
> When using this command, you are prompted for another key, to specify 
> the true export command.  Org-mode will then make a temporary buffer 
> containing the visible part of the current buffer only, and export this 
> buffer to ascii, html, xoxo.

Thanks.  This is perfect.

One thing I noticed, though, is that tables with the < > column width 
limitation are exported without the width being collapsed, like so:

| purpose | run | words |  EM | note       | options    |
|---------+-----+-------+-----+------------+------------+
| acfeat  |   0 |       | <3> | turns      |            |
| thresh  |   1 | NA    | 12  | turns      |  thrsh=10  |
| thresh  |  56 | x     | 0/0 improve | nolab/turns | thrsh=30   |

even if it was being displayed collapsed at the time of export 
(collapsed by hitting a tab in a cell somewhere, for example).

Now that I think of it, it would be nice if table column widths were 
collapsed at the first entry of a .org file.  Without that first TAB, my 
tables are unreadably mangled.  On the other hand, I suppose that seing 
them uncollapsed at first, is a good reminder of the content that will 
be hidden after the first TAB.

Scott

Re: fancier and less fancy export

[Carsten Dominik]

On May 12, 2006, at 19:08, Scott Otterson wrote:

>
> One thing I noticed, though, is that tables with the < > column width 
> limitation are exported without the width being collapsed, like so:
>
> | purpose | run | words |  EM | note       | options    |
> |---------+-----+-------+-----+------------+------------+
> | acfeat  |   0 |       | <3> | turns      |            |
> | thresh  |   1 | NA    | 12  | turns      |  thrsh=10  |
> | thresh  |  56 | x     | 0/0 improve | nolab/turns | thrsh=30   |
>
> even if it was being displayed collapsed at the time of export 
> (collapsed by hitting a tab in a cell somewhere, for example).

Nice to know that someone is using the narrow columns.

Yes, this is not yet correct, in particular on XEmacs.  I think this 
does work on Emacs, because Emacs carries the invisibility properties 
correctly along and even respects them when printing.  OK, it is on my 
list of things to fix.

>
> Now that I think of it, it would be nice if table column widths were 
> collapsed at the first entry of a .org file.  Without that first TAB, 
> my tables are unreadably mangled.  On the other hand, I suppose that 
> seing them uncollapsed at first, is a good reminder of the content 
> that will be hidden after the first TAB.

either globally in .emacs

     (setq org-startup-align-all-tables t)

or in the file itself

    #+STARTUP: align

This is also covered in the manual, at the end of section 3.2.  In 
large org-files with many tables, this may cause a noticeable delay 
when visiting an org-file because all tables are re-aligned.  I guess I 
could limit this to only tables with a <N> cookie, then it could be a 
bit faster.

- Carsten