nbshinx -> nbsphinx

[mgeier]

No description provided.

[chrisjsewell]

Hey @mgeier thanks for the typo correction, I promise it wasn't a slight on nbsphinx 😂
Sorry, I intended to contact you about my use of nbsphinx but it got lost somewhere in my long Todo list. Hopefully, you can see why I wasn't able to utilise nbsphinx directly as a dependency; principally because of the way the nbconvert mechanisms (template and execution pre-processor) are somewhat hardcoded into the parser.
Some of the changes I have made, that you may want to consider implementing directly in nbsphinx are:

• Splitting up the code into separate files. I've found it easier to understand the code like this, and better for the git history.
• Implementing my markdown -> RST ipypandoc filter. As you can see, for example, in this tutorial, this allows me to directly use RST roles and directives in the markdown cells. This replaces your use of HTML tags in Warning-Boxes, and also allows for use autodoc/intersphinx links like :py:class:`MyClass`.

Any questions you have, feel free to get in touch.

[mgeier]

Don't worry, it's OK to copy some code from nbsphinx, since you are giving proper attribution.

the nbconvert mechanisms (template and execution pre-processor) are somewhat hardcoded into the parser.

I know. Actually, I see this as a temporary implementation detail.
I hope to be able to implement spatialaudio/nbsphinx#36 at some point, which will let me completely drop the whole template-based stuff, and generate the internal docutils representation directly.

The preprocessors would still be useful, probably I can make them more configurable at some point.

Splitting up the code into separate files.

Sure, that's just a matter of somebody finding the time and energy to do that.
I started with a single .py file, which seemed somewhat advantageous in the beginning, but now I agree that separate files would make more sense.

Implementing my markdown -> RST ipypandoc filter.

In the future, I'd like to avoid both RST and pandoc.
I would like to use an extensible Markdown (or CommonMark) parser and implement an AST -> docutils transform.
This will allow arbitrary syntax extensions.
But I don't know if/when this will happen ...