Default viewer template: necessary overhead and customizability?

[joyrexus]

The viewer template includes the coffeescript compiler. Necessary?

More generally, you want to allow for custom templates via a command-line switch along docco lines (simple JSTs)? I myself can imagine using the Tangle elements to drive D3 viz and would likely never use the flot graphing thingy.

[alecperkins]

Yes, because the code blocks are editable, so it has to recompile the CoffeeScript each time. Custom templates are also a definite, or perhaps features you don’t want to be part of it can be excluded using flags.

activemd --template custom_template.html
activemd --no-graph --no-coffee

I’d like the default to “just work”, so that means enabling all the possibilities. But there is definitely a lot of overhead for simpler documents. If the parser is more intelligent, it could detect which elements are used and include/exclude libraries accordingly, since, while the code is editable, controls and elements can’t be added or modified. Having the parser be written in CoffeeScript is probably the best approach, because then it can share parsing code between the command and the viewing template (and also any online live viewer, similar to how proto works).

I really should go through my notes and make proper issues for features.

[joyrexus]

Yes, (CS compiler is necessary), because the code blocks are editable, so it has to recompile the CoffeeScript each time.

Ah, right.

Custom templates are also a definite,

Excellent.

... or perhaps features you don’t want to be part of it can be excluded using flags.

activemd --no-graph --no-coffee

Or you could use the switches to include the feature-rich stuff if you need it, e.g.: activemd --editable --graph

activemd [options] file.amd

  options:
    -t --template
    -e --editable
    -g --graph

Just a thought.

FWIW, I guess I'm thinking that reactive rather than programmable docs -- like @mbostock's tutorials or @worrydream's explorable explanations -- would be the more common use case, but I could be wrong.

[alecperkins]

What I have in mind is reactive documents, but ones that expose their logic directly and allow that logic to be tinkered with. So for example, an author has a document about a budget that lets you mess with parameters, but you have some questions about their underlying assumptions and want to see what happens.

@worrydream's Ten Brighter Ideas lets you open up the code that runs the examples and edit it live, but it's not as integrated as it could be. It also requires understanding how the Tangle framework works. The thinking with Active Markdown is to abstract the framework part of it enough that interacting with the controls through the code is just using and assigning variables — one of the most basic and easily understandable aspects to programming.

Huh, @worrydream even says “Can it be almost as easy as writing static text?” in the Explorable Explanations page; that’s exactly what came to mind when first thinking about all this.

[joyrexus]

What I have in mind is reactive documents, but ones that expose their logic directly and allow that logic to be tinkered with.

Its a brilliant idea and makes total sense. I didn't mean to suggest the programmability of the document shouldn't be an option.

I'm just sayin' that there's a potentially common use case for interactive READMEs, essays, and tutorials where you wouldn't want to expose the logic linking the interactive pieces, as the logic might not be relevant to what you're trying to communicate.

[alecperkins]

Good point. A --no-edit flag might be a useful option.