protected macros

[Jean-Pierre Rivière]

In a tiddlers tagged as #:/tags/Macro there is a public macro. It requires other macros to achieve its goals, but these macros have no business being used elsewhere.

If I declare these macros in the same tiddler, they are exported. Bad :-( To mitigate that, I have their name beginning with an underscore, meaning to me not to use them elsewhere.

But if two differentss macros tiddler both define their own _subMacro, what _subMacro would be called? the one in the same tiddler or maybe yes, maybe not, we can't say. This is the real problem.

same question if my macro tiddler has _myStuff macro and a non macro tiddler define a macro also called _myStuff and use it: which one would be called? That's a variation from the previous question.

I know I can have _mySuff macro into a separate non macro tiddler, and \import it within my macro tiddler. That way my macro tiddler is 100% functionaal and _myStuff is not exported but creating another tiddler is a problem in itself: it's yet another tiddler, it's not that a good idea because it's only there for a single tiddler, and I would need to have a name for it. It would complexify my naming convention which is already a lengthy paper... and I would have to decide which idea is the one I shall get. to be honest, my macro fubar for the foo matter is in $:/user/foo/macros/fubar. So where should _sub4fubar be ? $:/user/foo/macros/fubar/private would do but then $:/user/foo/macros/fubar would both be a file and a directory, whis is a no go. So no way to store anything below the macro name. $:/user/foo/privateMacros/fubar perhaps? or  $:/user/foo/private/macros/fubar ? I could have some macro for a bar filter in $:/user/foo/private/filters/fubar but then I don't have the same meaning for macros there than in the $:/user/foo/macros/fubar where "macros" tells that here are macros but in $:/user/foo/private/macros/fubar "macros" tells that this concerns a macro tiddler  named fubar but could be whatever, not especially macros (altgough very likely macros). And when the macro has no sub macros, the naming convention shouuld be the same: do not complexify 100% for the 10%. This rules out a scheme like $:/user/foo/macros/fubar/fubar and $:/user/foo/macros/fubar/_sub4fubar which would otherwise answer the question (but being a very ugly beast).

A suggestion: could we say that any macro whose name starts by _ or even __ for compatibility's sake, is not exported even within a macro tiddler?

[PMario]

On Tuesday, June 29, 2021 at 1:43:23 AM UTC+2 jn.pierr...@gmail.com wrote:

In a tiddlers tagged as #:/tags/Macro there is a public macro. It requires other macros to achieve its goals, but these macros have no business being used elsewhere.

If I declare these macros in the same tiddler, they are exported. Bad :-( To mitigate that, I have their name beginning with an underscore, meaning to me not to use them elsewhere.

But if two differentss macros tiddler both define their own _subMacro, what _subMacro would be called? the one in the same tiddler or maybe yes, maybe not, we can't say. This is the real problem.

No. That's a feature. This behaviour allows the core to define sensible defaults, that can be overwritten by the user at any time. As I wrote in the other thread.

\define xx() xx

is a shortcut for

<$set name=xx value=xx>

tiddler content

</$set>

So the local macro with the same name will always win!    If there is no local macro the predefined one will be used.

Global macros have an order. Typically they are initializes in alphabetical order by the tag. So if you have

title: a

tags: $:/tags/Macro

text: \define me() a

and

title: b

tags: $:/tags/Macro

text: \define me() b

For global macros the rule is: The last one wins

So yes. Your naming convention will influence the order, who macros are initialized. .. BUT since you know that now, you can use it for your advantage ;)

> A suggestion: could we say that any macro whose name starts by _ or even __ for compatibility's sake, is not exported even within a macro tiddler?

No, because this would be not backwards compatible. But you can use this convention if you like, but the system won't enforce it.

The way it is designed is consistent but not always obvious.

-mario

[PMario]

Have a closer look at: https://tiddlywiki.com/#dumpvariables%20Macro:%5B%5Bdumpvariables%20Macro%5D%5D%20%5B%5Bdumpvariables%20Macro%20(Examples)%5D%5D

and: https://tiddlywiki.com/#LogWidget:LogWidget%20ActionLogWidget

They may help you to see what's going on. .. The later 2 can only be seen in the browser dev console.

-mario

[Jean-Pierre Rivière]

Le mardi 29 juin 2021 à 02:47:35 UTC+2, PMario a écrit :

> A suggestion: could we say that any macro whose name starts by _ or even __ for compatibility's sake, is not exported even within a macro tiddler?

No, because this would be not backwards compatible. But you can use this convention if you like, but the system won't enforce it.

The way it is designed is consistent but not always obvious.

Today, global macros are tagged $:/tags/Macro but let's say I add an other tag $:/tags/NewMacro which is similar to the previous one, would it not be OK to have for NewMacro only that macros starting by _ are not global? That would not destroy any old code.

Whatever, now that I know that my locally defined macros are *always* prioritary, the need is lesser.

Many thanks for all your valuable help Mario!

[TW Tones]

Jean Pierre,

The tag $:/tags/macro is used when displaying tiddlers to include the macros you defined in each tiddler as its display. This is a global macro.

Another alternative is to use the  ImportVariablesWidget which allows to bring in definitions from elsewhere without them being global. It allows you to use a filter so you can also use your own tag such as  $:/tags/NewMacro. Of course the use of the import variable widget could be in a tiddler tagged view template in which case it may as well be global.

I am not sure I understand the rest of your post, please review these references and consider reframing the question.

My IT Support experience suggests to me, you are asking us to solve one problem you came across, perhaps while trying to solve another problem, and in fact you need to solve the first problem, not the latest. Lets call this a root cause we need to find.

Regards

Tones

[Mohammad Rahmani]

Hi Jean-Pierre,

 This is quite common in other programming languages! It is also possible in TW!

 Put all those sub-macros in another tiddler say $:/jean/macros/utility NOT tagged with $:/tags/Macro

 In the main macro after definition line (header) \import $:/jean/macros/utility

That's all! There are some good hints in TW-Scripts.

Best wishes

Mohammad

--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/fd8f1a78-196c-4508-837e-7c53580563e0n%40googlegroups.com.