inline element with block treatment

[vshesh]

Motivation

There are elements that visually appear to be inline elements, but are in fact block style elements.

Concrete example: headers

Headers are block level elements and need to be treated as such by the parser. However, writing

---header 2
Overview
...

Is major overkill for such a simple element.

Options

command line style interface.

eg, the first line of the module syntax as it already stands. It needs it's own invocation syntax though, so splitblock can parse it out.

#! header 1 Overview

It's technically easy to implement but looks ugly and strange visually in the document. There's also no flexibility to define it another way; you're stuck with looking like you're running a shell command whenever you do this.

Custom syntax that spans exactly one line.

Limited to one line to disallow users from defining multiline styles which effectively mimic some dialect such as markdown. It may not be a problem to allow users to do a multiline version since the registries allow adding/removing of any element, but I just feel like allowing arbitrary inline styles to be treated like blocks is opening up a huge can of worms that will end in lots of regex conflicts and the like. Plus, it completely distracts from the benefits of having a standardized block syntax - everyone will go off and invent their own.

Harder to implement (by a little, I suppose) - the sub-style parser is the only block level parser affected by this - the others don't really care what's going on. parseinline would have to be modified to return a strings for the text portions and dictionaries for the extracted/parsed sections, so something like:

>>> parseinline(Standard, Paragraphs, 'text *bold*')
['text ', {'elem': Bold(...), 'html': ['strong', {}, 'bold']}]

There is a small danger of implementing a custom AST doing this process, but I think it's relatively safe since the information of the element is contained inside the element itself, so it's all the users's defined element and stuff. Also, it would be good to standardize this with splitblocks, which currently returns ['block call string', 'body text'] instead of something more descriptive like {'elem': Katex(...), 'args': [...], 'text': '...'} which could be more useful.

List of technical changes:

1. Inline element needs a display property that can be BLOCK or INLINE.
2. splitblock returns dicts
3. parseinline returns dicts
4. postparseinline uses dicts
5. postparse uses those dicts too.
6. parseblock updated so that the non-SUB nesting branches just pluck the html from the returned trees.

If the dicts include the element, it will be easy to decide whether to make a [||1||] or [|1|] out of it for block SUB style nesting.

[vshesh]

Ok, instead of returning dicts, which are very verbose, I'm now returning tuples, which are easier on the eyes, eg (Bold, [strong, {}, text])

[vshesh]

fixed in f9f5ad91c3388695e4e8a4cbb11cb4bac3fcf3de