Yes, this is missing in TiddlyWiki wikitext

[markkerrigan]

I think @TW_Tones is asking to have a way to implement this feature of Markdown

When you do want to insert a <br /> break tag using Markdown, you end a line with two or more spaces, then type return.

Yes, this takes a tad more effort to create a <br />, but a simplistic “every line break is a <br />” rule wouldn’t work for Markdown. Markdown’s email-style blockquoting and multi-paragraph list items work best — and look better — when you format them with hard breaks.

For example, with the use case of a block quote, in TiddlyWiki,

> Hello
> There

Produces:

And also

<<<
hello
there
<<<

Produces:

While in Markdown it appears as two consecutive lines rather than two separate paragraphs. (fenced blockquotes generally not a common feature of Markdown flavors.)

Hello
There

And terminating each line with 2 spaces in TiddlyWiki also doesn’t do anything, unlike in Markdown, which would produce the expected behavior:

Hello
There

I agree the current existing linebreak interpretation is not intuitive (and is not the same as TiddlyWikiClassic) and isn’t always a match to the expected behavior, as if wikitext were Markdown. Line breaks are strict (2 lines to separate paragraphs), unless wrapped in fenced """. Original Markdown is not as strict, later variants (GFM) have become more strict, but current TiddlyWiki syntax does not allow a way to bypass the strict behavior (and what Anthony is proposing is a syntax to allow this).

While I do think this is a worthy issue, I would rather TiddlyWiki syntax remain rather strict as it is still forgiving in the sense that even if you put more line breaks than is necessary in wikitext, it will not produce extra line breaks in the output.

[TW_Tones]

I appreciate you support.

Good arguments suggest we need to accept the current behaviour now out of the box but all I ask is a way to do this seamlessly.

It is not as easy to read;

one<br>
two<br>
three<br>

we see to much

See above for Marios space space newline, my only concern is these are also too hard to see

What I ask for is only

• A legal character to place at the beginning of the line that is almost identical in the final result to using the “;” which is not bold and as does the “;” treats a line as a line, but introduces no additional whitespace, and provides the opportunity to add a .classname as I understand it it need only parse to a <div> rather than a <p>.

[TW_Tones]

All,

On windows 11 I have noticed the predictive text also presents icons or emoticons. This may be a way to introduce wikitext markup from the keyboard if only I knew how to manipulate it.

There are other solutions that work this way, perhaps I need to revisit those.

Unicode as used in “Custom markup” is also another avenue, all we need is a way to allow quick entry from any keyboard.

[TiddlyTweeter]

@TW_Tones

Unicode as used in “Custom markup” is also another avenue, all we need is a way to allow quick entry from any keyboard.

Definitely. Unicode is a forest but is very strict and reliable. Support is now good in browsers. The refractory issue is font support. A fairly simple safeguard solution is to create “a mini-font set” of markers that can be embedded directly in TW.

Just a comment
TT

[twMat]

@TW_Tones

A legal character to place at the beginning of the line that is almost identical in the final result to using the “;” which is not bold and as does the “;” treats a line as a line, but introduces no additional whitespace, and […]

Note that you can override the behaviour from “;” – or any wikitext markdown AFAICT – with CSS to make it appear as you wish. If you you rarely use definition lists, you could use the : and restyle to remove the indentation.

Using only a : (i.e the dd) actually automatically adds an envloping dl, so this works and I think it fulfills the formal syntactical needs for accessability etc:

:foo
:bar

<style> /* or in a stylesheet, of course*/
dl dd {margin-inline-start:0;}
</style>

Yes, you need to prefix every line with the character, i.e it doesn’t “sense” the soft linebreak, which is what you really wish for.

[TW_Tones]

@twMat

restyle to remove the indentation.

This is correct and it illustrates we just do not have a symbol that can be freely applied to “any other line”. Since the parsers default is to turn “any other line into a paragraph with wrapping” it would be nice to have one that defaults to a “div ending at new line with no wrapping”. Allowing us to add css with the .classname.

In the meantime I will use Marios “space space newline”, using the "space space \" when I need it visible. Then in more advanced cases the custom markup.

I plan to use custom markup to introduce a range of “presentation elements” when authoring content such as indent, assides, sections, info boxes etc… all with a simple “markup”.

[pmario]

@TW_Tones

I plan to use custom markup to introduce a range of “presentation elements” when authoring content such as indent, assides, sections, info boxes etc… all with a simple “markup”.

That’s, what it is intended to be used for.

As I wrote. The next version may have a possibility to define the symbol. So it should be possible to do this:

ASIDE some text.

Where ASIDE is the symbol, that used to be degree ° in my other examples. … I’m not sure yet, if it is possible to replace existing symbols like !, *, # and so on. It’s not a primary goal, to be able to do that.

[twMat]

@pmario

The next version may have a possibility to define the symbol. So it should be possible to do this:

Wunderbar! Even if the simplicity of a single symbol typically is desirable, I think it would be really cool with full string names (like `ASIDE) and creating complex styles/behaviours… in fact: just WOW! …CSS is pretty powerful and in combination with some programmatic behaviour (like breaking newlines) this really opens up possibilities.

[TiddlyTweeter]

@twMat

@pmario

The next version may have a possibility to define the symbol. So it should be possible to do this:

Wunderbar!

Wundercafé!

My experience with Custom Markup has been wholly positive. It works very well with extant TW and is extremely powerful. In my use cases I use it to deliver custom layouts and to easily access some HTML elements that normal TW Wikitext does not fully support.

In a way it is a “minority sport” but, overall, it is very liberating.

Cutting to the quick … I, for my use, want to be able to utilise the gamut of HTML elements in an easy way. Custom Markup makes that easy.

IF @pmario might allow arbitrary designation of the base markers I think it could be ace+.

Side comment
TT

[Springer]

On a best-practices note, I have recently been trying to wean myself from using this easy trick

:line one
:line two
:line three

… when I want a super-fast way to make line breaks behave as desired. Why resist this? Well, the resulting html from ; and : shortcuts is semantically bound to the defined-term and definition <dt> and <dd> tags. Not all of my wiki-making is public, but some is, and I want to be free to pull things over into public projects without second-guessing their accessibility.

Most occasions when I want simple line-breaks without extra space, I’m effectively making an unordered list (say, “thoughts while listening to this talk”). So figuring out how to make a whole tiddler, or part of a tiddler, display in this way ought to involve a variant on <li> tags, along with css that styles them without any bullets or indentation. (Or, more likely: we keep hanging indents in the css, so that the start of a new line is visually salient even when a long line wraps.)

-Springer

[TW_Tones]

In the same vein I commonly do this;

;next actions

• act1
• act 2

[twMat]

@Springer

trying to wean myself from using this easy trick

:line one
:line two
:line three

[…] without second-guessing their accessibility.

But in what way does that make it inaccessible? Is it that e.g a “voice reader” or other accessibility tool will read it out as a dt list but in your text it is not shown as such but merely appears as a list? If this is the distinction, when would this have any negative consequences?

[TiddlyTweeter]

Just an observation.

The whole layout thing here is also dependent on CSS.
Break control is well managed via CSS for all the spacing variants.

TBH I think this is a hot sweat looking in the wrong direction.

Just a comment,
TT

[TW_Tones]

@TiddlyTweeter I will respectfully disagree with what appears to be the minimisation of this problem that at least I recognise for myself.

@TiddlyTweeter

TBH I think this is a hot sweat looking in the wrong direction.

CSS can resolve issues especially for less common cases but there are few word processors or markup (as others reported) where being able to choose between a newline representing a “line” or “Paragraph” is not possible, at the keyboard and in the editor.

CSS often demands we wrap something, apply a class etc… which means we are forced enter css, remember a class name and have to nominate a beginning and an end, and in future make sure new items are placed inside or outside this wrapping. CSS also usually involves more than one tiddler. This although achievable is long winded, fiddly, requires memory/documentation and introduces some fragility.

Now if you are an author, wanting to produce a lot of content, just a little extra complexity will reduce productivity.

Problem statement follows (again)

I do think this is a glaring gap; show me the intermediate result in wiki text between
Text in the editor;

line one
line two
line three

Paragraph process appends and gives you
line one line two line three

<new-line><new-line> ie an empty line between. Gives you

line one

line two

line three

There is no option to simply type at the keyboard so you see the following;

line one
line two
line three

I just tried the <space><space><newline> of @pmario and unfortunately it itself is forcing two extra line breaks if you want wikitext recognised;

This is a sentence ending in space-space-newline  
* next item

Returns exactly what you see above and the * is not transformed into a bullet.

You need two empty line, yes two, before the bullet works defeating the value of space-space-newline in the first place.

Sure;

line one<br>
line two<br>
line three<br>
* next

The above gives the desired outcome but is this acceptable? 4+ characters, two needing shift to enter, to represent end of line? is somewhat ugly, and needs to also be applied to subsequent items inserted. Not to mention the next line not working as wikitext.

Sorry, but “something is not right, in paradise”.

[CodaCoder]

I’m not sure what I’m more surprised by in the following - that // and '' work, or that * etc don’t.

And no, placing newlines around the bullets does not affect the result.

Tones, you’re right. It’s a “gap”. I don’t foresee it changing either (based on something I recall Jeremy saying a long while back).

[TW_Tones]

@CodaCoder

I don’t foresee it changing either (based on something I recall Jeremy saying a long while back).

Yes, I have being down the “”“triple quotes”"" path before and saw the inconsistencies you do.

What I would like recognised, not how but that it needs to be resolved.

It is irrelevant, if it can or can’t be done using the core, the parser or any other obscure component or mechanism.

This is to me a clear usability requirement, if it needs a plugin, a hack, new type, an alternative view template, custom markup - one of dozens of different approaches available to us in tiddlywiki then so be it. If such a solution is not perfect then lets see if we can improve it, or live with it.

Also necessity is the mother of invention, so let us say “it is necessary”.

[CodaCoder]

Certainly stretches (if not outright fails) PLS - the principle of least surprise.

@jeremyruston care to jump in and explain the outcomes we’re seeing?

[btheado]

@CodaCoder

I’m not sure what I’m more surprised by in the following - that // and '' work, or that * etc don’t.

@CodaCoder

@jeremyruston care to jump in and explain the outcomes we’re seeing?

I’m not Jeremy, but I know the reason.

From https://tiddlywiki.com/#Block%20Mode%20WikiText:

The above WikiText types are only recognised in block mode . However, the text enclosed by most of them will be parsed in inline mode (Block Quotes in WikiText and Styles and Classes in WikiText are the two exceptions in which the parser will continue in block mode ).

https://tiddlywiki.com/#WikiText%20parser%20mode%20transitions attempts to explain when parsing mode transitions will happen. HTML element with a blank line is one way to get the parser to recognize block mode punctuation again:

"""
* not recognized as a list
* also not recognized as a list
<div>

* blank line following html element transitions to block mode and this list item is recognized
* and so is this list item
</div>
"""

These tiddlers show a lot of parser mode examples:

https://tiddlywiki.com/#Block%20Mode%20WikiText%20(Examples):[[Block%20Mode%20WikiText%20(Examples)]]%20[[WikiText%20parser%20mode%3A%20HTML%20examples]]%20[[WikiText%20parser%20mode%3A%20macro%20examples]]%20[[WikiText%20parser%20mode%3A%20transclusion%20examples]]

[CodaCoder]

[Springer]

twMat,

Yes: Universities and other institutions require employees to abide by accessibility norms for screen-readers whenever they generate public-facing html. And indeed, being told that one is about to hear a definition would be pretty annoying, if in fact that’s not what’s going on…

Meanwhile, I myself have decided to embrace semantic html anyway whenever possible (and to tweak my css as needed). After all, if my future self – or someone who inherits my project, etc. – decides to bring some fancy css to bear on things like definitions, abbreviations, citations, emphasis (whatever), it would be nice to know my tiddlers are not littered with gratuitous cosmetic uses of the corresponding tags for each of those information niches. (This is analogous to specifying named Palette-colors rather than hard-coding a color, to maximize forward-compatibility.)

-Springer