[tw5] Re: Inconsistency is so frustrating

[David Gifford]

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 davou...@gmail.com 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:  Here comes some 
>> bold text. 
>>
>> 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
>>
>> text 1
>> text 2
>>
>> 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 
>> . 
>> Hard-Linebreaks
>>
>> """
>> text 1
>> text 2 
>> """
>>
>> Which creates this: text 1text 2 which tells the browser 
>> to add line-breaks.  
>>
>> A second method to achieve a similar result is Hard linebreaks with CSS 
>> .
>>   
>> 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. 
>>
>> <>
>> <>
>>
>> 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 <> 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: Here comes some 
>> bold text. 
>>
>> 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
>>
>> <>
>> <>
>>
>> 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: aaa
>> The parser detects macro start / end in line 2, which will be rendered 
>> like this: bbb   
>>
>> 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)
>>
>>  - <>
>> <>
>>
>> and this b)
>>
>>  - <>
>>
>> <>
>>
>> 
>>
>> 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
>>
>>  - aaa
>> bbb
>>  
>>
>>
>>
>> add b) Now the  text and macro 1 belong together and macro 2 gets 
>> it's own block. 
>> HTML output
>>
>>  - aaabbb 
>>
>> 
>>
>> 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 

[tw5] Re: Inconsistency is so frustrating

[Louis Davout]

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:  Here comes some 
> bold text. 
>
> 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
>
> text 1
> text 2
>
> 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 
> . 
> Hard-Linebreaks
>
> """
> text 1
> text 2 
> """
>
> Which creates this: text 1text 2 which tells the browser 
> to add line-breaks.  
>
> A second method to achieve a similar result is Hard linebreaks with CSS 
> .
>   
> 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. 
>
> <>
> <>
>
> 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 <> 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: Here comes some 
> bold text. 
>
> 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
>
> <>
> <>
>
> 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: aaa
> The parser detects macro start / end in line 2, which will be rendered 
> like this: bbb   
>
> 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)
>
>  - <>
> <>
>
> and this b)
>
>  - <>
>
> <>
>
> 
>
> 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
>
>  - aaa
> bbb
>  
>
>
>
> add b) Now the  text and macro 1 belong together and macro 2 gets it's 
> own block. 
> HTML output
>
>  - aaabbb 
>
> 
>
> 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 tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/905b7ed9-3998-4a35-bf22-5c4ea63fb0c9n%40googlegroups.com.

Re: [tw5] Re: Inconsistency is so frustrating

[David Gifford]

Thanks everyone! Brian's macrocall solution worked great for me. And
everyone has done great at explaining how it works.

Now if I can just get that fix for edit-comptext config (see other thread),
world domination will be within reach!

If anyone wants to see what I am up to, check out
https://giffmex.org/experiments/det.template.html

It is similar to my recent hideme thing with the modal and link, but now as
a detail element with a link, so basically you can read it in a way similar
to Dynalist: outlines within outlines as far as you want, and open a
tiddler at whatever level you want to.

-- 
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 tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/CANE%3DBFJddbp0-tYGGNW7oFG8u0SfpiVRrvcsk_qHBN47cs1LOw%40mail.gmail.com.

[tw5] Re: Inconsistency is so frustrating

[PMario]

Hi,

I did create a little plugin that allows you to use "markdown-like"   
new-line markers at the end of the line. 

https://wikilabs.github.io/editions/space-space-newline/

So if you add 2 spaces OR 2 spaces and a backslash   at the end of the line 
you'll create a hard-linebreak. 

This behaviour is compatible with most markdown parsers. 

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 tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/a8107875-c76a-4105-875b-fc1205ad0284n%40googlegroups.com.

[tw5] Re: Inconsistency is so frustrating

[PMario]

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:  Here comes some bold 
text. 

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

text 1
text 2

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 
. Hard-Linebreaks

"""
text 1
text 2 
"""

Which creates this: text 1text 2 which tells the browser to 
add line-breaks.  

A second method to achieve a similar result is Hard linebreaks with CSS 
.  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. 

<>
<>

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 <> 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: Here comes some 
bold text. 

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

<>
<>

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: aaa
The parser detects macro start / end in line 2, which will be rendered like 
this: bbb   

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)

 - <>
<>

and this b)

 - <>

<>



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

 - aaa
bbb
 



add b) Now the  text and macro 1 belong together and macro 2 gets it's 
own block. 
HTML output

 - aaabbb 



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 tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/777abd37-9df9-4b28-a5da-db1af00172dbn%40googlegroups.com.

[tw5] Re: Inconsistency is so frustrating

[TW Tones]

David,

Perhaps you did not realise that your macro may be introducing the line 
feed you do not want?. Do share a simple example to discuss.

   - Further this issue has being there since TW5 one long term solution in 
   progress using custom mark-up where you decide how paragraphs and line 
   breaks are handled. it originated in an idea I called the .paragraph, to 
   force a paragraph, the opposite to what you are asking.
   - Buttons and macros can make use of the "\whitespace trim pragma for 
   some cases
   - You can also use CSS in some cases

If you install the core internals plugin, the preview includes a html view, 
this can help identify where line breaks creep in\ with a little 
understanding of html, primarily the difference between inline and block 
html tags.

Regards
Tones

On Sunday, 11 July 2021 at 09:27:39 UTC+10 David Gifford wrote:

>
> So if I type
>
> Line of text
> Line of text
> Line of text
>
> It will show in view mode as
>
> Line of textLine of textLine of text 
>
> Unless I separate each line with a second carriage return or a 
>
> But if I type
>
> <>
> <>
> <> 
>
> it renders as 
>
> Text of macrocall
>
> Text of macrocall2 
>
> Text of macrocall3 
>
> Unless I change it to 
>
>  <> <> <> 
>
> In the first example, lines get smooshed together unless I do something 
> unnatural to separate them. In the second example, macro calls get pulled 
> apart from each other unless I smoosh them together in edit mode in a 
> visually unappealing way. 
>
> What does TiddlyWiki have against single-spacing? Why does it either jam 
> items together or pull them apart? What if I want 
>
> Text of macrocall 
> Text of macrocall 
> Text of macrocall 
>
> With no space in between them? But I don't want edit mode to be illegible 
> with macrocalls all piled up on each other?
>
> Okay, rant over! Feels good to get that off my chest... :-)
>

-- 
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 tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/9b42af63-4e5a-4aa2-8767-a8e7f7a7b39fn%40googlegroups.com.

Re: [tw5] Re: Inconsistency is so frustrating

[David Gifford]

Very helpful explanation, Charlie, thanks!

On Sat, Jul 10, 2021, 8:18 PM Charlie Veniot  wrote:

> G'day David,
>
> I'm thinking what you're running into is the nature of HTML, and not so
> much the nature of TiddlyWiki.
>
> In HTML, to have the following appear as separate lines, you might have
>
> Line of text
> Line of text
> Line of text
>
> or each line of text wrapped in HTML elements that force  to happen,
> for example:
>
> Line of text
> Line of text
> Line of text
>
> To avoid all of these HTML tags, wikitext from various wikis (I think)
> will take two carriage returns as meaning a line break.  That shelters folk
> from having to deal with HTML tags so they can focus on just the content.
> Wikitext is not WYSIWYG.  WYSIWYG, I'm thinking, would be really messy, or
> have loads of potential for messy.  Having the editor side-by-side with
> preview is a good compromise, I think.
>
> Aside: Often, a bunch of stuff that ought to be displayed on one line,
> there is an advantage of having that long line broken up into different
> lines in the editor, to make editing the long line easier (kind of like
> chunking the elements of that long line of text.
>
> When one does want to get a bit more control formatting, then that control
> comes in via HTML (and/or CSS for some real formatting power.)
>
> Well, I didn't get any training on any of that.  Just my yellow-belt
> understanding from observations.  Food for fodder...
>
> On Saturday, July 10, 2021 at 8:27:39 PM UTC-3 David Gifford wrote:
>
>>
>> So if I type
>>
>> Line of text
>> Line of text
>> Line of text
>>
>> It will show in view mode as
>>
>> Line of textLine of textLine of text
>>
>> Unless I separate each line with a second carriage return or a 
>>
>> But if I type
>>
>> <>
>> <>
>> <>
>>
>> it renders as
>>
>> Text of macrocall
>>
>> Text of macrocall2
>>
>> Text of macrocall3
>>
>> Unless I change it to
>>
>>  <> <> <> 
>>
>> In the first example, lines get smooshed together unless I do something
>> unnatural to separate them. In the second example, macro calls get pulled
>> apart from each other unless I smoosh them together in edit mode in a
>> visually unappealing way.
>>
>> What does TiddlyWiki have against single-spacing? Why does it either jam
>> items together or pull them apart? What if I want
>>
>> Text of macrocall
>> Text of macrocall
>> Text of macrocall
>>
>> With no space in between them? But I don't want edit mode to be illegible
>> with macrocalls all piled up on each other?
>>
>> Okay, rant over! Feels good to get that off my chest... :-)
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "TiddlyWiki" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/tiddlywiki/RoTA7OJFMMg/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> tiddlywiki+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/tiddlywiki/df1a00ac-3895-4061-a228-c72fe49990d3n%40googlegroups.com
> 
> .
>

-- 
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 tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/CANE%3DBFJyi3q%3DxMX3eQNGj1U4H8DWC1mJpwfQhSPN3R2N4mp8jA%40mail.gmail.com.

[tw5] Re: Inconsistency is so frustrating

[Charlie Veniot]

G'day David,

I'm thinking what you're running into is the nature of HTML, and not so 
much the nature of TiddlyWiki.

In HTML, to have the following appear as separate lines, you might have

Line of text
Line of text
Line of text

or each line of text wrapped in HTML elements that force  to happen, 
for example:

Line of text
Line of text
Line of text

To avoid all of these HTML tags, wikitext from various wikis (I think) will 
take two carriage returns as meaning a line break.  That shelters folk from 
having to deal with HTML tags so they can focus on just the content.  
Wikitext is not WYSIWYG.  WYSIWYG, I'm thinking, would be really messy, or 
have loads of potential for messy.  Having the editor side-by-side with 
preview is a good compromise, I think.

Aside: Often, a bunch of stuff that ought to be displayed on one line, 
there is an advantage of having that long line broken up into different 
lines in the editor, to make editing the long line easier (kind of like 
chunking the elements of that long line of text.

When one does want to get a bit more control formatting, then that control 
comes in via HTML (and/or CSS for some real formatting power.)

Well, I didn't get any training on any of that.  Just my yellow-belt 
understanding from observations.  Food for fodder...

On Saturday, July 10, 2021 at 8:27:39 PM UTC-3 David Gifford wrote:

>
> So if I type
>
> Line of text
> Line of text
> Line of text
>
> It will show in view mode as
>
> Line of textLine of textLine of text 
>
> Unless I separate each line with a second carriage return or a 
>
> But if I type
>
> <>
> <>
> <> 
>
> it renders as 
>
> Text of macrocall
>
> Text of macrocall2 
>
> Text of macrocall3 
>
> Unless I change it to 
>
>  <> <> <> 
>
> In the first example, lines get smooshed together unless I do something 
> unnatural to separate them. In the second example, macro calls get pulled 
> apart from each other unless I smoosh them together in edit mode in a 
> visually unappealing way. 
>
> What does TiddlyWiki have against single-spacing? Why does it either jam 
> items together or pull them apart? What if I want 
>
> Text of macrocall 
> Text of macrocall 
> Text of macrocall 
>
> With no space in between them? But I don't want edit mode to be illegible 
> with macrocalls all piled up on each other?
>
> Okay, rant over! Feels good to get that off my chest... :-)
>

-- 
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 tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/df1a00ac-3895-4061-a228-c72fe49990d3n%40googlegroups.com.