I’m getting ready to release Version 2 of Lost Items. There’s just one thing I’d like to fix: When used with Remembering, it sometimes prints an extra blank line.
[code]
Include Remembering by Aaron Reed
Include Lost Items by Mike Ciul
For noticing absence of something (called item) (this is the remember lost items rule):
Try remembering item;
The remember lost items rule is listed instead of the default notice absence rule in the for noticing absence rulebook.
The Living Room is a room. The dining room is west of the living room.
There is a watch in the living room. It is losable.
test me with “w/x watch/touch watch”[/code]
The “x watch” command is parsed directly as remembering, while “touch watch” causes a parser error, which triggers the noticing absence activity, which then initiates the remembering action. The latter case results in an extra blank line. Is there any way I can stop that from happening?
Seems to me there’s a page in the manual about how you can override sections of other extensions. I’ve never tried it, but this is the kind of situation it’s tailored for.
I’m already overriding some sections of Remembering, but I don’t even know how to fix this one - the line break is correct in one case but not in the other.
But where? If you put it in the action, you won’t get the desired break when it’s done normally. I guess you could put an “[if the printing a parser error activity is going on]” around it, but that seems like a weird thing to do to an action. If you put it in the activity, it does nothing at all. Any other suggestions?
I just had a look back - it turns out that I wasn’t replacing any sections, just doing a normal rule replacement. Unfortunately, that won’t work for the remembering action because Aaron didn’t name his rules. The section I’d have to replace constitutes about 40% of the entire extension.
But if that’s what I have to do, I can do it. Fortunately the other rule I replaced is in the same section.
I don’t know about with the extensions, but you can fix this example by writing
After printing a parser error:
say "[run paragraph on]".
The I6 routine Parser__parse explicitly sets the say__p flag right before running the after printing a parser error rulebook; that means that any [run paragraph on]s before that rulebook have no effect. Whether this is intentional or not I cannot say. Someone more familiar with the parser might be able to tell you.
There should shortly be an updated version of Remembering posted with better internal division and actually some significantly tweaked functionality. I can PM you the new version now if you want it.
I do have a bit of code that will handle the issue, using EmacsUser’s trick, but it’s not pretty:
[code]Converting parser error to action is a truth state that varies.
Before printing a parser error:
Now converting parser error to action is false.
For noticing absence of something (called item) (this is the remember lost items rule):
Now converting parser error to action is true;
Try remembering item;
The remember lost items rule is listed instead of the default notice absence rule in the for noticing absence rulebook.
After printing a parser error when converting parser error to action is true:
say run paragraph on.
[/code]
As usual, I’m having a hard time naming truth states. If there were something I could give a binary property to, I think it could be named and accessed more elegantly, but I can’t think of anything.
You can create if-statement variants that just take a truth state directly, if you dislike comparing them to true/false. (I agree that doing so is wordy and not natural language.)[code]
“asdf” by Ron Newcomb
There is a room.
'Tis awkward to compare to booleans is a truth state that varies.
To if (tr - a truth state), (ph - a phrase): (- if ({tr}) {ph}; -).
To if (tr - a truth state) begin – end: (- if ({tr}) -).
When play begins:
if 'tis awkward to compare to booleans, say “True.”;
otherwise say “False.”;
if 'tis awkward to compare to booleans:
say “True 2.”;
otherwise:
say “False 2.”
