-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Twee 3 spec: leading and trailing space in passage names #19
Comments
I've always considered Twine 2 allowing surrounding (leading/trailing) whitespace a bug. Twine & Twee v1 don't allow it, so it's always been a surprise to older users. As to the Twee v3 specification. The lack of explicit allowance of surrounding whitespace in the passage name section and the header whitespace handling rules do imply that surrounding whitespace is not significant, there only to separate the header components. There's no way to change the spec to allow surrounding whitespace in passage names without breaking something, which I am emphatically not in favor of. That said. The least breaking change that could allow such would be to explicitly allow surrounding whitespace in the passage name section and use the escapement rules to encode them. |
I also consider leading and/or trailing white-space to be invalid, and especially meaningless when encounter within a TWEE Notation based project. |
I can't imagine a situation where it would be both useful and intentional to distinguish between passage names based on any whitespace (never mind leading or trailing whitespace), rather than just being a result of author/UI error. An added trim() or two in the UI seems preferable to letting users attempt to sow chaos with leading or trailing whitespace, though it doesn't solve the whole problem. |
I was curious, and it seems Twine 1.4.1 also allowed leading and trailing space in passage names. But it's not something I would encourage, either. I also agree, escaping the spaces seems like the safest course. |
Looking over the spec, something that isn't mentioned is how to handle leading or trailing space in a passage name. I know it's not best practice to put either in a passage name, but people do (came up in discussion here) and I think the spec as it's currently written would cause that whitespace to be lost, and links to potentially break as a result.
Wondering if this is worth documenting in the spec or if there is a recommended workaround.
The text was updated successfully, but these errors were encountered: