Twine links should adhere to linebreaks

[mrombout]

Summary

Spiner places all twine links on a the same line even when separated by linebreaks. Instead it should place them in a new line.

[[Enter the cold cave|Page17]]
[[Enter the windy cave|Page8]]
[[Walk up the trail|Page12]]

Expected behaviour

The following markdown syntax in Twine:

[[Enter the cold cave|Page17]]
[[Enter the windy cave|Page8]]
[[Walk up the trail|Page12]]

Should translate to something along the lines of:

<a href="">Enter the cold cave</a><br />
<a href="">Enter the windy cave</a><br />
<a href="">Walk up the trail</a><br />

Actual behaviour:

The example above translates to the following:

<p>
  <a href="">Enter the cold cave</a>
  <a href="">Enter the windy cave</a>
  <a href="">Walk up the trail</a>
</p>

[mrombout]

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.

[mrombout]

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.

[mrombout]

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.

---

Story format	Adheres to MD
Harlowe 2.1.0	No
Harlowe 1.2.4	No
Snowman 1.3.0	Yes
SugarCube 2.21.0	No
SugarCube 1.0.35	No

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:

Editor	Adheres to MD
https://jbt.github.io/markdown-editor/	Yes
https://dillinger.io/	No
https://stackedit.io/editor	No

[mrombout]

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.