Illustration of four different "modes" of wikitext expansion

I have written some documentation explaining different ways WikiText will be processed depending on where it appears.

My goal is to eventually submit a PR so it will be included on tiddlywiki.com

I feel this information is required for all but the most basic authoring of wikitext.

I’m looking for feedback on accuracy, styling, understandability.

Download this tiddler and drop it onto tiddlywiki.com:

illustration showing which TW syntax gets wikified.json (4.3 KB)

Or read this screenshot of the result:

While writing this, I noticed that I’m not able to find any documentation for inline and block mode at tiddlywiki.com.

2 Likes

Hi @btheado,
I really like your work on this subject, as it would have been so useful for me when I started using TW, and it would still be useful now :slightly_smiling_face:
I find your idea of color code meaningful and concise.

While writing this, I noticed that I’m not able to find any documentation for inline and block mode at tiddlywiki.com .

Yes, definitions and related examples for inline and bloc mode would be perfect additions to your article.
I’d love to translate your work for the French edition of tiddlywiki.com when it’s ready for publication.

Thanks for your work !

Fred

I think your representation may be critical for your own (and some others) tiddlywiki learning process however the terminology is not exactly the same as TiddlyWiki’s. This translation from one set of terms to another is valuable but we must be cautious not to confuse things. as a result I do not think in this form it should go on TiddlyWiki.com where we use tiddlywiki terminology only. Your content may be best posted as a guide to tiddlywiki, and yet linked from tiddlywiki.com. See the existing community resources.

Perhaps constructive criticism of your content includes;

  • The use of “no” the negative, at the beginning of sentences. Making the negative the subject of the sentence rather than the thing you are actually talking about.
  • I am not sure you use of the word recursive is as meaningful as it should be, truly recursive, calls itself. I think “transclusion” is the appropriate word in many of your examples.

No attribute values enclosed by quotes are wikified:

May be better as;

Attribute values enclosed by quotes are NOT wikified

Have a look at my previous work which is a superset of what you have raised Tones GitWiki — For Designers from TW Tones (AKA TonyM) and the links to related tiddlers, which is yet to be updated with improvements in recent versions.

In fact if we could collaborate on expressing your ideas, the differences that is, in my content, and in tiddlywiki terms the result will be helpful.

Please do not be discouraged by my feed back, documenting tiddlywiki from different perspectives is important for new user adoption however the only way to strengthen existing terminology is not to confuse it with other terminology so we need “translations” and guidance rather than undermine existing terminology.

Your contributions are valuable.

1 Like

This old thread includes a definition of sorts for inline and block modes:

@TW_Tones, thanks for the feedback.

I think this information in some form makes the most sense on tiddlywiki.com so it can be interlinked from the relevant documentation and easily discovered.

Thanks, good idea. I made this change in my local copy. I only found the one example you pointed out.

Something akin to recursion is going on. A recursive function can directly call itself. Also a function it calls might call the original function and I consider that also to be recursion. Basically if a function gets called and is called again before it returns, then it is recursion.

During the process of parsing/rendering WikiText, more WikiText might be encountered (i.e. transclude widget, macrocall widget). An additional round of parsing/rendering takes starts before the original parsing/rendering finished. That’s why I used the term recursive.

Regardless, I think I agree that “recursive” is not a good term to use here. I just wanted to highlight the difference between full WikiText expansion and the only-retrieve-the-value that goes on with attribute parameters.

I’ll think about this more…this part definitely needs improved.

This looks useful, thanks. I haven’t seen it before.

It may be, however much of this is already documented on tiddlywiki.com, and it should use the exact terminology to be included. As I said however this is valuable first to you because it is in terms you are familiar with and others who use the same terms, but how big an audience will find one way better than another, and how do we not confuse those who understand the terms differently?

Will you help me by identifying the specific terms I’m using differently?

Having written it, I’m having a blind spot here. My guesses on what terms you might mean:

  1. Recursive - already acknowledged this is a poor choice
  2. wikification?
  3. others?

Forgive me but I don’t have time at this point, I have a complex issue for a client to resolve, and unfortunately for me what you ask may be difficult for me.

Let me explain, The problem for me is I am not sure I follow the way you communicate the information. I have other ways I understand the same things you address. As I said before “your way” may be quite relevant to others perspective but not to mine, or how I understand tiddlywiki.

It would help if you defined your terms, and then checked that they matched those on tiddlywiki.com

An example is
! only inline wikitext is expanded here

I am not sure what this means because what is excluded here since the following also works ?

! {{transcluded}}
! <<varname>>
! <<macro parm>>
etc...

Then you have
<<mymacro "literal text" <<no_macro_expansion>> {{no_transclusion}}>>

But this works from a recent version;

\define amacro() result
\define mymacro(p1 p2 p3)
$p1$ $p2$ $p3$
\end
<<mymacro "literal text" "<<amacro>>" {{transcludeme}}>>

or with
[then<single_level_macro_expansion>]

We can now use parameter’s
[then<single_level_macro_expansion p1 p2 "p 3">]

The only way I can see being able to help you myself is if you go back to the key information you want to present so I/we can check its valid then see where it may already be documented and summarise it (as you seem to be doing).

Or perhaps your text has too much assumed knowledge and could be more verbose to “spell out” the meaning, with less reliance on color highlights and “titles” like “single_level…”, “inline only” etc…

Thanks for the feedback. I need to think on it more.

1 Like

Yes that may help but please continue to contribute we value it.

Different perspectives are important, and especially by and for those in the learning phase, because new users come from many perspectives.