I7 - Setting "mentioned" from within a room's description.
Aaron A. Reed
uninteractive text, and only the subsequent paragraphs listed items
you could actually do stuff with.
Increasingly, however, the things mentioned within the room
description body are often rather important themselves. In fact, the
room description itself is starting to feel more and more like
something that has to be hacked around (cf. Blue Lacuna) to get it do
the sort of cool stuff the rest of the language can do.
As a small suggestion towards an improvement on this front, wouldn't
it be lovely if we could just do something like:
[code]
Laboratory is a room. "This room is completely nondescript but for
[the Hieronymus machine], the massive bulk of which fills nearly every
corner."
The Hieronymus machine is a fixed in place device in Laboratory.
[/code]
Currently, this produces the discouraging
[output]
Laboratory
This fantastic room is dominated by the Hieronymus machine, the
massive bulk of which fills nearly every corner.
You can see a Hieronymus machine here.
[/output]
Even so, we've gained a few benefits already: a) if the item's printed
name changes, so will its appearance in our room description, without
the need for ugly if/otherwise blocks; b) we've visually identified in
our source text the important objects in a block of description; c)
Inform will now give you problem messages for stuff you promised to
implement but haven't yet, and d) you're much more likely to notice if
you change an item's name in one place (description text) and not the
other (printed name), thus making players less likely to type a word
in the room description that you forgot to implement as a synonym for
the object.
What would be lovely is if this construction could also e) know that
the bracketed thing is now mentioned and it doesn't have to do it
again, and f) prevent having to manually declare things as scenery, or
go through the elaborate gyrations seen in the "Rip" example for
manually not mentioning things that aren't.
What do you think? Impossible? Ill-advised? Should I submit as a
feature request?
--Aaron
(Pipe dream: in Inform 8, when you type [the Hieronymous machine] in a
room description and don't mention it again in your source code, an
object with this name is automatically created as a very-unlikely-to-
be-meant scenery object. Bracket all noun phrases and players will
never snicker at "You can't see any such thing" again.)
Jim Aikin
descriptions to do a lot more work (and in a user-friendly way). It may
turn out to be an Inform 8 feature, though. I played with it a little,
and found that using the method illustrated in "Rip", while not trivial,
worked well enough:
[code]
The Forest is a room. "Big trees are standing all around you. Near the
path is [oak], which looks especially intresting. A path leads north."
The enormous oak tree is here. It is fixed in place. The description is
"Quite a tall, sturdy-looking tree."
To say oak:
say "an [printed name of the enormous oak tree]".
Before listing nondescript items of the Forest:
now the enormous oak tree is not marked for listing.
[end code]
The difficulty in streamlining it is, I suspect, that unmarking things
has to happen in a before rule. By the time the description of the room
is being printed, it's too late. My first attempt didn't work at all:
To say oak:
now the enormous oak tree is not marked for listing;
say "an [printed name of the enormous oak tree]".
Maybe you could put something else into the to say rule that would do
the job. But really, what's wrong with making scenery scenery? This
works, but it's pointless:
To say oak:
now the enormous oak tree is scenery;
say "an [printed name of the enormous oak tree]".
You might just as well declare the object as scenery to begin with. But
maybe I'm not understanding what you have in mind. Can you clarify why
you want something to not be listed after the room description prints,
but you also don't want it to be scenery?
--JA
Erik Temple
> What would be lovely is if this construction could also e) know that
> the bracketed thing is now mentioned and it doesn't have to do it
> again, and f) prevent having to manually declare things as scenery, or
> go through the elaborate gyrations seen in the "Rip" example for
> manually not mentioning things that aren't.
>
> What do you think? Impossible? Ill-advised? Should I submit as a
> feature request?
Aaron, I don't think this is something that should happen by default. For
example, you may want to bracket your nouns to get the benefits of your
points
Erik Temple
> Even so, we've gained a few benefits already: a) if the item's printed
> name changes, so will its appearance in our room description, without
> the need for ugly if/otherwise blocks; b) we've visually identified in
> our source text the important objects in a block of description; c)
> Inform will now give you problem messages for stuff you promised to
> implement but haven't yet, and d) you're much more likely to notice if
> you change an item's name in one place (description text) and not the
> other (printed name), thus making players less likely to type a word
> in the room description that you forgot to implement as a synonym for
> the object.
>
> What would be lovely is if this construction could also e) know that
> the bracketed thing is now mentioned and it doesn't have to do it
> again, and f) prevent having to manually declare things as scenery, or
> go through the elaborate gyrations seen in the "Rip" example for
> manually not mentioning things that aren't.
>
> What do you think? Impossible? Ill-advised? Should I submit as a
> feature request?
[Apologies for the accidentally sent incomplete message.]
Aaron, I don't think this is something that should happen by default. For
example, you may want to bracket your nouns in a description solely to get
the benefits of your points a-d (I do this fairly often), yet you may
still want a mentioned item to have its own line, for emphasis perhaps, or
because you describe whatever it is doing something in its description
(e.g., "The Hieronymus Machine is chugging along quietly in the corner").
However, given the ability to distinguish which bracketed nouns should be
treated this way, I think this could be useful. Here's an example that
seems to do everything you were wanting, minus the pipe dream of course
(the code to execute a phrase from within a say statement is a trick of
JDC's):
<code>
Laboratory is a room. "This room is completely nondescript but for [$ the
Hieronymus machine], the massive bulk of which fills nearly every corner."
The Hieronymus machine is a fixed in place device in Laboratory.
A thing can be description-mentioned or not-description-mentioned. A thing
is usually not-description-mentioned.
To $ (obj - a thing):
say "[obj]";
now obj is scenery;
now obj is description-mentioned.
To say (ph - phrase): (- if (0==0) {ph} -).
Before listing nondescript items (this is the mark description-mentioned
objects rule):
repeat with obj running through things:[<--There is probably a better way
to narrow down the traversal here]
if obj is description-mentioned:
now obj is not marked for listing;
now obj is not-description-mentioned.
</code>
Here a simple shorthand before the noun ($) tells us that we need to mark
it as scenery and also mark it as not for listing. (If I were using this
myself, I would probably remove the "now obj is scenery" line.)
If you were using the Epistemology extension or similar knowledge-tracking
system, you might also want to mark the object as seen by the player in
the $ phrase.
Also, the code as written loops through all things in the world--there is
probably a way to narrow this down, depending on how you see the thing
functioning.
--Erik
Ron Newcomb
> uninteractive text, and only the subsequent paragraphs listed items
> you could actually do stuff with.
> Increasingly, however, the things mentioned within the room
> description body are often rather important themselves.
Hm. Good point.
> What would be lovely is if this construction could also e) know that
> the bracketed thing is now mentioned and it doesn't have to do it
> again, and f) prevent having to manually declare things as scenery, or
> go through the elaborate gyrations seen in the "Rip" example for
> manually not mentioning things that aren't.
The following code implements point E, and, I think, point F.
---code ------------
The initialise locale description rule is not listed in the before
printing the locale description rules.
The initialise locale description rule is listed first in the carry
out looking rules.
First before printing the locale description of something while not
looking (this is the initialise non-look locale description rule):
consider the initialise locale description rule.
---end code ------------
To explain: the "initialise locale description" rule is the one that
resets the Mentioned property on everything. We move it to much
earlier in the process -- to the first Carry Out Looking rule -- so
that when items appear in the room description text they'll be marked
Mentioned by the pre-existing machinery, disappearing from you-can-
also-see.
But, commands like ENTER and EXIT also use that activity sans the
Looking rules, so we stick that rule back into its original place,
with a "while not looking" condition appended.
BTW, this also works on objects mentioned in the room heading. So if
your room heading read:
Laboratory (in the teleport chamber)
...then the teleport chamber wouldn't be mentioned later in the room
description, writing a paragraph about, or you-can-also-see phases.
Is good? Or did I miss something about point F?
-Ron
Erik Temple
wrote:
> Also, the code as written loops through all things in the world--there
> is probably a way to narrow this down, depending on how you see the
> thing functioning.
Uh, that was silly. A much better version of the final block:
Before listing nondescript items (this is the mark description-mentioned
objects rule):
repeat with obj running through description-mentioned things:
Erik Temple
> The initialise locale description rule is not listed in the before
> printing the locale description rules.
> The initialise locale description rule is listed first in the carry
> out looking rules.
> First before printing the locale description of something while not
> looking (this is the initialise non-look locale description rule):
> consider the initialise locale description rule.
Ah, very nice! I still wouldn't want this to be the default behavior, for
the reasons I mentioned in my previous post. But it's a simple and elegant
solution... (I also didn't quite get point F--I'm not sure how, in a case
like the "Rip" example, we could ever know precisely what to do from a
simple mention of the noun.)
--Erik
Ron Newcomb
> the reasons I mentioned in my previous post. But it's a simple and elegant
> solution... (I also didn't quite get point F--I'm not sure how, in a case
> like the "Rip" example, we could ever know precisely what to do from a
> simple mention of the noun.)
Thank you. I really must make a flowchart of how locale descriptions
are created.
I'm looking at the Rip Van Winkle example right now. It seems to
exist because, like in Aaron's example above, the problem is a thing
being mentioned twice -- once in the room description and once in the
you-can-also-see line. The usual Inform solution to that is declaring
the thing Scenery. But, the RIP example asks, what if you can't make
it scenery because it really is an important, interactive object?
How to hide it from you-can-also-see then?
Here's the new RIP example with the fix:
----code start-----
"Rip Van Winkle"
The initialise locale description rule is not listed in the before
printing the locale description rules.
The initialise locale description rule is listed first in the carry
out looking rules.
First before printing the locale description of something while not
looking (this is the initialise non-look locale description rule):
consider the initialise locale description rule.
A person can be asleep.
The Catskills is a room. "Here is a lovely, secluded [Hieronymus
machine] in the mountains, far from civilization[if Rip Van Winkle is
asleep]: as though to prove it, [Rip Van Winkle] is sleeping under a
tree[end if]."
The Hieronymus machine is a fixed in place device in the Catskills.
A tree is scenery in the Catskills.
Rip Van Winkle is a man in the Catskills. "Rip Van Winkle stands here,
looking mightily confused." Rip Van Winkle is asleep.
Instead of waiting:
say "Rip Van Winkle wakes up with a snort.";
now Rip Van Winkle is not asleep.
Test me with "look / z / look".
------end code-----
and
----transcript--------
Rip Van Winkle
An Interactive Fiction
Release 1 / Serial number 091008 / Inform 7 build 5Z71 (I6/v6.31 lib
6/12N) SD
Catskills
Here is a lovely, secluded Hieronymus machine in the mountains, far
from civilization: as though to prove it, Rip Van Winkle is sleeping
under a tree.
>test me
(Testing.)
>[1] look
Catskills
Here is a lovely, secluded Hieronymus machine in the mountains, far
from civilization: as though to prove it, Rip Van Winkle is sleeping
under a tree.
>[2] z
Rip Van Winkle wakes up with a snort.
>[3] look
Catskills
Here is a lovely, secluded Hieronymus machine in the mountains, far
from civilization.
Rip Van Winkle stands here, looking mightily confused.
>
---end transcript---------------
Erik Temple
> I'm looking at the Rip Van Winkle example right now. It seems to
> exist because, like in Aaron's example above, the problem is a thing
> being mentioned twice -- once in the room description and once in the
> you-can-also-see line. The usual Inform solution to that is declaring
> the thing Scenery. But, the RIP example asks, what if you can't make
> it scenery because it really is an important, interactive object?
> How to hide it from you-can-also-see then?
Yes, that makes sense. Looking back, I see I misread Aaron's points E and
F--I thought he wanted objects to *actually* be marked as scenery, except
when they shouldn't be. In the solution I suggested, this would mean
changing:
To $ (obj - a thing):
say "[obj]";
now obj is scenery;
now obj is description-mentioned.
to
To $ (obj - a thing):
say "[obj]";
now obj is description-mentioned.
(which is my preference anyway, as I said.)
Thanks, Ron.
--Erik
Ron Newcomb
> Aaron, I don't think this is something that should happen by default. For
> example, you may want to bracket your nouns in a description solely to get
> the benefits of your points a-d (I do this fairly often),
On your philosophical point:
I think Aaron does this fairly often too. :) If we do it more often
than not, then it's a valid reason for changing the default behavior.
Obviously either method will be wrong in particular circumstances, so
we need to look at how hard it is to make each method operate like the
other.
RIP has a weird and complicated rule. But I can undo the new default
behavior like so:
Carry out looking: now the Hieronymus machine is not mentioned.
..and place the rule between the body text rule & paragraphs about
objects rule. This seems easier.
-R
Erik Temple
> On your philosophical point:
>
> I think Aaron does this fairly often too. :) If we do it more often
> than not, then it's a valid reason for changing the default behavior.
> Obviously either method will be wrong in particular circumstances, so
> we need to look at how hard it is to make each method operate like the
> other.
Actually, you've won me over. After playing around with your
rearranged-rule solution a bit, I think the new behavior should be the
default behavior after all.
> RIP has a weird and complicated rule. But I can undo the new default
> behavior like so:
>
> Carry out looking: now the Hieronymus machine is not mentioned.
>
> ..and place the rule between the body text rule & paragraphs about
> objects rule. This seems easier.
As you might gather from the way I went about my suggested fix, I would
like to see more use--in the system itself--of inline say phrases. They
work nicely toward the larger goal Aaron mentioned of getting historically
"flat" text like the room description to actually do stuff. Case in point:
It seems yet easier to me to wrap that rule for not mentioning a given
object into an inline say phrase which will work for any object:
To @ (obj - a thing):
say "[obj]";
now obj is not mentioned;
To say (ph - phrase): (- if (0==0) {ph} -).[<--Allows a bracketed phrase
to execute "inline"]
And now all you have to do to be sure that the Hieronymus Machine still
gets its own line is to write it like this in the room description:
"This room is completely nondescript but for [@ the Hieronymus machine],
the massive bulk of which fills nearly every corner."
--Erik
Ron Newcomb
> Actually, you've won me over. After playing around with your
> rearranged-rule solution a bit, I think the new behavior should be the
> default behavior after all.
OMG, I won a philosophical argument on Usenet. I'm gonna print this
thread and frame it. :)
Since a frequent path to default behavior is extensionhood, I'm
writing the code change up as an actual Inform 7 extension. Though
I'm normally against 3-liner extensions, this one seems unintuitive
enough to warrant packaging. OTOH, doing this formally, I'm finding
some interesting pointy edges to the new behavior. More below.
> As you might gather from the way I went about my suggested fix, I would
> like to see more use--in the system itself--of inline say phrases. They
> work nicely toward the larger goal Aaron mentioned of getting historically
> "flat" text like the room description to actually do stuff.
I like that description of it, "flat" text, quotes and all. I think
one of the design goals of Inform 7 is to make code appear more
"flat". Observe any well-written Instead Of one-liner.
> Case in point:
> It seems yet easier to me to wrap that rule for not mentioning a given
> object into an inline say phrase which will work for any object:
> "This room is completely nondescript but for [@ the Hieronymus machine],
> the massive bulk of which fills nearly every corner."
Well, the first thing that comes to my mind is not to use the square
brackets at all in that case.
The second thing would be to use words for the say phrase, not a
punctuation mark. Like ".. [the Hieronymus machine mentioned
below]..." Especially since the word "mentioned" is used there, and
it affects the mentioned property, it is easier to remember than a
random punctuation mark.
My concern now is BRIEF and SUPERBRIEF. As well, the abbreviated room
description that happens when the player gets off of or out of
something. This cuts the room description, which, well, I think is
frankly inappropriate for such works. As Aaron says, the room
description isn't static anymore, and the entire purpose of having
BRIEF mode was to avoid boring the player with the same exact
paragraphs of prose over and over.
Yet even malleable text gets dull. Blue Lacuna's mutable weather was
nice, but after awhile I just wanted to turn it off. It wasn't,
usually, important.
Erik Temple
> Since a frequent path to default behavior is extensionhood, I'm
> writing the code change up as an actual Inform 7 extension. Though
> I'm normally against 3-liner extensions, this one seems unintuitive
> enough to warrant packaging. OTOH, doing this formally, I'm finding
> some interesting pointy edges to the new behavior. More below.
Cool, I'm glad you're going to wrap it up that way.
>> It seems yet easier to me to wrap that rule for not mentioning a given
>> object into an inline say phrase which will work for any object:
>> "This room is completely nondescript but for [@ the Hieronymus
>> machine], the massive bulk of which fills nearly every corner."
>
> Well, the first thing that comes to my mind is not to use the square
> brackets at all in that case.
In some cases, sure, the best thing would simply not to use the brackets.
If we're doing something more interesting, though, like varying the
printed name (and perhaps description) of the object based on our PC's
psychological state and/or how often she's seen an object, then we'd
definitely want the option to use brackets without marking our object as
mentioned. So, even in this example, we could in fact be seeing something
like "the Hieronymus machine" --> "that irritating machine" --> "that
infernal machine". (Also, maybe we just want the benefits Aaron mentioned
in his points A-D).
> The second thing would be to use words for the say phrase, not a
> punctuation mark. Like ".. [the Hieronymus machine mentioned
> below]..." Especially since the word "mentioned" is used there, and
> it affects the mentioned property, it is easier to remember than a
> random punctuation mark.
Absolutely. My example was pitched for concision, not for an extension.
Your syntax is great for the latter.
> My concern now is BRIEF and SUPERBRIEF. As well, the abbreviated room
> description that happens when the player gets off of or out of
> something. This cuts the room description, which, well, I think is
> frankly inappropriate for such works. As Aaron says, the room
> description isn't static anymore, and the entire purpose of having
> BRIEF mode was to avoid boring the player with the same exact
> paragraphs of prose over and over.
If you're looking for (biased) input, I would suggest unapologetically
turning off all BRIEF functionality in the extension as well as setting
the full-length room descriptions option. (I would like to see BRIEF and
SUPERBRIEF go the way of the dodo, which is why I say "biased"). I guess
another option might be to write two extensions, one to turn off
BRIEF--I've always found it odd that Inform doesn't make it easy to
disable them with a single use option--and then have the
description-mentioning extension include that extension.
--Erik
Ron Newcomb
> Cool, I'm glad you're going to wrap it up that way.
I'll take the liberty of emailing it to you & Aaron. Please poke it
with sticks and ensure it doesn't leak. Afterward we'll release it to
the wild.
> In some cases, sure, the best thing would simply not to use the brackets.
Noted.
> > frankly inappropriate for such works. As Aaron says, the room
> > description isn't static anymore, and the entire purpose of having
> > BRIEF mode was to avoid boring the player with the same exact
> > paragraphs of prose over and over.
I'm going to amend that and say, the purpose of BRIEF & SUPERBRIEF is
to avoid distracting the player while they backtrack through the world
looking for keys. A mutable room description with three new words
every time you pass by isn't worth the player's attention -- at least,
the weather reports in Lacuna I ceased to care about, pretty as they
were -- so fancy room descriptions aren't a reason to remove them.
However, after spending time on weaving great room descriptions with
great object descriptions, the abbreviated version may look horrible
-- a bare list of object paragraphs, including those objects never
intended to be treated in such a way.
I'll take the liberty of creating a full LOOK after going, but only
document the concerns about BRIEF with copy-pasta for disabling them.
-R
Aaronius
Hey guys, sorry for dropping the topic and running; another wave of
grad school hit me and I didn't have time to get back to this earlier.
Ron, the extension is fantastic! I played around with this a bit and
it's exactly what I wanted. You're even taking into account the issues
with capitalization and "brief" mode. I think this is ready to be
posted, er, post-haste? And thanks to Erik and Jim for comments too.
Speaking of capitalization, though, we've now brought that issue up as
well. The current best solution to produce something like "Yellow mist
fills every corner," as Ron points out, is probably:
[code]
Laboratory is a room. "[A yellow mist] fills every corner." yellow
mist is in Laboratory.
[/code]
...which works ok, but certainly isn't too intuitive and makes the
natural language model queasy for at least two reasons (the spurious
"A"; and the uncapitalized "yellow" when defining the item). Actually,
three, if we count the messages like "You see nothing special about
yellow mist" that this generates.
Better would be for Inform to recognize the difference between
"[Yellow mist]" and "[yellow mist]". Does anyone know if there's a
technical reason this doesn't happen already? If not, I'll submit a
feature request.
--Aaron
Ron Newcomb
> Ron, the extension is fantastic! I played around with this a bit and
> it's exactly what I wanted. You're even taking into account the issues
> with capitalization and "brief" mode. I think this is ready to be
> posted, er, post-haste? And thanks to Erik and Jim for comments too.
Hey thanks. (And to think they laughed at me -- laughed! -- for
writing so many extensions. Who's laughing now, Mr. Bond? Mua-ha-ha-
ha-haa!)
> Laboratory is a room. "[A yellow mist] fills every corner." yellow
> mist is in Laboratory.
>
> ...which works ok, but certainly isn't too intuitive and makes the
> natural language model queasy for at least two reasons (the spurious
> "A"; and the uncapitalized "yellow" when defining the item).
That would be mainly because you want to define with "some".
Some yellow mist is in the laboratory.
Inform will use "some" or "the" as appropriate. The times when you
need the spurious indefinite are exceedingly rare, per Writing with
Inform in the sections the extension references.
Although I guess this brings up the issue with objects who's names AND
articles change, as in "Some amorphous but moving darkness" -> "the
demon". But then, Printing The Name Of can fix that, too.
I wonder if I should strike the spurious indefinite's use from the
documentation, leaving only a reference to WwI in the rare case an
author hits it. I mean, it's really rare when defining a thing that
one wouldn't use some sort of article. "Water is in the cave" is of
course nice, but it's easier to fix it there, "Some water is in the
cave", than define it 'wrong' and then try to fix it.
OTOH, sometimes it's easier to patch a specific prose issue than mess
with the code and risk breaking something else. So....
> Better would be for Inform to recognize the difference between
> "[Yellow mist]" and "[yellow mist]". Does anyone know if there's a
> technical reason this doesn't happen already? If not, I'll submit a
> feature request.
There is a tech reason. ::deep breath::
In The Beginning, Inform couldn't distinguish case at all -- it was
practically a feature of the language, when comparing it to more
persnickety languages -- and the regex engine didn't exist yet. The
writers complained about the case issue begin difficult, so Graham
cleverly turned a "bad" feature into a good one.
You likely know you're not supposed to define a say phrase with a
parameter-preceding article in it, like
To say this is the (X - a thing):
because the "the" is now mandatory when you invoke it. Say "[this is
water]" won't compile; it has to be Say "[this is the water]".
Fixing that requires changing the definition to one of:
To say this is the/an/a/-- (X - a thing):
To say this is (X - a thing):
And if there isn't a parameter there to "eat" articles, the first form
is required:
To repeat through the/an/a/-- unmodified (R - a rulebook):
Graham updated Inform to allow identical-except-for-case To-phrases,
so one could define these:
To expound on china: [dishes]
To expound on China: [the country]
Then he put 2 & 2 together:
To say The (X - an object):
To say the (X - an object):
Inside, neither phrase knows anything of upper or lower case. Both of
them are hardcoded to print one or the other. Nor does the Inform 6
code have any indication of how the Inform 7 invocation was written,
wherever it was written. So, there's really no decision-making going
on, it's just putting the Inform 7 compiler's (computer's)
persnicketyness to good use.
With [yellow mist], there's no required article there for the trick to
hang onto. It's say phrase is basically
To say (X - object):
Hence, the issue.
While we *can* do a [cap yellow mist] to capitalize, it's no prettier
than [A yellow mist] or [A Yellow mist]. After some testing, we can
do [cap][Yellow mist] which will always capitalize, or even use a
proofreading mark. (Though I don't think there is one for cap like
there is ¶ for paragraph break.) Nor am I sure if [^][yellow mist]
or [^ Yellow mist] (space after the caret required) is less of a
bother than [A Yellow mist]. (Plus, punctuation marks don't tell you
what they are for.)
Finally, there's other non-captialization benefits to [A ....] as WwI
details.
Whaddaya both think?
-R
Ron Newcomb
Aaronius
Thanks for the explanation. I sometimes feel embarrassed that I've
spent so much time using I7 and still know surprisingly little about
how it works. I suppose it's a testament to its design that I mostly
don't have to.
On Oct 11, 8:38 pm, Ron Newcomb <psc...@yahoo.com> wrote:
> sometimes it's easier to patch a specific prose issue
Ouch. Ouch, ouch, ouch. The writer in me just died a little.
Yes, I suppose not everyone will want sentences like "Yellow mist
lingers," but damnit, I like that sort of thing. It's more poetic and
succinct than "Some yellow mist lingers." Sorry, but I flat-out refuse
to "patch my prose issue."
I'll submit a feature request and try to start all my sentences with
"the," "a," or "some" in the meantime.
A sincerely,
--Aaron
(And I encourage you to imagine me walking haughtily into the distance
much like C-3PO on the deserts of Tatooine, muttering something about
"patch my prose issue indeed" under my breath.)
Ron Newcomb
> Thanks for the explanation. I sometimes feel embarrassed that I've
> spent so much time using I7 and still know surprisingly little about
> how it works. I suppose it's a testament to its design that I mostly
> don't have to.
It's a big system. I'm re-reading the Appendix docs now, trying to
remember it all.
> Ouch. Ouch, ouch, ouch. The writer in me just died a little.
Um, UNDO and try again? :P
I'll add an explicit capitalization say-phrase to the extension. I
think I'll go with [uc] as the way to do it, as a "cap" is a wearable
thing, and I guess I'll leave the ^ caret as a synonym for it, just so
you don't see letters in front of your sentence's beginning (since I
agree it kinda throws off a... a... cadence or something, like how
graphic designers pushed Apple to make those new lickable buttons in a
more neutral color because their graphic works were a bit red-shifted,
unconsciously balancing the GUI's blue button colors.).
Other than that, I suppose I'll submit it for release. Erik, anything
to add?
> (And I encourage you to imagine me walking haughtily into the distance
> much like C-3PO on the deserts of Tatooine, muttering something about
> "patch my prose issue indeed" under my breath.)
~heh~
Erik Temple
> Other than that, I suppose I'll submit it for release. Erik, anything
> to add?
Nothing except that the extension is really nicely done, with excellent
attention to detail! I think that both uc and the caret seem like good
commands, both better than the spurious article (the proofreading mark for
capitalization is a triple-underline--not really a possibility in a text
editor, though I like the idea that one might use proofreading marks to
correct Inform's "editorial" assumptions.)
Good work! I look forward to using it in a real project (just as soon as I
get out of the forest of extensions I'm currently working on...)
--Erik