Making macro and any other syntax compatible with the code updating on passage name change

[Philip-Sutton]

This issue relates to an interaction with Twine 2. I'm using v 2.3.16 (desktop)

Twine 2 auto updates links and some other code across the whole project when the author changes a passage name.

I've run some tests and found that any links or other code using the [[...}} syntax will be updated, but any code with the passage name in double quotes is not updated. I've tested this with three macros: <<include>>, <<goto>> or <<button>>.

I'm guessing that twine 2 was designed to update passage names in square brackets and not in double quotes because it would not be easy (possible?) to change code with the passage name in double quotes but not change non-code text that coincidentally had the passage name words in quotes?

Would it be possible to revise the sugarcube code syntax so that all of it could be auto-updated by twine when authors change passage names?

I've systematically searched the sugarcube documentation and (unless I've somehow missed cases)) all the code that mentions passage names offers two formats - [[...]] and "...". So would it be possible to deprecate the "..." options? This would then mean that twine 2 passage change auto-updating would be 100% effective???

(I did a search in the issues list to see if there was anything there already related to this issue. I didn't find anything.)

[greyelf]

Deprecate the "..." options for known macros that take a Passage Name as an argument wouldn't get around situations like the following...

<<set _passage to either("Library", "Study", "Kitchen">>

<<include _passage>>
<<goto _passage>>
<<run Engine.play(_passage)>>
<<run Dialog.wiki(Story.get(_passage).processText())

...as how is the Story Format mean to know that the String values being passed to the either() function are actually Passage Names.

Potentially the is the possibility of adding a new 'data-type' to the engine that represents a Passage Name Reference, and enforcing the usage of it on the Authors, but that would still require a means for letting the Twine 2.x application know how to handle it.

I would also hesitate in using the Mark-up based link syntax for that representation because currently there is no way to tell the Twine 2.x application not to create a "connection arrow" in the Story Map for a Passage Name reference that doesn't lead to a Passage Transition. Thus the linking of the map would become more complex than it already is, and as it's the drawing of those "connection arrows" that are one of the main things that influence the slow-down of the map more is not necessarily better.

[tmedwards]

I've tested this with three macros: <>, <> or <>.

In future, please use the markdown code markup for inline examples or code fences for block examples so they aren't eaten by the system.

 

So would it be possible to deprecate the "..." options? This would then mean that twine 2 passage changeautoupdateing would be 100% effective???

All built-in macros that want, or can take, a passage argument will accept the link markup. No one is being forced to use the separate text/passage argument format, so I'm not seeing the problem or a compelling argument here.

Beyond that there are cases where using the link markup is suboptimal—e.g., when using variables—so having an alternative is nice.

Additionally. Some people don't like the connection arrows, for various reasons, so….

[Philip-Sutton]

Thanks.

Is there then any way for twine/compilers or story formats to somehow warn authors on passage name change that they cannot reply on the auto name change process to pick up all references to the old passage name?