Yeah. I think changing the I6 compiler to support an I7 runtime feature is too much of a layer violation. But replacing that routine in the I7 template is fine.
Going back to your original comment (in the extension), though…
Many interpreters unfortunately pass tabs through into the command.
Are tabs more of a problem than other invisible/control characters? What situation did this come up in?
So the PR changes the snippet code to not convert via printing, which is sensible.
But do we also want to fix these?
It would also be good if bug reports can be filed on any terps that are not following the rules.
One compiler change that would make sense IMO would be to selectively disable certain strict mode functions. (That would be true for I6 users too!) If RT__ChPrintC is replaced such that it does nothing more than wrap the streaming opcodes, then it’s kind of a useless function call.
On the other hand, strict mode is likely to be turned off when building for release, so the performance hit doesn’t matter as much.
oh, wait, did I miss the point and things would have already gone awry by the time the command had been echoed in KeyboardMorePrimitive? If so, the substitution of spaces for tabs could be moved to KeyboardMorePrimitive.
Echoing is normally performed by the interpreter, but if you switch to manual mode then this could be an issue.
However… Considering that most interpreters probably just echo the command through the normal printing system, I suspect that means they’re not actually checking for the restrictions from the spec, otherwise we would’ve heard about interpreters breaking if you entered a tab. (Or they’re silently filtering the characters on output rather than complaining.) Either way that suggests the main thing that actually cares about section 2.2 of the spec is the veneer function.
Once the Glk Foundations are merged, I’d suggest this be done as a Glk event handling rule, so that it’s fixed before KeyboardMorePrimitive even knows an event has happened.
The reason tabs are more of a problem is that they’re easy to type, unlike other control characters (which are either untypable or require special effort to type). With tab you can just, well, hit the tab key.
The thing that makes it confusing is that Inform interprets tab as part of a word, and not as word-breaking whitespace. I don’t suppose it would have caused any oddities if it was interpreted as a word separator.
This raises the question of whether, now that we support Unicode input (thank you again for that), we should recognize all Unicode whitespace as word breaks in the standard parser (which, IIRC, Inform 7 currently does not). I would suspect we should.
Ah. Thank you. I thought there was a way to replace veneer routines but I was having trouble. It’s not possible to replace them using (- -) inclusions in I7.
It looks like it is done in inform/inform7/Internal/Inter/Architecture32Kit/Sections/Veneer.i6t however.
I should try that… let’s see if we can just put RT__ChPrintC there and get a correct replacement…
Got it. This is working.
The other patch is still a speedup, and I’m still thinking about using the other patch as the basis to rework a bunch of the snippet code. There’s a bunch of irritating snippet bugs which I think could largely be fixed by converting the snippets to text preemptively more often, and my other patch makes that more straightforward.
This was the bit I was thinking of from Writing With Inform – I didn’t remember it exactly right, it says reading from files, rather than player input. I was imagining reading files of player input, of course…
**8. Line break and tab**. The notations "\n" and "\t" are used for a line break ("n" for "new line") and tab, respectively. Tabs normally do not occur in Inform strings, but can do when reading from files. It makes no sense to reverse these, so "\N" and "\T" produce errors.
But anyway I have the veener patch now, and I think it’s the right thing to do.