This pull-request validates passages used in these places:
Argument links/images.
Parameters that take passage names. (Such as <<link text passage>><</link>>)
This does not cover normal in-text links, only handling those passed in through arguments to a macro.
This is a Warning rather than an error because having incomplete paths through a story is not uncommon, and thus is intended at times.
The images showcases where it currently succeeds at.
You may notice the window.garbage and the [[garbage]] link part. This is a necessary false-positive for the common use-case. Since the input to the link can be arbitrary TwineScript (thus translated to JavaScript..), we can not 100% validate whether or not it is meant to be a passage name or a TwineScript string. (We can validate whether it is a passage name, because of SugarCube just using the given value as the passage name if it exists then validating it, but we're trying to provide warnings about invalid ones).
So to support the really common case of doing [[MyPassageName]] over [[MyGlobalVariable]], this treats single Barewords as if they were intended to be passage names. As shown in the image that would result in a false-positive in that case. There is a setting to disable the single Bareword being treated as if it is meant to be a passage name, for if a user is doing something strange.
As well, mentioned by the link beneath that, it does not currently handle [[Oh My]], where it is meant to be a passage name to a passage with a space in it. The single bareword handling somewhat just falls out of the basic Twinescript conversion regex from SugarCube, but handling space separated would be somewhat more complex and so is not done in this Pull Request.
The PR is broken into smaller commits, of which they are not the most sensibly ordered, but all build up to the PR.
A future goal would be to extend this to inline passage name validation, but I have no clue how challenging extracting the links from the documents would/will be.
This pull-request validates passages used in these places:
<<link text passage>><</link>>)This does not cover normal in-text links, only handling those passed in through arguments to a macro.
This is a Warning rather than an error because having incomplete paths through a story is not uncommon, and thus is intended at times.
You may notice the
window.garbageand the[[garbage]]link part. This is a necessary false-positive for the common use-case. Since the input to the link can be arbitrary TwineScript (thus translated to JavaScript..), we can not 100% validate whether or not it is meant to be a passage name or a TwineScript string. (We can validate whether it is a passage name, because of SugarCube just using the given value as the passage name if it exists then validating it, but we're trying to provide warnings about invalid ones). So to support the really common case of doing[[MyPassageName]]over[[MyGlobalVariable]], this treats single Barewords as if they were intended to be passage names. As shown in the image that would result in a false-positive in that case. There is a setting to disable the single Bareword being treated as if it is meant to be a passage name, for if a user is doing something strange.As well, mentioned by the link beneath that, it does not currently handle
[[Oh My]], where it is meant to be a passage name to a passage with a space in it. The single bareword handling somewhat just falls out of the basic Twinescript conversion regex from SugarCube, but handling space separated would be somewhat more complex and so is not done in this Pull Request. The PR is broken into smaller commits, of which they are not the most sensibly ordered, but all build up to the PR.A future goal would be to extend this to inline passage name validation, but I have no clue how challenging extracting the links from the documents would/will be.