Fixed v5.3.0 backward compatibility for macrocalls

[flibbles]

Okay, after I got done sulking about it, it wasn't too hard to make the new macrocalls backward compatible with the old ones. This makes plugins (or Relink anyway) function without needing to migrate anything for v5.3.0.

The tests are failing. I know. I wanted to make sure this is acceptable before reconciling the tests.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
tiddlywiki5	✅ Ready (Inspect)	Visit Preview	Jul 20, 2023 3:04am

[flibbles]

Went ahead and reconciled the tests anyway.

[Jermolene]

Thanks @flibbles. The fact that this fix keeps the Relink plugin working seems like it might be an implementation accident. I'm not certain that this fix would necessarily be much help in general because it would appear to only work for code that doesn't check the node type. Any code that is explicitly checking for the type of macrocall will fail, and any code that knows how to deal with transclude nodes will fail because of the unknown $variable attribute. What do you think?

[flibbles]

I wouldn't have thought so. If we have a plugin that works exclusively with the parseTreeNode, I'd figure it would see a transclude and then look for the attributes and orderedAttributes which will be there. If they're dealing with a macrocall, I don't even think macrocall parseTreeNodes exist anymore, do they?

I'm not sure how it handles because Relink and Uglify don't come at it from the parseTree. They create new methods to attach to each of the wikiparser rules, because working exclusively with the parseTree would lose a lot of important context. Relink, for instance, won't muck up any indentation you had between your widget attributes, but it can only do that if it's dealing with the wikitext, not the parseTree.

As v5.3.0 left, Relink definitely couldn't rely only on the parseTree, because macrocall syntax become transclude nodes under the hood, and there's no way to determine that they had been in the <<macrocall>> syntax from the node alone. It has to look at the wikiparser rule that called it.

Maybe Relink and Uglify are unique from other plugins that way. It works with text, and thus the wikiparsers, while maybe everyone else only looks at the parse tree.

Still, does the introduction of two legacy properties really cause parseTree manipulating plugins to break? Genuinely asking. I only know of how Relink and Uglify does it, and I don't know about any other plugins that do text manipulation like they do.

[flibbles]

I mean, if nobody else is having trouble with the fact that macrocalls now turn into transclusions under the hood, then I can fix Relink to cope with both pre and post v5.3.0. And we can overlook backward compatibility in this case. I'd probably just write a method to add the "name" and "params" properties myself if they're not already there.

[flibbles]

I now agree with you that this PR is insufficient, seeing as how I've discovered a few more of my plugins which fail for the exact reasons you described.

I will close this. And honestly I'm not sure how to fix this problem. Macrocalls are now transcludes. That's kind of a huge change.

As far as I can tell, I'm the only person who's been bothered by the v5.3.0 release. Maybe I can just migrate the last of my plugins.

[Jermolene]

Hi @flibbles over on the forums I made a couple of proposals that might improve the situation, and I'd be interested in your views.

The particularly galling thing is that I understand that you have extensive tests for the relink plugin. So, it does seem like it would be a good idea to run 3rd party tests like yours as part of our CI process. Perhaps it would be easier to manage running the tests if they were part of a centralised community plugin library

The other suggestion that has occurred to me is to introduce an intermediate set of parse tree node types that represent syntactic constructions (so there would be a distinction between all the different wikitext shortcuts for the transclude widget). These intermediate types might be named with a special prefix like “@inline-transclusion”, “@pragma-define” etc. Then we would need a process for mapping those syntactic node types to the actual rendered widget nodes that we use at the moment.