Parse valid responses to disambiguation requests as disambiguation requests rather than new commands
When a disambiguation request is printed, Inform decides whether to process the next input as a response to the request or as a new command by checking to see whether the first word of the input is a verb. Ordinarily this works well, but it will break when an object's name contains a verb. See http://inform7.com/mantis/view.php?id=1127 for an example.
In comments there, zarf says:
"This has been the intended behavior since the I6 days. It would be bad if a disambiguation prompt made some other command untypable, by stealing its verb. (It is less bad if a disambiguation fails, because the player can always make themself clear by typing the complete intended command.)"
I respectfully disagree with this evaluation. This behavior:
"What do you want to take, the buy chip or the sell chip?
What do you want to buy?"
seems worse to me than temporarily foreclosing the "buying" action, as the game has asked a question and refused to understand one of the answers it offers. People who know how the parser internals work can make themselves clear by typing "take buy chip" out in full, but this behavior is unfriendly to people who don't know this.
(Note that the "command has become untypable" problem only applies when the player changes her mind after seeing the disambiguation prompt, and thus will be much rarer. In any case, a player who knows how the parser internals work can recover her intended command by typing an invalid response to the disambiguation prompt and then typing the new command.)
So my proposal is that, at a disambiguation prompt, the game should always try to process the command as a response to the disambiguation first and, if that fails, try to process it as a new command.
matt weiner commented
I am seeing Emily's response very late!
What I was envisioning here was:
If the response to the Which do you mean question is a valid disambiguation response, run it.
If not, process it as a new command.
So in the "the spoon or the spoon" case, it would be possible to break out of the loop by typing anything that isn't "the spoon"--as with the current behavior. The command would not be understood as a disambiguation prompt and would be reparsed as a new command.
This would prevent the player from breaking out of "Which do you mean, the KISS album or the KISS album?" by typing "kiss," but that is a very edge case (and if the author can't be bothered to distinguish Double Platinum from Alive II, that's too bad).
Adminemshort (Admin, Inform 7) commented
Whatever solution is adopted (or not), it would be really bad if it were possible to get stuck in a disambiguation loop. Just occasionally one encounters a game state that asks "Which do you mean, the spoon or the spoon?" -- where it's not clear what to type to disambiguate -- and currently it's at least possible to leave that situation by typing another verb instead. (One can also try "both" or something, but most novice players are probably unaware of that.)
matt weiner commented
For a more plausible use case, see the very bottom of this post about the Threaded Conversation extension: http://www.intfiction.org/forum/viewtopic.php?p=55429#p55429
In a situation where the game has asked, "What do you want to ask Bob about: what it might be worth or who would buy it?", the player cannot type "buy." It wouldn't be feasible to expect that valid verbs not appear in conversation topics.
Another worry is that the existing strategy for dealing with disambiguation prompts also fails on commands that do not begin with verbs, in particular on directional commands. This:
Playroom is a room. A green block is here. A red block is here. Kitchen is north of Playroom. Test me with "x block /n".
yields "I only understood you as far as wanting to examine north," so the new command's non-verb has effectively been stolen by the disambiguation request. It is possible to get the same effect by "go north," but again that's something that you would be unlikely to type if you didn't understand how the parser internals work.