Inline structures (literals and roles) #21

Open
wants to merge 7 commits into
from

Projects

None yet

3 participants

@masklinn
Contributor

Builds on #19.

masklinn added some commits May 14, 2013
@masklinn masklinn Move tests from tests/__init__ so unittest2's discover can find them
--HG--
rename : rst2rst/tests/__init__.py => rst2rst/tests/test_fixtures.py
1f89613
@masklinn masklinn Fix docutils 0.10 compat: error_reporting and math moved to docutils.…
…utils
a87cdd2
@masklinn masklinn Avoid intermediate list for unified_diff results 9c35385
@masklinn masklinn Revert expected and observed results in diffing
this way, removals and additions show the *errors* in the current output
61c9755
@masklinn masklinn Have each fixture be reported as its own test case
Allows checking multiple failing fixtures, and better reporting on
tests count.
9c3cee2
@masklinn

This makes it Python 2.6 only, not sure upstream will find it acceptable

masklinn added some commits May 15, 2013
@masklinn masklinn Remove default/empty visit/depart implementations
better to fail on them, if no-behavior is desirable should extend SparseNodeVisitor instead
a72c57c
@masklinn masklinn Start implementing inlines (literals & roles) 011c437
Contributor

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
@mgaitan

wonderful commit

@mgaitan

this should be a pull request

Owner

er. it was? benoitbryon#18

Owner

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.

Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment