Inline structures (literals and roles)

[masklinn]

Builds on #19.

[masklinn]

At this point, the test case completely fails:

• Text wrapping is not applied correctly as inlines are within a paragraph but not a text
• Spaces aren't inserted between a piece of text and the following inline construct => foo *bar* becomes foo*bar*
• Odd newlines insertion, might be related to current spacer state

[benoitbryon]

I feel the writer uses wrong design to rebuild the document out of the nodes:

• currently, when it visits or departs a node, it tries to convert it directly to an output string... But sometimes it needs something from the context, or something that is not available yet. We could implement things, but it would require bunches of tricky conditions on spacer and wrapper. Too bad. Poor readability.
• what if the writer worked on a tree? Visits and departs could re-create nodes, then the tree could be inspected to generate the right ouput.

As examples:

• Contiguous inline nodes could be concatenated with a space, then wrapped. Instead of each being wrapped and concatenated with tricky spacer conditions.
• in bullet lists, first we would generate the content (which can include nested lists), then apply wrapper and spacer rules, then add the bullet.

I feel that this design would make the writer much easier to implement... provided we find a readable way to do this.
@masklinn: what do you think about it?

I once tried to implement it for the lists... but failed to get it quickly :(
It could be a separate (and high priority) ticket. This one would depend on it.

[masklinn]

I feel the writer uses wrong design to rebuild the document out of the nodes:

Yes I've got similar issues, it feels like trying to hammer round pegs in square holes.

We could implement things, but it would require bunches of tricky conditions on spacer and wrapper. Too bad. Poor readability.

And requires lots of odd special cases, it also makes things much less composable: "parent" nodes need to set up odd contexts in order to get their children to (unwittingly) do the right things, it's very brittle.

Contiguous inline nodes could be concatenated with a space, then wrapped. Instead of each being wrapped and concatenated with tricky spacer conditions.

Yeah I started going that way (paragraph was the only one applying wrapping after collecting its children), but I think I was in too deep (and had broken all vertical spacing between paragraphs and paragraph-containing nodes) so I reverted everything.

Spacers actually ended up being a much bigger problem than line-wrapping: most block-level nodes (all of them but titles IIRC) don't hold text directly but hold paragraphs which do the text-holding (for all inline structures), so if the paragraph can capture its inline content it can easily wrap everything cleanly. But the interaction of spacers between nested block-level nodes didn't work out.

I feel that this design would make the writer much easier to implement... provided we find a readable way to do this. @masklinn: what do you think about it?

Worth a try