* fancier and less fancy export
@ 2006-05-08 16:43 Scott Otterson
2006-05-08 17:07 ` Nic
` (3 more replies)
0 siblings, 4 replies; 8+ messages in thread
From: Scott Otterson @ 2006-05-08 16:43 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: fancier and less fancy export
2006-05-08 16:43 fancier and less fancy export Scott Otterson
@ 2006-05-08 17:07 ` Nic
2006-05-08 19:33 ` David O'Toole
` (2 subsequent siblings)
3 siblings, 0 replies; 8+ messages in thread
From: Nic @ 2006-05-08 17:07 UTC (permalink / raw)
To: Scott Otterson; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: fancier and less fancy export
2006-05-08 16:43 fancier and less fancy export Scott Otterson
2006-05-08 17:07 ` Nic
@ 2006-05-08 19:33 ` David O'Toole
2006-05-08 21:00 ` Carsten Dominik
2006-05-12 7:57 ` Carsten Dominik
3 siblings, 0 replies; 8+ messages in thread
From: David O'Toole @ 2006-05-08 19:33 UTC (permalink / raw)
To: Scott Otterson; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: fancier and less fancy export
2006-05-08 16:43 fancier and less fancy export Scott Otterson
2006-05-08 17:07 ` Nic
2006-05-08 19:33 ` David O'Toole
@ 2006-05-08 21:00 ` Carsten Dominik
2006-05-08 21:13 ` Nic
2006-05-12 7:57 ` Carsten Dominik
3 siblings, 1 reply; 8+ messages in thread
From: Carsten Dominik @ 2006-05-08 21:00 UTC (permalink / raw)
To: Scott Otterson; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: fancier and less fancy export
2006-05-08 21:00 ` Carsten Dominik
@ 2006-05-08 21:13 ` Nic
0 siblings, 0 replies; 8+ messages in thread
From: Nic @ 2006-05-08 21:13 UTC (permalink / raw)
To: Carsten Dominik; +Cc: Scott Otterson, emacs-orgmode
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: fancier and less fancy export
2006-05-08 16:43 fancier and less fancy export Scott Otterson
` (2 preceding siblings ...)
2006-05-08 21:00 ` Carsten Dominik
@ 2006-05-12 7:57 ` Carsten Dominik
2006-05-12 17:08 ` Scott Otterson
3 siblings, 1 reply; 8+ messages in thread
From: Carsten Dominik @ 2006-05-12 7:57 UTC (permalink / raw)
To: Scott Otterson; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: fancier and less fancy export
2006-05-12 7:57 ` Carsten Dominik
@ 2006-05-12 17:08 ` Scott Otterson
2006-05-12 22:03 ` Carsten Dominik
0 siblings, 1 reply; 8+ messages in thread
From: Scott Otterson @ 2006-05-12 17:08 UTC (permalink / raw)
To: Carsten Dominik; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: fancier and less fancy export
2006-05-12 17:08 ` Scott Otterson
@ 2006-05-12 22:03 ` Carsten Dominik
0 siblings, 0 replies; 8+ messages in thread
From: Carsten Dominik @ 2006-05-12 22:03 UTC (permalink / raw)
To: Scott Otterson; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2006-05-12 22:03 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-05-08 16:43 fancier and less fancy export Scott Otterson
2006-05-08 17:07 ` Nic
2006-05-08 19:33 ` David O'Toole
2006-05-08 21:00 ` Carsten Dominik
2006-05-08 21:13 ` Nic
2006-05-12 7:57 ` Carsten Dominik
2006-05-12 17:08 ` Scott Otterson
2006-05-12 22:03 ` Carsten Dominik
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).