Yes, PMario, I concur with davou's comment, that your description was very helpful. My apologies to you, PMario, for not thanking you sooner for your patient and thorough reply that must have taken some time to write out. What a friendly gesture. Blessings to you!
On Monday, August 9, 2021 at 12:32:22 PM UTC-4 [email protected] wrote: > PMario, > > Thanks for this explanation. It was very helpful. > > On Sunday, July 11, 2021 at 10:06:08 AM UTC-4 PMario wrote: > >> Hi David, >> >> I hope you feel better now ;) >> >> So the only thing I can do here is : Try to explain how the parser >> algorithm works, so that you can see, why it behaves the way as it does. >> >> =========================== >> >> The tiddlywiki parser knows 2 types of rules >> >> - block rules and >> - inline rules >> >> For the whole tiddler content it always starts with "block mode" and >> starts to "scan" for "block rules". If a block is found it switches to >> "inline mode" and starts to look for "inline rules". ... I call this the >> "context" here in the post. >> >> Here comes some ''bold'' text. >> >> It detects the whole text as a paragraph "block" ... which will be >> rendered like this: -> Here comes some *bold* text >> >> As HTML code it looks like this: <p>Here comes some >> <strong>bold</strong> text.</p> >> >> The P element defines the "block" >> The ''bold'' wikitext is an *inline-rule* per definition. >> >> That make sense. right? >> >> -------------- >> >> So the question now is, how does the parser detect different blocks of >> text, to create paragraph tags around them. ... We all know this rule: 2 >> NewLines .. will split 2 text elements into separated paragraphs. >> >> eg: >> >> paragraph 1 >> >> paragraph 2 >> >> That makes sense. right? >> --------------------- >> >> text 1 >> text 2 >> >> Doesn't contain 2 new-lines but 1 ... It's inline mode and it will be >> translated to the following HTML code >> >> <p>text 1 >> text 2</p> >> >> You can see the new-line is still there BUT HTML ignores whitespace per >> specification. ... So the browser shows the text like this >> >> text 1text 2 >> >> So it's not a TW problem, it's the browser that follows the rules. ... >> TiddlyWiki has a wikitext rule to compensate this problem >> <https://tiddlywiki.com/#Hard%20Linebreaks%20in%20WikiText>. >> Hard-Linebreaks >> >> """ >> text 1 >> text 2 >> """ >> >> Which creates this: <p>text 1<br>text 2<br></p> which tells the browser >> to add line-breaks. >> >> A second method to achieve a similar result is Hard linebreaks with CSS >> <https://tiddlywiki.com/#Hard%20Linebreaks%20with%20CSS:[[Hard%20Linebreaks%20with%20CSS]]%20[[Hard%20Linebreaks%20with%20CSS%20-%20Example]]>. >> >> Which works well for wikitext. It may cause problems with macros and >> widgets. >> >> ================================ >> >> You may say: BUT the following macros only have 1 new-line between them. >> >> <<macrocall>> >> <<macrocall2>> >> >> I say: Yes, you are right. ... But *macros *and *transclusions *have to >> be able to inherit the mode from their context. ... eg: >> >> \define bold(text) ''$text$'' >> >> Here comes some <<bold bold>> text. >> >> The parser starts at line 1 character 1 and detects some text. The "end >> marker" for text blocks is .... 2 new-lines >> After the block of text is detected, it switches to *inline-mode*. >> >> It detects the macro within this context, so the macro is rendered in >> inline mode. >> >> The text is translated to the following HTML code: <p>Here comes some >> <strong>bold</strong> text.</p> >> >> That's what we expect. Right? >> >> ---------- >> >> As written above macros and transclusions do inherit the mode from their >> context. >> >> Back to your example: Let's have a look at the "context" here. ... >> >> \define macrocall() aaa >> \define macrocall2() bbb >> >> <<macrocall>> >> <<macrocall2>> >> >> The context is the whole tiddler body, which starts as block mode. >> Then the parser detects the start << and the end >> of a macro in line >> 1. ... There is no other info >> The mode is still block mode, that's why the macro is rendered in block >> mode like this: <p>aaa</p> >> The parser detects macro start / end in line 2, which will be rendered >> like this: <p>bbb</p> >> >> That may not be, what you expected, but the behaviour is consistent. >> Humans may see the 2 macros as 1 block. ... The wiki parser does not. >> >> Try this a) >> >> xxxx - <<macrocall>> >> <<macrocall2>> >> >> and this b) >> >> xxxx - <<macrocall>> >> >> <<macrocall2>> >> >> ------------ >> >> add a) You can see that it detects some text in front of macro 1. So >> macro 1 and macro 2 will be part of the text block and will be rendered in >> inline-mode >> HTML output >> >> <p>xxxx - aaa >> bbb >> </p> >> >> >> >> add b) Now the xxxx text and macro 1 belong together and macro 2 gets >> it's own block. >> HTML output >> >> <p>xxxx - aaa</p><p>bbb</p> >> >> -------------------- >> >> If you compare the HTML output with my descriptions, you will see the >> algorithm is consistent. ... BUT it may not always be what we expect. >> >> I hope my descriptions are good enough to show how the "block" and >> "inline" detection works. >> >> have fun! >> mario >> > -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/258ab8ed-f2c7-4046-b0fd-02a636335f2en%40googlegroups.com.
