Proposal: custom renderers

[Tenchi2xh]

It's kind of a crazy idea, but after thinking for a while about how to manage this in the settings, I think I got a simple solution in the end.

It's a bit long to explain so I'll let the images do the talking:

What do you think? It would make it much easier for including diagrams. The alternative, inlining all diagrams and ASCII art, would take a lot of space in the markdown file, and make it harder to maintain: lots compiling, copy-pasting, and escaping special characters.

Here's in text format the config format I showed in the screenshots above:

imageRenderers:
  - pattern: .*\.(monopic|mono)
    command: monodraw --unicode {0}
  - pattern: .*\.puml
    command: java -jar ~/plantuml.jar -f txt {0}

spanRenderers:
  figlet:
    parameters:
      font: -f {0}
    command: figlet {0} {1}

  toilet:
    parameters:
      font: -f {0}
      filter: -F {0}
    command: toilet {0} {1}

  rainbowCow:
    parameters:
      cowfile: -f {0}
    command: cowsay {0} {1} | lolcat -F 0.3

(Instead of regexes, it could be just lists of strings containing the relevant extensions)

Edit: something I forgot! When using the markdown image syntax (or HTML), the text/alt part could be rendered underneath the rendered image like so:

[jaspervdj]

I would still like to have something like this but I haven't yet decided on a clean format.

One design decision to make is if we want to support a long-running process (like the https://github.com/gibiansky/IHaskell kernel) or if we just evaluate the command before displaying the slide and assume it exits.

[nbrandaleone]

+1 on the idea. I would love for Patat to support AsciiArt, or some sort of UTF-8 graphics.

[Floby]

I support this because I had to inline my ascii schematics inside a

 block for it to render properly
            

[jaspervdj]

I'd like to pick this up now. I am leaning towards a design where an evaluator is set at the top level, e.g.:

patat:
  eval:
    command: bash

Whenever a code block is highlighted as eval, we:

1. Start a process with the given command
2. Feed the contents of the code block to the stdin handle of that process
3. Render the stdout of the command in a code block

This means that this presentation:

---
patat:
  eval:
    command: bash
...

```eval
echo "Hello, world!"

Is equivalent to the following presentation:

Hello World!

Some questions / concerns around the design:

1.  Should the output always be wrapped in a code block?  It definitely seems
    useful for most use cases.  But not having it wrapped in a code block means
    you can use a command that renders markdown, which is also powerful.
    However, doing that would require us to re-parse the slides, so I'm leaning
    towards not doing this for now.
2.  Should we display the input as well as the output?  This seems useful if
    you're teaching a programming languages and you want to show REPL
    examples!  However, you probably wouldn't want it for the images example
    mentioned by @Tenchi2xh.  Maybe it should be configurable?
3.  If we're displaying the input as I mentioned in (2), should the user press
    a key before we display the output?  That seems useful as well for teaching.
    Maybe there needs to be a setting here as well?  Or do we do this by
    default?
4.  Do we need to care about the order of commands?  If we have something
    like `mkdir foo` on slide 2, and `touch foo/bar` on slide 3, what happens if
    the user skips to slide 3?  Should we always run all commands just once
    in-order and cache the result?  That may cause a noticeable delay when
    opening the presentation or seeking...