Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
[Sugarcube] Quotation marks, or 'Speech marks'/Apostrophes not showing In Passage links
Here's something that's been on my mind for a while, but has more recently come forward as a more.. Threatening issue.
I have just done a test to confirm the validity of this error:
Will display in passage as:
Even though they all have quotation marks/apostrophes in the text, the only one that will show is the first iteration.
I had noticed this problem before but had assumed it was an error on my part. Now, I can't be so sure.. Why does this error persist?
I have just done a test to confirm the validity of this error:
[['Quotation mark test']] [['Quotation mark test'|Quotation mark test 2]] [['Quotation mark test'|'Quotation mark test 3']]
Will display in passage as:
'Quotation mark test' Quotation mark test Quotation mark test
Even though they all have quotation marks/apostrophes in the text, the only one that will show is the first iteration.
I had noticed this problem before but had assumed it was an error on my part. Now, I can't be so sure.. Why does this error persist?
Comments
The standard markup link accepts either:
1. A single String parameter which is used as both the Link Text and the Target Passage Name.
2. Two String parameters, one being the Link Text and the other the Target Passage Name.
A String value in Javascript/Twinescript is delimited by either single quotes or double quotes.
I believe the reason you generally don't have to delimit the parameter(s) of the standard markup link is because it automatically converts any non-delimited Text passed to it into a String value.
I would have expected that I would have to do something like the following if I wanted to be able to see single quotes in the Link Text of a link.
The first displays the quotes because they're actually part of the passage's name. In the single component case, the parser checks to see if a passage exists by the specified name first. If so, it displays the passage name as-is.
Ergo, the following single component link: Is functionally equivalent to the following two component link:
As to why the single set of quotes within the text component disappears in the latter two examples, greyelf is mostly correct—the only correction I offer is that the link markup accepts either plain text or a valid TwineScript expression, rather than simply a string.
'Quotation mark test 2'
This is more grammatically correct than putting quotes in the link, since technically, the quotes aren't really part of the linking word. Therefore, they shouldn't be highlighted in colour. However if you want the links to look like the quote you can wrap them in a <span> that applies a class with the same bold and colour as a normal link.
I very much appreciate the explanation, Mad Exile and greyelf!
I had considered doing it in this manner previously, but I had been concerned that the quotation marks would not appear inside the link, especially since I may plan on doing something extra with those links anyway so it would just seem as though I would be making a little more work for myself.
I personally prefer the quotations to appear inside of the link, in story development and in the actual presentation because it would be easier - for me at least - to work with and future, and is simply more aesthetically pleasing to my idea.
That's an interesting way of tackling the problem, but it may also be the most time consuming for me as I seem to spend longer than usual on any macros that involves any reference to <span> and <span id> x). But I do appreciate that advice nonetheless.
Ahh, that does seem to make sense.. So in the second case the quotation marks act as a string rather than an actual apostrophe.
I feel as though it is a little odd that the words need to be wrapped in quotation marks in order to properly function. I assume it is to realign their usage (or something similar) from string ref back to grammar? Much obliged by the way, that was the easiest way of interpreting the conundrum.
That explains the string thing more directly. Thank you very much!
Thanks guys!
Basically, if the text component is a valid expression, then the parser has to assume that it is one—assuming that it's plain text really doesn't work. Only if the text component fails as an expression does the parser assume that it must be plain text.