First-class mechanism for executable examples

For https://github.com/JoshKarpel/pytest-its-whats-for-testing I needed to have editable and executable code examples (stored as separate files) in the presentation.

To get that talk out the door, I did this "outside the library".

I added a mechanism to add custom keybindings on a per-slide level

spiel/spiel/slide.py

Line 21 in 29c5138

bindings: Mapping[str, Callable[..., None]] = field(default_factory=dict)

. Because the callbacks are per-slide, I was able to generate new edit functions (using the library-level suspend) for each slide https://github.com/JoshKarpel/pytest-its-whats-for-testing/blob/ada03fc54c92c90a1f18ced4b80dca4cab56f7b4/pytest_its_whats_for_testing/slides.py#L132.
I built code execution on top of triggers https://github.com/JoshKarpel/pytest-its-whats-for-testing/blob/ada03fc54c92c90a1f18ced4b80dca4cab56f7b4/pytest_its_whats_for_testing/slides.py#L72-L83.

It would be nice for there to be some kind of first-class mechanism for this inside spiel so that people don't need to reinvent the wheel. The problem is that this mechanism needs to be highly customizable:

Code examples may or may not need to be editable, and there might be multiple files involved in a given example.
Code examples might not be Python code, so the executable needs to be customizable (but sys.executable is probably a reasonable default). There might even be multiple things to execute!
The slide contents need to be totally customizable. I'm not even sure I feel comfortable providing a default...

... but it might also be worth making a "drop dead simple" version that is not very customizable, and then letting users build more complex versions if they want one - the primitives are all there, of course. Being too proscriptive is not the goal, and building something that can please everyone isn't possible either.