allow live execution of code snippets in html export

allow live execution of code snippets in html export

[Matt Price]

[-- Attachment #1: Type: text/plain, Size: 577 bytes --]

In other threads I've been describing a method to allow live code snippets
to be embedded in reveal.js export, using klipse (
https://github.com/viebel/klipse).  I have to say it feels somewhat
transformative to me, and I wonder if it would be worth integrating into
ox-html.  I'd be happy to hack together a patch but I wanted to ask if
anyone else likes the idea.  The great thing about putting it into ox-html
instead of building a derived mode is that the other derived mode would
potentially inherit the functionality directly.

Would anyone else like to see this happen?

[-- Attachment #2: Type: text/html, Size: 680 bytes --]

Re: allow live execution of code snippets in html export

[Rasmus]

Hi Matt,

> In other threads I've been describing a method to allow live code snippets
> to be embedded in reveal.js export, using klipse (
> https://github.com/viebel/klipse).  I have to say it feels somewhat
> transformative to me, and I wonder if it would be worth integrating into
> ox-html.  I'd be happy to hack together a patch but I wanted to ask if
> anyone else likes the idea.  The great thing about putting it into ox-html
> instead of building a derived mode is that the other derived mode would
> potentially inherit the functionality directly.

I like it.  The clearest example seems to be this one:

      https://jsfiddle.net/viebel/50oLnykk/

Some observations follow:

The syntax for Klipse source blocks is nice and simple:

    <div class="klipse">
     function foo(name) {return "Hello " + name;}
     foo("Klipse");
    </div>

It might be worth investigating whether you can just run Klipse on <pre>
blocks as that would potentially make it backward compatible.
Potentially, an extension to Klipse that recognizes Org src blocks (in
html) might be nice.

The Klipse license is GPL3.

The README recommends to get the files from googleapis.com.  I’m not sure
we would want to generate html files that get stuff from Google.  Then
again, maybe googleapis.com is perfectly OK...

It could easily become a mess in complex cases, e.g. if your Python code
blocks use Pandas, which does not seem to be supported by Skulpt.

Nonetheless, Klipse looks intriguing.  I think it could be great if you
look further into it.

Thanks,
Rasmus

-- 
Dung makes an excellent fertilizer

Re: allow live execution of code snippets in html export

[Rasmus]

Hi all,

>> It might be worth investigating whether you can just run Klipse on <pre>
>> blocks as that would potentially make it backward compatible.
>> Potentially, an extension to Klipse that recognizes Org src blocks (in
>> html) might be nice.
>>
> I think that should be pretty straighforward.

Yeah, the link in Bastien's twitter post shows there's already a setting
for it

    <script type="text/javascript">window.klipse_settings = {selector: '.src-clojure'};</script>

I don’t know if much more support is needed.  We add some automatic
configuration scripting or add a per-block switch for enabling klipse.

>> The Klipse license is GPL3.
>>
>
> Is org GPL2 or GPL3? Are there any compatibility issues between the two?

No, it was meant as a compliment of a sort.

> If the license permits, and there's a precedent, we could bundle the
> scripts with org.

The Mathjax that ox-html pointed to used to be hosted on orgmode.org until
Mathjax recommend their own CDN.  The problem with that solution is that
it would not be kept up-to-date.

Perhaps there’s no issue with potentially pointing to a Google server, I’m
probably on the more paranoid side on this issue.

Thanks,
Rasmus

-- 
Lasciate ogni speranza o voi che entrate: siete nella mani di'machellaio

Re: allow live execution of code snippets in html export

[Bastien Guerry]

Hi all,

thanks for adding me to this discussion!

klipse + org works pretty much out of the box, which is really great.
I just tested it again with a mix of Scheme and Clojure blocks, both
can work together within the same HTML page.

That said, I think we can take this opportunity to slightly improve
how ox-html handles source code:

- why only <pre> and not <pre><code> ?

- make src-clojure in <pre class="src src-clojure"> customizable ?

- have ob-javascript.el to let ox-html know how to export js code?

- have org-html-js to easily allow adding js libraries at the bottom
  of a page? Perhaps together with #+html_js and #+html_js_extra ?

>> If the license permits, and there's a precedent, we could bundle the
>> scripts with org.

I have no problem with this, but I'd rather think a more general
mechanism to embed scripts in general and get more flexibility in
css classes.

If we provide a straightforward solution, I don't think there is
a problem pointing to Google servers.

We might have a problem with recommending js code that does not
pass the https://www.gnu.org/software/librejs/ tests: that is,
we cannot recommend code that is not advertised the way librejs
recommends it should be advertized.

This is an annoying issue, but a real one I guess.

As long as Klipse + org is somehow available and documented,
I'll be very happy :)

-- 
 Bastien

Re: allow live execution of code snippets in html export

[Matt Price]

[-- Attachment #1: Type: text/plain, Size: 1954 bytes --]

On Wed, Dec 14, 2016 at 5:36 AM, Bastien Guerry <bzg@bzg.fr> wrote:

> That said, I think we can take this opportunity to slightly improve
> how ox-html handles source code:
>
> - why only <pre> and not <pre><code> ?
>
Would we need a switch to permit the old syntax for people with complex
setups who don't want to change?

>
> - make src-clojure in <pre class="src src-clojure"> customizable ?
>
Is this likely to break anything in derived exporters? It would certianly
be convenient e.g for using highlight.js in wordpress in similar
environments.

>
> - have ob-javascript.el to let ox-html know how to export js code ?


Isn't this in org already? there's an ob-js.el in my org repo.


> - have org-html-js to easily allow adding js libraries at the bottom
>   of a page? Perhaps together with #+html_js and #+html_js_extra ?
>

This seems like a good idea and pretty easy.

>
> >> If the license permits, and there's a precedent, we could bundle the
> >> scripts with org.
>
> I have no problem with this, but I'd rather think a more general
> mechanism to embed scripts in general and get more flexibility in
> css classes.
>
> If we provide a straightforward solution, I don't think there is
> a problem pointing to Google servers.
>
> We might have a problem with recommending js code that does not
> pass the https://www.gnu.org/software/librejs/ tests: that is,
> we cannot recommend code that is not advertised the way librejs
> recommends it should be advertized.
>
> This is an annoying issue, but a real one I guess.
>
> I odn't really quite understand the problem and solution parameters.
Since Yehonathan is here on this thread and enthusiastic about helping out:
is there something he could do to make this feasible for us?  Or by "more
general mechanism" do you mean some third way between bundling and linking
to?


> As long as Klipse + org is somehow available and documented,
> I'll be very happy :)
>
Me too!

>
> --
>  Bastien
>

[-- Attachment #2: Type: text/html, Size: 3401 bytes --]

Re: allow live execution of code snippets in html export

[Bastien]

Hi Matt,

Matt Price <moptop99@gmail.com> writes:

> Would we need a switch to permit the old syntax for people with
> complex setups who don't want to change?

Yes.  We need to be more careful on being backward compatible.

>     - make src-clojure in <pre class="src src-clojure"> customizable
>     ?
>
> Is this likely to break anything in derived exporters? It would
> certianly be convenient e.g for using highlight.js in wordpress in
> similar environments.

Yes.

>     - have ob-javascript.el to let ox-html know how to export js
>     code ?
>
> Isn't this in org already? there's an ob-js.el in my org repo.

Yep, indeed -- I have just this in my emacs.el for inline js:

(add-to-list 'org-src-lang-modes '("inline-js" . javascript))
(defvar org-babel-default-header-args:inline-js
  '((:results . "html")
    (:exports . "results")))
(defun org-babel-execute:inline-js (body _params)
  (format "<script type=\"text/javascript\">\n%s\n</script>" body))

Maybe this could be made available too.

>     - have org-html-js to easily allow adding js libraries at the
>     bottom of a page? Perhaps together with #+html_js and
>     #+html_js_extra ?
>
> This seems like a good idea and pretty easy.

I will think more about this.

> I odn't really quite understand the problem and solution parameters. 
> Since Yehonathan is here on this thread and enthusiastic about
> helping out: is there something he could do to make this feasible for
> us?  Or by "more general mechanism" do you mean some third way
> between bundling and linking to?

One way to solve this on Yehonathan's side is to update klipse.js and
follow the instruction on librejs on how to make librejs accept the js
code as "safe":

https://www.gnu.org/software/librejs/free-your-javascript.html

I don't know how much work is involved in this, though.

-- 
 Bastien

Re: allow live execution of code snippets in html export

[Matt Price]

[-- Attachment #1: Type: text/plain, Size: 1561 bytes --]

On Thu, Dec 15, 2016 at 5:07 AM, Bastien <bzg@gnu.org> wrote:

> Hi Matt,
>
> Matt Price <moptop99@gmail.com> writes:
>
> > Would we need a switch to permit the old syntax for people with
> > complex setups who don't want to change?
>
> Yes.  We need to be more careful on being backward compatible.
>
> The new patch in that other thread does this.


> >     - make src-clojure in <pre class="src src-clojure"> customizable
> >     ?
> >
> > Is this likely to break anything in derived exporters? It would
> > certianly be convenient e.g for using highlight.js in wordpress in
> > similar environments.
>
> Yes.
>


> > This seems like a good idea and pretty easy.
>
> I will think more about this.
>
> > I odn't really quite understand the problem and solution parameters.
> > Since Yehonathan is here on this thread and enthusiastic about
> > helping out: is there something he could do to make this feasible for
> > us?  Or by "more general mechanism" do you mean some third way
> > between bundling and linking to?
>
> One way to solve this on Yehonathan's side is to update klipse.js and
> follow the instruction on librejs on how to make librejs accept the js
> code as "safe":
>
> https://www.gnu.org/software/librejs/free-your-javascript.html
>
> I don't know how much work is involved in this, though.
>

I think you just have to add two lines to non-minified scripts, and one
more to minified scripts:
https://www.gnu.org/software/librejs/free-your-javascript.html#magnet-link-license

Yehonathan, would you bewilling to do this?


> --
>  Bastien
>

[-- Attachment #2: Type: text/html, Size: 3132 bytes --]

Re: allow live execution of code snippets in html export

[Yehonathan Sharvit]

[-- Attachment #1: Type: text/plain, Size: 1809 bytes --]

On Thu, Dec 15, 2016 at 5:50 PM, Matt Price <moptop99@gmail.com> wrote:

>
>
> On Thu, Dec 15, 2016 at 5:07 AM, Bastien <bzg@gnu.org> wrote:
>
>> Hi Matt,
>>
>> Matt Price <moptop99@gmail.com> writes:
>>
>> > Would we need a switch to permit the old syntax for people with
>> > complex setups who don't want to change?
>>
>> Yes.  We need to be more careful on being backward compatible.
>>
>> The new patch in that other thread does this.
>
>
>> >     - make src-clojure in <pre class="src src-clojure"> customizable
>> >     ?
>> >
>> > Is this likely to break anything in derived exporters? It would
>> > certianly be convenient e.g for using highlight.js in wordpress in
>> > similar environments.
>>
>> Yes.
>>
>
>
>> > This seems like a good idea and pretty easy.
>>
>> I will think more about this.
>>
>> > I odn't really quite understand the problem and solution parameters.
>> > Since Yehonathan is here on this thread and enthusiastic about
>> > helping out: is there something he could do to make this feasible for
>> > us?  Or by "more general mechanism" do you mean some third way
>> > between bundling and linking to?
>>
>> One way to solve this on Yehonathan's side is to update klipse.js and
>> follow the instruction on librejs on how to make librejs accept the js
>> code as "safe":
>>
>> https://www.gnu.org/software/librejs/free-your-javascript.html
>>
>> I don't know how much work is involved in this, though.
>>
>
> I think you just have to add two lines to non-minified scripts, and one
> more to minified scripts:
> https://www.gnu.org/software/librejs/free-your-javascript.
> html#magnet-link-license
>
> Yehonathan, would you bewilling to do this?
>
​Sure. Will do it tomorrow.​


>
>
>
>> --
>>  Bastien
>>
>
>

[-- Attachment #2: Type: text/html, Size: 4431 bytes --]

Re: allow live execution of code snippets in html export

[Yehonathan Sharvit]

[-- Attachment #1: Type: text/plain, Size: 1863 bytes --]

Done

On Thu, 15 Dec 2016 at 22:55 Yehonathan Sharvit <viebel@gmail.com> wrote:

> On Thu, Dec 15, 2016 at 5:50 PM, Matt Price <moptop99@gmail.com> wrote:
>
>
>
> On Thu, Dec 15, 2016 at 5:07 AM, Bastien <bzg@gnu.org> wrote:
>
> Hi Matt,
>
> Matt Price <moptop99@gmail.com> writes:
>
> > Would we need a switch to permit the old syntax for people with
> > complex setups who don't want to change?
>
> Yes.  We need to be more careful on being backward compatible.
>
> The new patch in that other thread does this.
>
>
> >     - make src-clojure in <pre class="src src-clojure"> customizable
> >     ?
> >
> > Is this likely to break anything in derived exporters? It would
> > certianly be convenient e.g for using highlight.js in wordpress in
> > similar environments.
>
> Yes.
>
>
>
> > This seems like a good idea and pretty easy.
>
> I will think more about this.
>
> > I odn't really quite understand the problem and solution parameters.
> > Since Yehonathan is here on this thread and enthusiastic about
> > helping out: is there something he could do to make this feasible for
> > us?  Or by "more general mechanism" do you mean some third way
> > between bundling and linking to?
>
> One way to solve this on Yehonathan's side is to update klipse.js and
> follow the instruction on librejs on how to make librejs accept the js
> code as "safe":
>
> https://www.gnu.org/software/librejs/free-your-javascript.html
>
> I don't know how much work is involved in this, though.
>
>
> I think you just have to add two lines to non-minified scripts, and one
> more to minified scripts:
>
> https://www.gnu.org/software/librejs/free-your-javascript.html#magnet-link-license
>
> Yehonathan, would you bewilling to do this?
>
> ​Sure. Will do it tomorrow.​
>
>
>
>
>
> --
>  Bastien
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 6547 bytes --]

Re: allow live execution of code snippets in html export

[Matt Price]

[-- Attachment #1: Type: text/plain, Size: 1806 bytes --]

On Wed, Dec 14, 2016 at 5:06 AM, Rasmus <rasmus@gmx.us> wrote:

> Hi all,
>
> >> It might be worth investigating whether you can just run Klipse on <pre>
> >> blocks as that would potentially make it backward compatible.
> >> Potentially, an extension to Klipse that recognizes Org src blocks (in
> >> html) might be nice.
> >>
> > I think that should be pretty straighforward.
>
> Yeah, the link in Bastien's twitter post shows there's already a setting
> for it
>
>     <script type="text/javascript">window.klipse_settings = {selector:
> '.src-clojure'};</script>
>
> I don’t know if much more support is needed.  We add some automatic
> configuration scripting or add a per-block switch for enabling klipse.
>
> Two more little things. HTML blocks can't use the standard editor so they
need an extra attribute `data-editor-style="html"`

Also, Klipse supports including comma-separated external scripts to the
execution environment with the `data-external-libs` attribute

I have been using
#+ATTR_HTML :code_attribs data-external-libs="
http://jquery.org/jquery.js,./lib/01.js".  I'm doing it in tandem with the
:tangle header, exporting previous code snippets and adding them to the
execution environment as I go (just for fun).  I don't know if there's a
better way to do this, potentially maybe trying to partially co-ordinate
the execution environments for klipse and org so that executing code in org
and in the html export gives similar results.  Seems a little ambitious.

Also, it would be nice if klipse had an elisp REPL since so many org users
blog about elisp.



> >> The Klipse license is GPL3.
> >>
> >
> > Is org GPL2 or GPL3? Are there any compatibility issues between the two?
>
> No, it was meant as a compliment of a sort.
>

:-)

[-- Attachment #2: Type: text/html, Size: 2611 bytes --]

Re: allow live execution of code snippets in html export

[Yehonathan Sharvit]

[-- Attachment #1: Type: text/plain, Size: 2012 bytes --]

On Wed, 14 Dec 2016 at 19:55 Matt Price <moptop99@gmail.com> wrote:

> On Wed, Dec 14, 2016 at 5:06 AM, Rasmus <rasmus@gmx.us> wrote:
>
> Hi all,
>
> >> It might be worth investigating whether you can just run Klipse on <pre>
> >> blocks as that would potentially make it backward compatible.
> >> Potentially, an extension to Klipse that recognizes Org src blocks (in
> >> html) might be nice.
> >>
> > I think that should be pretty straighforward.
>
> Yeah, the link in Bastien's twitter post shows there's already a setting
> for it
>
>     <script type="text/javascript">window.klipse_settings = {selector:
> '.src-clojure'};</script>
>
> I don’t know if much more support is needed.  We add some automatic
> configuration scripting or add a per-block switch for enabling klipse.
>
> Two more little things. HTML blocks can't use the standard editor so they
> need an extra attribute `data-editor-style="html"`
>
> Also, Klipse supports including comma-separated external scripts to the
> execution environment with the `data-external-libs` attribute
>
> I have been using
> #+ATTR_HTML :code_attribs data-external-libs="http://
> jquery.org/jquery.js,./lib/01.js".  I'm doing it in tandem with the
> :tangle header, exporting previous code snippets and adding them to the
> execution environment as I go (just for fun).  I don't know if there's a
> better way to do this, potentially maybe trying to partially co-ordinate
> the execution environments for klipse and org so that executing code in org
> and in the html export gives similar results.  Seems a little ambitious.
>
> Also, it would be nice if klipse had an elisp REPL since so many org users
> blog about elisp.
>

​For that, one needs to find (or to write) an elisp evaluation in
javascript.​


>
>
>
> >> The Klipse license is GPL3.
> >>
> >
> > Is org GPL2 or GPL3? Are there any compatibility issues between the two?
>
> No, it was meant as a compliment of a sort.
>
>
> :-)
>

[-- Attachment #2: Type: text/html, Size: 6258 bytes --]

Re: allow live execution of code snippets in html export

[Bastien Guerry]

Hi Matt,

Matt Price <moptop99@gmail.com> writes:

> Two more little things. HTML blocks can't use the standard editor so
> they need an extra attribute `data-editor-style="html"`

I'm not sure what you mean here: can you give an example?

> Also, it would be nice if klipse had an elisp REPL since so many org
> users blog about elisp.

Seems rather ambitious but I agree this would be fun!

-- 
 Bastien

Re: allow live execution of code snippets in html export

[Eric S Fraga]

[-- Attachment #1: Type: text/plain, Size: 812 bytes --]

On Tuesday, 13 Dec 2016 at 14:55, Matt Price wrote:
> In other threads I've been describing a method to allow live code
> snippets to be embedded in reveal.js export, using klipse (https://
> github.com/viebel/klipse).  I have to say it feels somewhat
> transformative to me, and I wonder if it would be worth integrating
> into ox-html.  I'd be happy to hack together a patch but I wanted to
> ask if anyone else likes the idea.  The great thing about putting it
> into ox-html instead of building a derived mode is that the other
> derived mode would potentially inherit the functionality directly.
>
> Would anyone else like to see this happen?

I could see using this for a few of my lectures so, yes, please!

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 26.0.50.1, Org release_8.3.6-1268-g877f35

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 162 bytes --]