Inconsistency is so frustrating

[David Gifford]

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 <br>

But if I type

<<macrocall>>

<<macrocall2>>

<<macrocall3>>

it renders as

Text of macrocall

Text of macrocall2

Text of macrocall3

Unless I change it to

<span> <<macrocall>> <<macrocall2>> <<macrocall3>> </span>

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... :-)

[Brian Radspinner]

The shorthand for macrocall wraps everything in <p> elements, so you get the auto linebreaks. As an alternative, you can use the <$macrocall /> widget:

[David Gifford]

Cool! Thanks Brian, I will experiment with that!

--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/5819bf41-2fba-456b-9c3d-36c292558e8an%40googlegroups.com.

[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<br>

Line of text<br>

Line of text<br>

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

<p>Line of text</p>

<p>Line of text</p>

<p>Line of text</p>

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

[David Gifford]

Very helpful explanation, Charlie, thanks!

--

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+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/df1a00ac-3895-4061-a228-c72fe49990d3n%40googlegroups.com.

[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

[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:  <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. 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.  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

[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

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

[Louis Davout]

PMario,

Thanks for this explanation. It was very helpful.

[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!