I7: Inconsistent application of After reading a command

I have a situation where I need to call a certain bit of code after each time the player presses return on the input line. I have been using the “after reading a command” rules to do this, but I’m finding that Inform is inconsistent about it when it invokes those rules.

They are always invoked after a simple command, of course. But beyond that point, Inform seems to take a hacky and inconsistent approach to calling them. After disambiguating between two objects (“Which key do you mean, the red or the blue?”), the after reading a command rules are called from the NounDomain routine. The same routine also handles cases like this:

However, NounDomain does NOT call the after reading a command rules for this type of two-part input. I can hack it into NounDomain at the end of that routine on the same model used for the multiple-disambiguation does (placing it after the second input has been combined with the first to produce a full command, just before the RETURN RE_PARSE), and things seem to work fine. But is it really necessary that I hack the template layer, or is there somewhere else I could insert the instruction? There are other situations, such as after Yes/No questions, where Inform also does not call the “after reading a command” rules–do I just have to hack into the template layer to get at those too?

Are there other potential situations that I’m missing? Why does Inform not handle this consistently?


OK, I’ve got the solution. Since I’m using Glulx, I can slot my code into HandleGlkEvent so that it will be fired whenever line input is received. However, I have the feeling that if I were using Z-code I’d be having to hack routines all over the parser template. Is there any good reason for the inconsistency with which this is handed?


It seems weird and inconsistent to me. (Not a very enlightening answer, I know.)

No, there’s no good reason that disambiguation re-invokes the read-a-line routine. It’s just always been that way (certainly since Inform 5); it’s the bottom layer of the parser, it’s old code, and rewriting it would break who-knows-what.

Thanks. That actually does seem to point out one difference between the handling of this in I5/I6 and I7–I7 doesn’t reinvoke the read-a-line routine after accepting a disambiguation response, it runs only the after phase of the reading a command activity. Presumably this is safer than actually re-requesting input, but it’s certainly possible that messing with it could still break things…!