Apparently Inform 7 automatically replaces different dashes and turns them into a normal hyphen. This is rather inconvenient, at least in German, where the Gedankenstrich (En dash) is often used.
I now use [unicode 8211], but that’s clumsy and doesn’t work in room names.
I’m deeply addicted to the em-dash, so I sympathize!
The dash normalization seems baked in, so IIRC the best I could do was something like: To say --: say unicode 8212. (Literally the first nontrivial line in my story file… 
) Which at least lightens the syntax, though you do need to remember to use it consistently.
You can get around this limitation with:
The printed name of the Living Room is “Living[unicode 8211]Room”
And building upon Ben’s solution, you can make it more elegant with:
To say -:
say “[unicode 8211]”.The printed name of the Living Room is “Living[-]Room”
Yeah, all my works have substitutions for - as an en-dash and -- as an em-dash. It’s inconvenient, but better than nothing.
When it comes to the room name in the source text that you refer to it by from other parts of the text, it’s probably a good thing that dashes and hyphens are equivalent – they look almost identical at a glance, after all.
This obviously doesn’t apply to the printed name of the room, where you probably want it to look as nice as possible, with en/em dashes, curly quotes, or whatever.
(Speaking of which, it would be nice if there were a mode that automatically makes quotes curly… and also automatically makes them single if nested…)
Thanks for all your good feedback!
I’m afraid that doesn’t work with me (Inform 10.1.2. on a Mac). I’d get
Living ? Room
(It worked with Inform 9.3 though.) I’ll use room names without dashes now and mark this thread fixed.
However, I still wonder if it is necessary / useful to automatically replace dashes when at the same time you can do something like:
A guide to Æsop for naïve æsthetes, Lönnrot’s Kalevala, a creed according to the Bahá’ís, FALARÃO magazine, an Estonian poem by Tõnu Trubetsky, a Portuguese-Italian recipe for macarrão, a stripy hanging CANDY PIÑATA bag, a ¿¡Punctuation Turned Upside Down¿¡ pamphlet, an Italian brewers’ anti-violence poster declaring BÓTTE NON BÒTTE, a map of È and a dusty book titled The Parnasum of Luís Vaz bearing CAMÕES on its spine are in Miscellany Mañana.
(Taken from Ex. 70 – The Über-complète clavier)
Works here, although I am on a somewhat old Mac laptop right now.
Hm, I’m on an M1 Mac – but could that really be the problem?
No, same result on an M1.
Are you sure that line is being applied where you think? Even if the dash was displayed as a question mark, that wouldn’t explain the spaces around it.
Obviously the Germen Extension I use is the cause of the error - I have just tried it in a fresh project and could not reproduce the error there at first until I included the said extension.
The spaces are unfortunately my fault, I had written the example above by hand to illustrate it. Sorry!
Does the German extension uses Text Capture or something like that? (I believe the Spanish one uses that for a capitalisation issue depending on pronouns.) Often, a question mark means that a non-Latin-1 character has been printed to a byte buffer, which can’t encode it so it is converted to a question mark.
Oof, that would explain it.
(Text capture will be Unicode-clean in the next release, which will be a great relief.)
This might be a good use case for the new text capture extension by @Draconis. (Draconis, could it be extended to allow capture of Unicode characters?)
I believe it already uses a word buffer rather than a byte buffer, though I have to check!
Unfortunately, I don’t know enough about the inner workings of the extension to be able to say… but that sounds very plausible.