Changing a parser error but still "printing a parser error"

Is there any way to replace the text of a parser error, while still allowing code triggered “when printing a parser error” to fire? Neither the method in Example 366 - WXPQ nor the extension Default Messages by Ron Newcomb allow such code to go through.

Specifically, Emily Short’s Conversation Builder relies on detecting an attempted speech action by hijacking the parser error activity:

Rule for printing a parser error (this is the read all performative quips rule): if the current interlocutor is nothing, make no decision; now the variable snippet is the player's command; store base quip text; say "That speech act is not implemented. Draft a new one? >"; if the player consents:Etc.

I can get around this by specifically exempting my prettifying code from use with the CB:

[code]Section 3 - A nicer parser error (for use without Conversation Builder BETA by Chris Conley)

Rule for printing a parser error when the latest parser error is the noun did not make sense in that context error:
if the current interlocutor is a person:
if the player’s command includes “say/ask/answer/tell/a/t” or the player’s command includes “[a subject]” or the player’s command includes “[a quip]”:
say “That doesn’t seem to be a potential topic of conversation.”;
say “You aren’t talking to anyone at the moment.”[/code]but that’s something of a hack, and anyway it doesn’t prevent this code from interfering with any future code or extensions that may be written relying on parser errors (or just the context parser error in particular).

I haven’t looked at Conversation Builder’s guts, so I’m not sure what the plan is there. Obviously it’s a weird case – most games will not have an all-encompassing “Rule for printing a parser error” replacement.

Normally, if an extension has a special rule for printing a parser error, it’s replacing the error message displayed. If you want to replace that error message yourself, you don’t want the extension’s rule to run. That’s more or less the whole point of the “printing a parser error” activity.

Hmmm, I had thought of suggesting that you could replace the general “rule for printing a parser error” with a “[text]” token, but that doesn’t seem to be consistently understood.

Here’s what I had:

[code]The current interlocutor is an object that varies.
Carry out examining a person: now the current interlocutor is the noun.
Carry out waiting: now the current interlocutor is nothing.
Conversation-building is an action applying to one topic.
Understand “[text]” as conversation-building when the current interlocutor is not nothing.
Report conversation-building: say “Here’s where we would tell [the current interlocutor] to say ‘[the topic understood]’.”

Salon is a room. Bob is a man in Salon. Jane is a woman in salon.

Test me with “xyzzy/x jane/xyzzy/x fofl/x bob/xyzzy/put the lime in the coconut/z/xyzzy”.[/code]

But this gives an ordinary parser error whenever the command starts with a verb in the dictionary. Is this a bug? It seems as though the text token should capture this. (If we were to extend the Quiz Show example to state mottoes, it would fail on Alaska’s motto “North to the future,” I think.)

Maybe another solution is to list Conversation-Builder’s parser error rule first? Can that be done with rules for activities?

Yes, you can order activity rule books in the usual way.

Ah, I was trying “First rule for printing a parser error” but it has to be “First for printing a parser error,” I guess.

I work with rule books so often, I should have thought of that. It works perfectly, of course. Thank you!

I’ve submitted the “[text]” thing as a bug, so the powers that be can judge it.

Whenever I see action syntax reconstructed like this, I try to think of a way to let the parser handle it. Have a look at my Disambiguation Override and Lost Items extensions for how they do that:

They’re both here:

Isn’t this the same thing, though? (from LI): Rule for printing a parser error when the latest parser error is the can't see any such thing error (this is the check for lost items rule): let the remembered wn be the parser's wn; Repeat with the missing item running through lost things: Now the item sought is the missing item; if the player's command includes "[any sought thing]": carry out the noticing absence activity with the missing item; rule fails; ...

Yes, that’s from an old version of Lost Items, and it really bugged me. I fixed it in the latest version. Where did you get that?

This is what it does now:

Rule for printing a parser error (this is the check for lost items rule): if we are looking for lost items: [we added lost items to scope but didn't find any, so return to normal] stop looking for lost items; make no decision; unless the latest parser error is relevant to lost items, make no decision; Start looking for lost items.

At which point it skips the rest of the turn and adds all lost items to scope, allowing the parser to have another look at the same command.