emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Orgmode] Org-export-generic and wikis...


From: Robert Goldman
Subject: [Orgmode] Org-export-generic and wikis...
Date: Wed, 28 Apr 2010 14:38:47 -0500
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4

I'm trying to get o-e-g to handle export to multiple wikis.

One of the ones that I'm having the most trouble with is tikiwiki
(www.tikiwiki.org).

The problem here is that tikiwiki won't reflow normal text blocks.  This
means that we need to (1) take contiguous blocks of text and ram them
all together (making sure we replace newlines with spaces) and (2) we
need to detect paragraph breaks in body text (blank lines, I believe)
and force them into the exported code as newlines.

I have a partial solution to the first, but it doesn't handle the second
problem well -- it's concatenating all the body text between two
headings together and not honoring paragraph breaks.  The reason it does
this is that the way o-e-g works is to process each line individually,
and there's no special check for blank lines.  For that matter, it
doesn't /seem/ to take into account the possibility that its output will
go somewhere that treats newlines as paragraph boundaries.

The only thing I can think about for the latter (and what I have
tentatively implemented) is to add a new export flag that indicates that
an export format expects to treat newlines as paragraph breaks.  With
this set to t, I have org-export-generic emit a newline when it sees a
blank line.  The expectation is that the value of body-line format does
/not/ emit a newline at the end.

Does this sound OK?  I will send a patch as soon as I can remember how
to make git send one in email...

Two follow-on questions about org-export-generic:
1. Would it be reasonable to move the documentation for
org-export-generic into the contrib/  directory of org-mode?  It seems
... suboptimal to have this package be maintained in the org git repo,
but its documentation in the worg git repo.  At least from my PoV this
raises the bar for keeping the documentation up-to-date and synchronized
to a pretty high level.
2. Is the existing "handle each line separately" algorithm going to
permit us to handle faces correctly?  Seems like we'll need a lot of
hair to handle, e.g., a phrase in italics that straddles a line-break,
won't we?

Best,
r




reply via email to

[Prev in Thread] Current Thread [Next in Thread]