RunKit Code Block Processor about asciidoctor-extensions-lab HOT 11 CLOSED

Very cool!

I like the option to specify the implementation, though I think to make this more semantic we should use an option with a default implementation and allow the attribute to override that choice.

[source%interactive,javascript]
----
const lodash = require("lodash");

lodash.camelCase('get content');
----

(This builds on the semantics of %interactive option for checklists).

I'd also rename the runkit attribute to runner. That way, we have a consistent syntax if we add support for other languages.

We might also want to have a global attribute to set the runner(s).

from asciidoctor-extensions-lab.

@hsablonniere You may be interested in where this is headed.

from asciidoctor-extensions-lab.

Of course, how cool would it be to test some Asciidoctor.js in the browser as the main example that we show?

from asciidoctor-extensions-lab.

Sure – we just need to be aware code snippets within a same document can be run by different runners. Authors could definitely mix Python and JS, each of them might have a different set of options depending on the runner runtime.

And indeed I almost hesitated writing the aforementioned snippets with asciidoctor-js to render some Asciidoc with Node in the browser ;-)

from asciidoctor-extensions-lab.

we just need to be aware code snippets within a same document can be run by different runners.

Absolutely. I was thinking more along the lines of a runner per langauge. Something like:

:runner-javascript: nodeVersion:6

from asciidoctor-extensions-lab.

When Asciidoctor encounters a delimited block or paragraph with an unrecognized name while parsing the document, it looks for a BlockProcessor registered to handle this name and, if found, invokes its {Processor#process} method to build a corresponding node in the document tree.

@mojavelinux Given this fact, what is the best approach to create an extension to process a source block ?

from asciidoctor-extensions-lab.

The best option is a Treeprocessor. Technically, there's nothing wrong with that choice in this case since we want all the normal behavior of parsing a source block, we just want to do something else with it before conversion (aka rendering).

The BlockProcessor is intended for the case when you want to influence (actually take over) the parsing. (Technically, Asciidoctor Diagram could be done with a Treeprocessor too).

from asciidoctor-extensions-lab.

In fact, I did something similar in one of the existing (somewhat poorly written) extensions in the lab. See https://github.com/asciidoctor/asciidoctor-extensions-lab/blob/master/lib/shell-session-treeprocessor/extension.rb.

The drawback of treeprocessors right now find_by misses some blocks in the tree, including blocks inside AsciiDoc table cells...so you just have to work a bit harder to find all the blocks to process. For most documents, though, the blocks are accessible.

from asciidoctor-extensions-lab.

It is out of scope of this repo so I close the issue.

I started working on it here: https://github.com/oncletom/asciidoctor-extension-interactive-runner.

from asciidoctor-extensions-lab.

👍

from asciidoctor-extensions-lab.

@oncletom The code looks really good, well done 👍

from asciidoctor-extensions-lab.