Change to ParseErrorQuestion

Set priority=true on this class.

docs/manual/changelog.htm

@@ -40,7 +40,9 @@ <h1>Change Log</h1>
 <br>
 
 <hr>
-<h2><a name="v1.6-1">Version 1.6.1</a> (17-Feb-2023)</h2>
+<h2><a name="v1.6-1">Version 1.6.1</a> (15-Mar-2023)</h2>
+<p>The default value of <strong>ParseErrorQusetion.priority</strong> has been changed to true. This means that player input in response to a parser query will be understood as a response to that query before being interpreted as a new command (if the latter is possible). So, for example, if the parser responds to X WALL, which 'Which do you mean, the east wall or the west wall?', the response EAST will be taken as meaning the player meant to refer to the east wall rather than being interpreted as a GO EAST command (as it previously would have been).</p>
+<hr>
 <p>The okaySetMsg property has been moved from the Settable class to the Thing class, and is now used On Thing in place of the DMsg() previously used to report the effect of setting something to somethinq. This ensures that overriding okaySetMsg should consistently behave as expected.</p>
 <hr>
 <p>All the occurrences of gDobj and gIobj within verify routines have been replaced with <a href="actres.htm#gTentative">gVerifyDobj and gVerifyIobj</a> (respectively). This should help guard against any further run-time error bugs of the kind noted below in relation to locks and keys (that is, run-time errors resulting from attempts by verify routines to reference gDobj or gIobj before the parser has determined what their values are).</p>
@@ -78,10 +80,9 @@ <h2><a name="v1.6-1">Version 1.6.1</a> (17-Feb-2023)</h2>
 <p>Fixed bug that prevented the names of responding objects to be listed in respond to a LISTEN TO command applied to multiple objects.</p>
 <hr>
 <p>Fixed bug in askMissingObject() that could cause run-time errors by resetting objects to nil at the wrong point. This might manifest, for example, when issuing a LOCK command without specifying a key.</p>
+<hr>
 <br>
 
-
-
 <h2><a name="v1.6">Version 1.6</a> (12-Dec-2022)</h2>
 <p>The <strong>Thing</strong> class now defines a new <strong>checkRemove(obj)</strong> which can be used to allow the Thing in question to object to the removal of obj. This is intended to be called at the check stage of action handling, so that checkRemove(obj) can prevent the removal of obj simply by displaying a message. Currently, the library only calls checkRemove(obj) from the check stage of the TAKE action (which covers most cases where an object is likely to be removed from a container, including commands that would result in an implicit TAKE). Game code may, however, wish to call checkRemove() from the check stage of other actions, depending on how they are implemented, if they could result in the removal of an object from its container without the actor taking the object. In some cases it may be easier to use the <a href = "thing.htm#reaching">checkReach(actor)</a> method to do this, especially where what is being modelled is the inaccessibility of the object to the player character's touch.</p>
 <p>This method was originally removed to correct a problem that had arisen with using <strong>exit</strong> or <strong>abort</strong> at the action stage of command handling, since at one point this was suppressing the output of any text from the action stage (resulting in silent failure of the command). This in turn made it appear unsafe to use notifyRemove() to prevent an object being removed from its container, since this would be called at the action stage (via actionMoveInto()). With luck, this should no longer be a problem, so it should be safe to use notifyRemove() and prevent the removal with <strong>exit</strong>. Using checkRemove() provides an alternative if its needed, or where it seems more logical to halt the action at the check stage before it gets going at the action stage.</p>

parser.t

@@ -1214,6 +1214,14 @@ class ParseErrorQuestion: Question
 
     /* the curable ParseError that posed the question */
     err = nil
+
+    /* 
+     *   Should we prioritize interpreting player input to a parser query as a response to that
+     *   query over interpreting it as a nea command (where the latter is possible)? By default we
+     *   do (since this seems more likely to reflect player intention in this case), although game
+     *   code can override if desired.
+     */
+    priority = true
 ;