Hard linebreaks while entering lists in WikiText

I often edit my tiddlers in VIM rather than the browser form editor. An issue I run into though is when entering lists such as below:

A paragraph with a bunch of text.  That eventually gets hard
wrapped at some column. A paragraph with a bunch of text.

* A list item with a bunch of text that eventually gets wrapped at a
  column and then continued.
* A list item with a bunch of text that eventually gets wrapped at a
  column and then continued.
* A list item with a bunch of text that eventually gets wrapped at a
  column and then continued.

A second paragraph with a bunch of text.  That eventually gets hard
wrapped at some column. A paragraph with a bunch of text.

Expected/desired HTML output is something like:

<p>
A paragraph with a bunch of text.  That eventually gets hard wrapped at some column. A paragraph with a bunch of text.
</p>

<ul>
<li>A list item with a bunch of text that eventually gets wrapped at a column and then continued.</li>
<li>A list item with a bunch of text that eventually gets wrapped at a column and then continued.</li>
<li>A list item with a bunch of text that eventually gets wrapped at a column and then continued.</li>
</ul>

<p>
A second paragraph with a bunch of text.  That eventually gets hard wrapped at some column. A paragraph with a bunch of text.
</p>

But what I see (edited for clarity) with the TiddlyWiki WikiText is something like:

<ul>
<li>A list item with a bunch of text that eventually gets wrapped at a</li>
</ul>

<p>column and then continued</p>

When rendering with markdown or asciidoc, the above markup works as expected.

When rendering with TiddlyWiki’s WikiText the list starts a new paragraph whenever a newline is encountered after the * character. Is there a way to force WikiText to include the continued list-item text as the same list-item?

(As an aside, I’m going to look into switching to soft-wrapping approaches in vim to see if that is an alternative viable approach).

To follow-up on configuring my vim setup to match WikiText, I’ve found the following useful:

Vim-pencil enables writing with “soft wrap” enabled navigation and viewing while in vim.

Goyo allows the window view to be customized at various character widths. (Similar to latex’s default viewport of ~64 characters for ease of reading/writing.)

1 Like

Hi,
The behaviour you describe is a “special case”, that was not part of the initial markdown specification, which was never standardised. So some companies defined their own “markdown flavour”

The commonmark specification, which is the official spec for text/markdown defines hard linebreaks as “2 spaces” at the end of the line or \ at the end of the line.

That’s not “beautiful” but works.

I did create a little plugin, that adds this behaviour to the TW parser See: Wikilabs Home — A home for: Plugins, Editions and Themes!

The \ rule in my plugin is different to commonmark, but still works with commonmark. If you copy wikitext with contains space space backslash into a TiddlyWiki, without the plugin, you will see the \.

So I recommend if you use TW wikitext use “space space newline” which also works fine if copied to other TWs. … There will be no hard linebreak, but at least there is no \ artefact.

There is a reason, why HTML ignores whitespace. Because we don’t know, where the text is shown. It may be a wide PC screen or a small mobile screen. So it should be possible for the device to define the text flow.

Manual hard linebreaks may create “bad” visual results with small screens. … So hard line breaks should be only used if “really” needed.

Thanks @pmario for the responses. I updated my original question to hopefully make it more clear.

The “paragraphs” are rendering as I expect when going from WikiText to HTML. The hard line breaks are ignored in the WikiText and continue the same HTML paragraph.

The “list items” do not translate from WikiText to HTML as I hoped. When in a WikiText list item a hard line break in the wikitext source causes the list item to be ended and a new paragraph started.

For example, the behavior I’m seeing is:

* list item

Renders as expected, as shown below:

  • list item

But compared to Markdown and Asciidoc, the following

* list item
with a hard linebreak in wikitext 

Translate to the below with a hard line break in the resulting HTML:

  • list item
    with a hard linebreak in wiki text

An example of the behavior I was used to seeing came from Complex List Items | Asciidoctor Docs

…while I personally like to have a human fixed formatted wikitext source, getting my vim editor to perform the wrapping sounds like a more portable and better solution.

* list item  
with a hard linebreak in wikitext 

or

* list item  \
with a hard linebreak in wikitext 

And it does what you want. Be aware in the first example, there are 2 spaces at the end of the first line.

It also works with a commonmark editor. See: commonmark.js demo

1 Like

Umm… I wonder how this (or some modification of it) could make TiddlyWiki to support Semantic Breaks as Markdown and AsciiDoc does, particularly inside lists. That would mean that using

* A list item that contains several complex ideas
  with line breaks inside
  would be showed as a single paragraph/item

Would be showed like this:

So the behavior of HedgeDoc, with hard breaks disabled, and AsciiDoc would be the same regarding multiline lists items.

Using semantic breaks has been a way of improving my writing as I can break long text by ideas, internal “soft” enumerations inside them and so on. With paragraphs in WikiText it works pretty well, but with bullet/number list, enclosing the contents in <div></div> becomes cumbersome, even when used with macros (for example when the item includes macros). For example, I have a <<li """item text"">> macro that surrounds """item text""" with div delimiters, but when the item text contain macros (<<li """item <<myMacro>> and more text"">>) the syntax highlighting is disabled (after the first >>).

@offray, your with semantic breaks and how markdown/asciidoc handles them is what I was intending.

I’m not familiar with the WikiText (parser?) yet, so I haven’t started looking at the code.

I’m also not sure – but would this potentially be a breaking change for other WikiText that expects a line break to start a new paragraph?

I’m wondering if pmario’s solution where “space space newline” could be used as a continuation rather than a hard line break in list items.

1 Like