[Bug] mixing \procedure with \define from 3rd party plugins seems to cause problems

[pmario]

This issue is related to Revert "Migrate some old macros to new syntax" #9160

I did create an issue, so it is not forgotten.

The PR: Migrate some old macros to new syntax #8768 did update some macros to the new \procedure syntax.

What I found out so far:

• core tiddler: $:/core/macros/list has a procedure: list-tagged-draggable
• list-tagged-draggable has a default action \procedure list-tagged-draggable-drop-actions(tag) that defines the actions, that happen, when an element is dropped.
• If a 3rd party plugin like Projectify -> $:/plugins/nico/projectify/macros/todo-list overwrite this drop-action, there is something wrong with the __variables__ eg:

The projectify drop actions look like this:

• The __tag__ is missing in the action-log
• so variable order is empty.

So the tagging with new tags fails, what was reported.

\define todo-list-drop-actions(tag)
<!-- Same as list-tagged-draggable-drop-actions, but removing the item from its old project and adding the todo tag. -->
<$action-listops $tiddler=<<actionTiddler>> $tags=<<todo-list-drop-tags>>/>
<!-- Save the current ordering of the tiddlers with this tag -->
<$set name="order" filter="[<__tag__>tagging[]]">

<$action-log/>

I do not know, where this comes from atm

[pmario]

@Jermolene -- Does the OP ring any bells for you?

[Leilei332]

I wonder whether we can enable a "legacy mode" for specific procedures to make them behave like macros (like variables with underscores), like those with a $:/tags/Macro tag.

[pmario]

@Leilei332 -- As I wrote. I am not sure yet.

The Projectify macros are quite complex and I do not fully understand them atm. I think, I did find a "strange" behaviour that I described in the OP. So some more experiments will be needed. I'll try to create a "minimal testcase", which should be much simpler. But I have to be sure first.