Twine links should adhere to linebreaks about spiner HOT 4 CLOSED

This could be solved in at least two ways, depending on the current behaviour and limitations of the current API.

1. The TwineLinkParser could be edited to explicitly check for a newline and modify the TwineLinkNode to add a new line during rendering.
2. Or possibly the newline is already included as parse of the next but ignored due to the renderer. In this case it would be possible to translate any newlines to <br />.

First options is preferred, though further investigations is needed.

from spiner.

Currently all links are handled by the WikiLinks parsing feature of Pegdown. Using the custom TwineLinkParser is not possible because parser plugins appear to be called after link parsing, and thus the links are parsed as reflinks instead.

I've tried subclassing the Parser to override this behaviour, but that does not appear to be possible, see sirthias/pegdown#54.

This behaviour by Twine is not valid markdown. In order to solve this properly this has to be changed at the parser level because otherwise the linebreaks (which do not mean anything in valid Markdown in this context) are lost.

from spiner.

I checked the different Twine story formats and it turns out that each story format handles their own markdown parsing. And all but snowman appear to just replace all newlines with <br /> while Snowman appears to be the only one that actually adhere to the markdown "spec".

For example:

In Markdown it is possible
to write on several lines, but
in the rendered result is should be one single line.

This allows you to treat you text as if it were code.
And use the practice of having one sentence per line.

When rendered should appear as

In Markdown it is possible to write on several lines, but in the rendered result is should be one single line.

This allows you to treat you text as if it were code. And use the practice of having one sentence per line.

Because even different Twine story formats are not consistent I don't think fixing this even on the parser side it a good thing because not we need to know which template we're using. I don't think it's a smart idea to take templates into account, because that can easily break when using custom templates, or when the templates are updated.

It appears that one of Markdowns major flaws, lack of spec, strikes again. A quick search for a couple of editors shows several that behave differently:

from spiner.

In order to keep the burden on the complexity of the code down the only solution I'm comfortable with at this point is to do the following based on a custom option (it is up to the user which behaviour they want):

• Somehow replace all linebreaks with <br /> (this is what Harlowe does, because it renders the custom HTML tags directly, no <p> are ever used)
• Only replace single linebreaks with <br /> so that proper <p /> tags are still used.

I think it's best it should default to replacing linebreaks in order to support the majority of the default Twine templates.

So I've created a new issue #49 in order to support custom options. I've also created a new issue #50 to signify this decision, it that describes the LINEBREAK behaviour as described above.

from spiner.