Hi, There is one more problem with the <<qualify>> macro, which is different to your description. ... and I'll try to create a PR which fixes it soon.
*Problem*: Whenever an existing core utility uses <<qualify xxx>> macro human users are screwed, if they want to provide a "user state" which is already unique. ... eg: <<tabs>> macro. The tabs macro has a signature like this: \define tabs(tabsList,default,state:"$:/state/tab",class,template,buttonTemplate,retain) The default *state* parameter is set to $:/state/tab. This makes it convenient for new users, since they don't need to deal with state uniqueness. Later in the code it looks like this: <$button set=<<qualify "$*state*$">> .... ... <$reveal type="match" state=<<qualify "$*state*$">> ... But now the problem is: If I do want to call the tabs macro like so: <<tabs state:"human/predictable/unique/state" .... >> ... The tabs macro will screw it !!! This problem was introduced with the introduction of the <<qualify>> macro. .. What we need is <<qualify title:xxxx isUnique:yes>> which tells the macro, that the incoming title is already unique and it should use it. This won't solve your OP problems, but it may probably solve some for Tony's. I'll try to create a PR for this very soon. 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/5a2bd190-5ce9-4d46-8274-968666925ec2%40googlegroups.com.
