Yes, this is missing in TiddlyWiki wikitext

#1

Folks,

Unfortunately I have wasted years trying to seek change due to a particular bugbear of mine. I am also confident it causes problems for new users. Let me illustrate rather than explain.

[edit] for clarity I make another attempt to demonstrate the problem below

Line one
Line two
Line three

Renders as

Line one Line two Line three

I can treat each line as a sentence, ie break at the end of the line using say bullets;

* Line one
* Line two
* Line three

It basically renders as expected

In fact most (if not all) wikitext markup that starts with a character at the beginning of a line treats it as a sentence until it reaches \n end of line. However all transform the line in someway and to generate space above or below the line.

In the following example I suggest having a “dot sentence” but of course another character unlikely to appear at the beginning of the line could be used.

. Line one
. Line two
. Line three
.Line one
.Line two
.Line three

which would render as;

Line one
Line two
Line three
Line one
Line two
Line three

This should also allow us also to add the .classname after the character as is possible for most wikitext

.Line one
..classname<space>Line two
.<space>Line three

I will just leave this suggestion there and ask if anyone can see the need and value in such an extension to wikitext markup where we have no way to indicate a line is to be treated not as just a continuation of the above line nor a paragraph but an in between, a simple “sentence”.

Background
I think I mistakenly asked for a “dot paragraph” before, I do not want this.

which would render as;

Line one

Line two

Line three
1 Like
#2

Wrapping the text in triple double quotes will maintain the line breaks (https://tiddlywiki.com/#Hard%20Linebreaks%20in%20WikiText). Have you considered using that feature?

#3

Thanks, but yes I use that feature when appropriate, I can even use alternate word wrap and other methods, I do however believe I am pointing out a clear gap in the wiki-markup you can’t turn a simple line into a line without a blank line, nor can you add a classname.

As an author we can just use a whole range of markup on any line, even headings ! or !! but there is no way to treat a simple line.

#4

Somehow your post is both clearly written and difficult to understand at the same time. Is it a request for a feature? And is the request to introduce a specific row-prefixing character that makes soft linebreak at the end of the sentence be treated as hard linebreaks? (I would like this too.) Or do I completely misunderstand what you’re after?

What does this paragraph mean:

If it refers to that you’re using a prefixing dot in your previous text… why don’t you just correct the previous text instead? And why are there double space lines in the list?

Did you see pmarios space-space-newline ?

#5

@twMat I have being going around in circles for a long time on this; Thanks for reading.

The mentioon of dot paragraph is only to contrast it with prior discussions. Sorry if it is confusing.

Sorry you don’t follow but I reviewed it and the post is consistent, if not clear.

I had asked in the past for a “dot paragraph” the leading dot would cause each line to become a paragraph, whilst it stops the wrapping it inserts a blank line in between each “paragraph”, I specifically do not want this.

At the moment I am trying to see if I can explain the problem, or gap and open to solutions. However it is my view we need an additional wikitext markup character that can be placed on any line resulting in no wrap, and no blank lines between instances. I have kept it open since perhaps someone has a trick that is equivalent.

As opposed to using the various wordwrap a new wiki-markup character also allows the application of a class to that “line”.

I hope that is clearer?

#6

Agreed. (With some minor additions, that sentence would make a good intro for your OP to immediately “frame” what the post is about.)

But wasn’t it @pmario and you that experimented with custom wikitext markup about a year ago? The project was very promising but in the end it was decided to use special characters to trigger the markup, and I’m sad to say this was a showstopper for me because those characters are too inconvenient (which kills the whole point with markup, i.e speedy and distraction free typing). But maybe that is a thread to pick up for your request here?

But, regardless, I agree that it should be provided natively, as you imply. I don’t think the specific choice of a dot . is a good one since it interferes with the existing syntax to apply styles, as you also bring up. Maybe a prefixing comma could be better? (Incidentally the difficulty in deciding on good characters was, if I recall, also why the custom wikitext experiments ended up with such special characters, i.e requirement of backward compatability made it difficult to start interpreting common characters in new ways.

#7

Yes to all you say. The custom markup is great an I hope to use it extensively. It can be used to achieve this except I can enter it at the keyboard. Thats OK for sophisticated custom markup, but not for what I see should be “basic behaviour”.

Here I am, interested in suggesting this is a clear gap and needs a native solution.

#8

custom-markup plugin is still experimental

There are some characters, that are easy to type and are part of default layouts. custom-markup uses some “free block markers” that should be part of many keyboard settings.

  • English and German keyboard settings should have fast access to: degree..(°) and tick..(´)
  • Other users may have possibilities to use single (›) and angle (Âť) because they need them in other software
  • And there are some “exotic” approx (≈) and pilcrow (Âś) which can probably only be created with keyboard shortcuts or buttons.

As a user, you can choose and only use those, which work for you (I did have to start with something, that has a “remote” chance to be useable)

There aren’t much characters left, which can be used without causing problems with the existing wikitext syntax or prose text. eg: We can’t use paragraph (§) or double paragraph (§§) as markers, because they are heavily used by juristic texts. …

Due to the lack of variation, I did implement a possibility to “name” those markers called glyphs. eg:

°list some text  ........... and

°xlist some other text

Those 2 can be interpreted as 2 different markers and can have a different output. … and so on.

Advanced wikitext users expect, to be able to add classes to wikitext. eg:

°list.myClass.anOtherClass some text

So we need to consider this. The following is possible with custom-markup.

°.myClass some text .......... or
´.myClass some more text

That’s very close, to what @TW_Tones describes, it just doesn’t use a dot at the beginning. …

Adding classes and different names start to become messy and a lot to type, if you want to user “self describing” class names. That’s why c-markup allows you to define some defaults, with eg:

\custom degree=myBox _classes=".indent.right-dedent.justify.cbox.cbox-primary"

Then we can use the above example like so:

°myBox Some text, which is covered in a blue box.

Which will look like this, if all the style-sheets are set in the right way.

grafik
grafik1297×429 22.6 KB

The latest version of c-markup allows to configure the “glyphs”(=°) … BUT … it introduced a performance hit and using a dot as a glyph broke the code.

2 Likes
#9

Spot-on.

I love @pmario’s Custom Markup system.
It is likely inevitable, I think, that you need new markers for new functions.

FYI, I have been happily using it to evolve bespoke layouts very efficiently. Plus the ability to use it for markup and simultaneously apply macros is ace.

Side comment
TT

#10

If no single character will work, why not a unique series of characters?

e.g. *@, ^#, ~.

Or possibly a rule at the top of the tiddler where the user could define which symbol they want, thus avoiding the land mines that eliminate the other possibilities?

I don’t recall the degree symbol ever appearing on any keyboard I’ve used. I would have to go spelunking for that.

1 Like
#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