Yes, this is missing in TiddlyWiki wikitext

#11

I interpret this to mean “choose any from this limited set”, right? As opposed to “choose freely”. Sadly, all the ones you mention are too inaccessible for me.

But degree ° is also used by some people. And I’m sure ticks ´ are too. So why can’t § be an option? If it conflicts with ones usual character set then the user can choose another one, as per your options. Personally I have never used § in a real sense (and this sentence doesn’t count) but the character even has its own key on my keyboard, so it would be absolutely superior!

1 Like
#12

I think that the fundamental issue here is the way that TW5 allows single line breaks within paragraphs, and requires a double line break to terminate a paragraph. Back in 2011/12, I copied this behaviour from the original Markdown:

https://daringfireball.net/projects/markdown/syntax#p

A paragraph is simply one or more consecutive lines of text, separated by one or more blank lines. (A blank line is any line that looks like a blank line — a line containing nothing but spaces or tabs is considered blank.) Normal paragraphs should not be indented with spaces or tabs.

Since then, GitHub Flavoured Markdown and other variants have risen in popularity, all of which interpret a single line break as the end of the paragraph.

It’s one of those things that’s hard to change without breaking backwards compatibility. Rather than a new syntax, my preferred resolution is to be able to able to create custom vocabularies where authors can pick and choose the rules that they want to use in a given tiddler. There is some discussion of the idea here:

1 Like
#13

Thanks for the details. They really help put the issue in perspective.

I agree that “custom vocabularies” are far better than potentially making backwards-compatibility issues. All those other systems do the blank line thang and will be around forever too.

The point for me, end-user, is merely, what markup system helps me most on this job?

TBH, @pmario’s approach in Custom Markup solved, for me, any issue I ever had—including the “line-end” issue.

TT

#14

When @pmario worked on this we debated this endlessly.

I guess it is still open?

MY final take was that …

1 - Keyboards have limits on cross-hardware availability
2 - But do you need a keyboard explicit key if you can insert markers via keyboard shortcuts?

Being slightly weird, I did traverse the Unicode universe for traditional manuscript markup symbols available but @pmario, sensibly, declined the offerings.

TT

#15

Another approach my be to have an alternative tiddler type or editor in which the user can assign alternative and custom markup. In fact there are so many ways apart from my aforementioned “dot sentence” or “dot line” it is not funny.

I would appreciate a Content<newline><newline> resulting in a paragraph, and <newline> resulting in a “new line” no spaces etc… during parsing. If for no other reason to facilitate live note taking and pasting content from elsewhere.

However beyond this solution there is no way to introduce a class or behaviour to another wise simple line in tiddlywiki with a prefix - this is in my view the gap.

If there was a special character that the parser used to instead wrap the current line in a <div> we would be there

eg

! my text becomes <h1 class="">my text</h1>

if “&” only at the beginning of the line were that special character imagine

&my text becomes <div class="">my text becomes</div>
& my text becomes <div class="">my text becomes </div>
&.classname my text becomes <div class="classname">my text becomes</div>

#16

A somewhat related conversation is here Best way to handle lists/items (ul, ol, li)?

#17

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:

Capture

And also

<<<
hello
there
<<<

Produces:

Capture2

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.

1 Like
#18

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>.
#19

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.

1 Like
#20

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

#21

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.

1 Like
#22

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”.

1 Like
#23

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.

1 Like
#24

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.

#25

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

#26

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

#27

In the same vein I commonly do this;

;next actions

  • act1
  • act 2
#28

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?

#29

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

#30

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

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”.