[Top][All Lists]

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

Re: [O] HTML5 presentations

From: Eric Schulte
Subject: Re: [O] HTML5 presentations
Date: Thu, 16 Jun 2011 16:19:28 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Robert Goldman <address@hidden> writes:

> On 6/16/11 Jun 16 -3:36 PM, Jambunathan K wrote:
>> Eric Schulte <address@hidden> writes:
>>> Robert Goldman <address@hidden> writes:
>>>> On 6/7/11 Jun 7 -3:01 PM, Tassilo Horn wrote:
>>>>> Vinh Nguyen <address@hidden> 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.

Admittedly I don't know what transformation are required by the html5
presentation mechanism, however I would think that an approach like that
taken in org-export-as-s5 [1], in which the existing org-export-as-html
is simply wrapped in a let-form which sets variable values uses hooks to
post-process, should be the simplest and would leverage as much of the
existing machinery as possible.

Best -- Eric

[1]  https://github.com/eschulte/org-S5/blob/master/org-export-as-s5.el#L17

Eric Schulte

reply via email to

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