Re: HTML5 presentations

[Robert Goldman <rpgoldman@sift.info>]

On 6/16/11 Jun 16 -3:36 PM, Jambunathan K wrote:
> Eric Schulte <schulte.eric@gmail.com> writes:
> 
>> Robert Goldman <rpgoldman@sift.info> writes:
>>
>>> On 6/7/11 Jun 7 -3:01 PM, Tassilo Horn wrote:
>>>> Vinh Nguyen <vinhdizzo@gmail.com> writes:
>>>>
....
>>>
>>> I have tried the version here:
>>> https://github.com/twada/org-html5presentation.el
>>>
>>> and it does not seem to be ready for prime-time.  Org-babel features
>>> don't work, and there seems to be not a clear integration with the
>>> org-export-preprocessor.  See my two issues, one (not satisfactorily)
>>> closed, one open.
>>>
>>> Possibly this should be folded into contrib, so that people could
>>> cooperate on it more easily than when it lives off in a separate git
>>> repo, but it shouldn't be enabled for the unwary until it's been
>>> thoroughly exercised.
>>>
>>> Is there a "tries to use all features" org presentation somewhere that
>>> would serve as a good acid test for an export facility?  It would be
>>> very handy to have that.
>>>
>>
>> This export target seems to re-implement much of the org HTML export
>> mechanics which is most likely the reason for the incomplete coverage of
>> Org's large functionality.
>>
>> Perhaps it would be possible to change this so that it works more like
>> org-s5, that is, so that it firsts exports using the existing html
>> export functionality, and then simply manipulates the resulting html.
>>
> 
> I haven't looked at or tried either org-s5 or the html5 presentations. 
> 
> I would like to note that much of the refactoring of the html exporter
> is already done and is ready for prime time. I would very much like to
> see that my code be used for such experimentations.
> 
> I will only note that the only way Free Software can thrive is by
> adopting an "embrace and extend" approach.

Can you explain more about how we should proceed?  Are you recommending:

Your refactoring should be merged into the main branch BEFORE attempting
to re-engineer org-html5presentation?

Or is there something else?

Also, does your re-engineering help with the problem that I cited above?
 I.e., the fact that org-export-current-backend is used BOTH to load the
export code AND to indicate to the preprocessor how to preprocess.  The
problem here is that we can't make two different backends share the same
preprocessing.

Actually, more generally, I think the problem is that the
export-preprocessor, since it doesn't have anything like methods or
higher-order functions, forces us to build into each preprocessing
function a big conditional based on the value of
org-export-current-backend, which is cumbersome.

Best,
r