I’m not sure anybody mentioned it in this thread: Probably in the very next update to TW there will be new mechanisms that make macros much more similar to functions.
1 Like
Oh heck no, I don’t see it as you being wrong.
More lead astray by both from-experience-preconception of “macro” and documentation that isn’t quite as clear as it could be. (That’s the nature of documentation: not an easy thing to do.)
That’s the problem with words. They often already have a meaning in a certain context. To reuse the same words to mean something else in a different context, that gets confusing.
Like the word “widget”. Totally throws me off my game. So I don’t use that word anymore.
Instead: “GUI Controls” (or “Controls” for short) and TwScript. I need my tidy groupings…
1 Like
macros & recursion are what I meant, but you make good points.
Is it the same way the JS Macros work?
I think macros were probably misnamed in TW5. The idea was to match the usage in Excel, Word etc., but I think it has probably given rise to more confusion for developers familiar with macro preprocessors in programming languages.
5 Likes
Now I really wish I spoke Chinese! Many of these topics are things I still struggle with.
Using google translate, it’s like a Chinese version of grok. Though the plugin development page is better than any English one lol
1 Like
I think several of us recognize this. We just haven’t figured out how to get beyond it.
And it is improving. But I’m hoping to capture the learning experience well enough that I might be able to smooth the way for other developers trying to learn.
Easier said than done, even if well-supplied with Zen and Taoist koans. 
But I’m working on it!
Zen, Taoist Koans, Yoda…:
- Do or do not. There is no try.
- You must unlearn what you have learned.
- Fear is the path to the dark side. Fear leads to anger. Anger leads to hate. Hate leads to suffering.
- The greatest teacher, failure is.
Giggles aside:
Before attempting to create solutions to problems in TiddlyWiki, it is very good to get familiar with each piece individually. Understand how each piece behaves.
I’ve had better luck knowing the inventory of pieces via the documentation, and then tossing the documentation aside when understanding those pieces and how they behave.
Also, better to not relate the pieces and the words in the documentation to nothing you’ve seen/experienced before. No preconceived notions or expectations. Total naivete except for very generic analytical and problem-solving skills.
Often, documentation is like the game of everybody in a circle, whispering into the ear of the next person some story. By the time the end of the circle is reached, the final story doesn’t quite match up right with the beginning story.
2 Likes
This is something frustrating to me too.
I think the fact macros don’t behave like functions, is unintuitive and error-prone.
(And as GameDungeon, I am not thinking about something with the ability to run arbitrary JS code when I think of functions, I am just thinking about the way it deals with parameters and return value)
I also have difficulties with all the different ways to access variables or arguments or stuffs (&&, <>, __, …) and dealing with quotations, spaces, concatenation of string, etc…
There are probably good reasons for all of these, and probably a big part of my difficulties is that I still don’t grasp it well, but it is still, for me, unintuitive and error-prone (and also quite verbose), and the worst part of an otherwise amazing software.
Where tiddlywikis architecture is difficult for programmer’s to come to terms with, I believe it is much easier for non-programmer’s to come to terms with tiddlywiki than most program languages.
I sort of don’t believe it. I think dealing with wikitext/macro/widget, etc… is quite technical.
(This is just a feedback about how this part feel to me, I am not saying it should change, I really don’t understand it well enough to have any advice)
2 Likes
The problem is we all come to it with our own backgrounds, there are multiple entry points and perspectives. It is hard to imagine the naïve perspective and quantify the learning journey. But we can always help with documentation and improvements.
My key argument is as a programmer, Software Dev, you may have to “unlearn somethings” before you “learn others” 
My procedural programming experience certainly caused some difficulties for me.
To me it seems there is divide here between “modern” (i.e. younger) programmers and older programmers. TiddlyWikis macro system is not so different to C/C++ #define preprocessor macros.
Case in point:
Like C #define macros, TiddlyWiki macros are not functions. Said another way, it’s usually a mistake to confuse similarity in syntax with intentions and purpose.
I’ve been hearing this anecdotally since I got more seriously involved with TW. I know of no hard evidence. But I mostly do believe it. I remember when Markdown was first starting to spread. Those who knew HTML seemed to have a harder time learning it than those who didn’t: “Where’s the nesting?!”
So I can easily believe that we programmers simply have more to unlearn. I would guess that part of it is that we have learned to expect great things from our tools, and we expect our tools to be flexible, but mostly in certain specific ways. TW may be flexible in others that we haven’t yet considered.
Unfortunately, this barely alleviates the frustration of not learning as fast as we would like.
Personally I have not had much trouble finding equivalents in wiki text for things I know in programming, some years ago I even wrote some documentation such as addressing sequence, iteration, selection and recursion in tiddlywiki.
- Where I have had difficulty is accommodating various little quirks that complicate and break otherwise resonable assumptions.
- Many of these have being improved with the evolution of tiddlywiki but I suspect still too many remain, for which I know understand, but will cause new users to stumble.
Just having a code highlighter that respected all html/tiddlywiki open and close tags would halve the syntax errors I have to deal with.
1 Like
In Tiddlywiki 5.3.0 this can be implemented using the recursive functions as below
- Open TiddlyWiki Pre-release — 5.3.0-prerelease
- Create a tiddler with below content
\define m(n1:0 n2 sep:" ")
<<__n1__>><<__sep__>>
<$let n1={{{ [<__n1__>match[0]then[1]else<__n1__>] }}}>
<$let n1={{{ [<n1>add<__n2__>] }}}>
<$list filter="[<n1>subtract[1000]sign[]match[-1]]">
<$macrocall $name=m n1=<<n1>> n2=<<__n1__>> sep=<<__sep__>> />
</$list>
</$let>
<$let>
\end
\function .fib(n1:0, n2)
[<n1>match[0]then[1]else<n1>]:map[<currentTiddler>add<n2>]
:filter[<currentTiddler>subtract[1000]sign[]match[-1]]
:map[.fib<currentTiddler>,<n1>]
:else[<n1>]
\end
<<.fib>>
<<m>>
produces
987
0 1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987
The recursive function generates the last number of sequence, while the m macro by @pmario produces the whole sequence. I think the reduce and accumulator may help here, but I think the code gets more complex.
1 Like
I just want to say that those plans have fallen by the wayside as most of my after-work programming time has been caught up by the periodic table demo I’ve been doing. But I’m still keeping notes on this, and hope one day to get back to it.
I know this is from a while ago and I’m somewhat necroing a dead thread, but I thought I would say something about this.
This you mention here is precisely the problem.
People say they are like #define macros, but they don’t implode from recursion. They clearly don’t behave like preprocessor macros, and statements like this are misinformation adding to the confusion.
But at the same time, they don’t behave like functions either, as one would expect from the macrocall syntax and it being the normal alternative to macros.
The best I could describe them is a “Preprocessor macro that is interpreted instead of compiled”, which is a very foreign concept to most programmers and might actually be at the core of the issue. It’s something a term does not really exist for. Additionally feeding the flames is the fact that this is a point that is basically never explained.
1 Like
I don’t see how that furthers understanding anymore than my half-assed attempt to bridge the gap – there is no preprocessor in TW.
Perhaps I should have said “akin to”, rather than “not so different to”. Either way, the point I was trying to make is that TW macros, like #define macros, operate as a text replacement mechanism. Reading anymore into the analogy (like most analogies), doesn’t survive deep analysis.
^Z
1 Like
If it helps any, this is the mindset I crank on when using macros in TW, to overcome the things that used to trip me up all of the time.
First, these are text-substitution macros. That’s it, that’s all. (Well, the snippet of text is a template, in which parts can be different based on values provided with the macro reference. Much like a form letter and mail merge thingy.)
Next, I never say macro call. I say macro reference. There is no “call”.
Where there is a macro reference, that macro reference gets replaced by the snippet of text defined for that macro.
The widget “macrocall”, treat it as just a label (with no more meaning to it than if it were called “xyz”). It is just the name of the widget with which you are setting up a macro reference.
It is much easier to train your mind to think this way than it ever will be changing the widget name. For backwards-forwards compatibility, that widget name should never never never change.
4 Likes
One of the issues is, however you define these terms they need to include the fact that they are “rendered” at “display time” and will update if triggered by a change in the “widget Tree” (may not be correct term).
- This fundamental aspect of TiddlyWiki is like an interpreter, where its own code can change whilst it is interpreting, then its reinterpreted.
- After more than a decade with TiddlyWIki I think we may need to stop arguing the details and just accept that its different in tiddlywiki. Such that simple macros gain a new level of power.