Passage renames don't affect story format-specific links

Philip-Sutton commented 2 years ago

Describe the enhancement.

I set up a test to see how twine 2.3.16 handles the cascading of passage name updates (in sugarcube 2.36.1).

Twine handles changes where the passage name appears in [[...]] brackets either as links or as arguments inside of macros. But where the passage name is included in double quotes in at least two macros <<include>>, <<button>> and <<goto>>

Steps to reproduce:

I set up a test twine project to test a range of macros and links to see where the passage name changes would cascade (or not).

Expected behavior:

That passage name changes would cascade to all code in a twine project.

Additional context on this problem.

Update links when passage name changes #851

Maybe story format developers could deprecate the "..." syntax in favour of the [[...]] syntax?

Twine version number

2.3.16

Does this problem occur with the web version of Twine or the desktop app?

Desktop app

What operating system does this problem occur on?

Windows

If this problem is occurring with the web version of Twine, what browser does it occur on?

No response

Presubmission checklist

[ ] I am interested in working on code that would fix this bug. (This is not required to submit a bug report.)
[X] I have done a search and believe that an issue does not already exist for this bug in the GitHub repository.
[X] I have read and agree to abide by this project's Code of Conduct.

greyelf commented 2 years ago

@Philip-Sutton For the "cascading of passage name" functionality to work it needs a clear definitions of what it a Passage Name, and where they can appear within the content of a Passage.

Currently the only place where Passage Names are known to found across all the different Story Formats that the application supports is the standard Markup based links... eg.

[[Link Text is the same as the Target Passage Name]]
[[Link Text->Target Passage Name]]
[[Target Passage Name<-Link Text]]
[[Link Text|Target Passage Name]]

... and this is because they are the only 'feature' that is common to all those story formats,

Because each of Story Format can define its own macro language syntax and its own list of core macros, and decide which of those macros take a Passage Name as an argument and which don't, it is difficult for the application to know which String "value" is a Passage Name and which isn't. eg. In the following (multi story format) passage content which instances of "Library" is a Passage Name and which isn't.

(link: "Open the red door")[
   (goto: "Library")
]
<<link "Open the red door" "Library">>

(set: _name to "Library")
(display: _name)

<<set $buildings to ["Guild Hall", "General Store", "Library"]>>
Map Legend: <<for _building range $buildings>><br>_building<</for>>

($CustomMacroThatDoesntTakeAPassageNameAsAnAgument: "Library")

Current there is no way for a Story Format Developer to indicate which macro arguments are a Passage Name Reference, nor can the project Author do that for any custom "macro" they create themselves.

Philip-Sutton commented 2 years ago

I raised this issue on the sugarcube github and there are some responses: https://github.com/tmedwards/sugarcube-2/issues/165

Philip-Sutton commented 2 years ago

If no automated changes are possible in twine (or the story formats), 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?

Philip-Sutton commented 2 years ago

Perhaps an alert could be added a bit like the alert when a passage name is about to be duplicated? But to avoid frustration by authors who have "got the message" perhaps this alert could have a way to stop it being represented every time?

klembot commented 2 years ago

This IMHO is an enhancement request, to allow story formats additional ability to tell Twine about where passages are referenced. We have the beginnings of this in the 2.4 betas with references, but going further than this will be difficult. Story formats would need to implement basically their entire templating language in an extension to be able to properly detect all names reliably. There are also performance implications on the Twine side--it seems natural to also draw passage connections based on this too, but that's a hot path for editor responsiveness.

As for an advisory message explaining this--perhaps? It's difficult because story formats use different terminology (SugarCube and Harlowe call things 'macros', Chapbook calls them 'inserts').

Philip-Sutton commented 2 years ago

Sorry about the inappropriate bug label.

Re the idea of an alert (that authors can 'retire' once they get the meaning of it), maybe the wording could avoid references to macros and inserts and other story format specific language? The advice could be more descriptive? Maybe something like: References to this passage elsewhere in the story/project will be auto-updated where they are in [[pageName]] format. Other references to the page in other formats eg. "pageName" will need to be changed manually using search and replace.

It would be good if the alert could also contain a button that sends the original name to Quick Find (which means that twine would need to remember the original name for the purpose of this operation).

Philip-Sutton commented 2 years ago

A random thought: Twee compilers can tell when they strike a passage name when they see the :: sigil (in the right context). Could passage names carry an additional sigil as part of the name itself so that passage names can be reliably processed automatically? Story format authors could modify their story formats so that the passage name sigil is not be displayed in the rendered output html file?

Is this idea related to what @Greyelf was talking about in the SugarCube github when referring to a Passage Name Reference? https://github.com/tmedwards/sugarcube-2/issues/165

Philip-Sutton commented 2 years ago

The sigil idea in my previous comment seems to be something that project authors can act on now - at least in some cases,

I've just run some limited tests and I found that I could include the twine link markup as part of the passageNames passed to variables. Then the passageName variables could be used naked to create or complete functional links. The nice benefit was that when the link passage name was changed, twine would update the content of the variables too.

klembot / twinejs