Hi Mike,
Thanks for the response! I should’ve probably left out the unicorn and the hourglass, because I feel as though I have a good grasp on what’s going on their–Inform guesses indefinite articles based on whether the first word of the letter is a vowel. And if it that makes it guess wrong, you can explicitly set the indefinite article. I don’t actually think it’s necessarily a bug that the Inform compiler doesn’t infer the article from what you use when you create it–I think this may even be explicitly stated in the docs–though it might be nice if it did.
What I’m really puzzled about is the behavior with “open” and “empty.” I didn’t expect Inform to get those cases right; the behavior I expected was for Inform to infer that chest and bucket to have indefinite article “a”, and then to print “a” before their names no matter what other stuff was getting printed before their names. So I expected “a open chest” and “a empty bucket” as well as “a open jug containing a beetle.” It’s surprising to me that Inform was able to guess that it should be “an open chest” and “an empty bucket,” and I’m really completely confused about how it got “an open jug” right but “a open jug containing a beetle” wrong. Something complicated is happening with indefinite articles, but I don’t know what it is.
…wait, I think I’ve got it, at least to some extent. Looking at Printing.i6t, PrefaceByArticle is doing some kind of lookahead before deciding what to print. But there’s a note on StorageForShortName that you mustn’t call this if it would overflow the buffer, or Bad Things will happen. And checking my attempt to modify Trachypachidae Maturin 1803, I was compiling that project to z8; when I compile to Glulx, I do get “an open jug containing a beetle.” So it must be that when the z-machine was planning to print “open jug containing a beetle” that was too long for StorageForShortName and it punted back to the default article for the jug. Whew.
Still curious about exactly how this is working, though. It must be that black magic stuff where when you print the indefinite article of something it silently runs through the activity of printing its name, with the accompanying mishegoss. This:
[code]Lab is a room.
A rock is in Lab. Before printing the name of the rock: say "[one of]orange[or]blue[or]green[or]red[or]indigo[at random] ".[/code]
yields “a/an” at random without respect to the color name; I think what’s happening is that it silently prints the name, picks a random color, prints the article based on the random color it picked, and then prints the name out loud this time–but now it’s printing a different random color. There’s some kind of new thing where text substitutions (sometimes?) get evaluated and queued up in advance; don’t know if that’s having an effect here.
When Appendix B says “All of this is a legacy design from a time when the I6 library did not support capitalised indefinite articles” is perhaps when I should back away slowly.
[For background, I’m working on extending this code, which provides a way to use Text Capture to see what you’re about to print, and calculates whether to say “a” or “an” based on that; and also handles “unicorn” and “hourglass” by putting them in a table of exceptions. And then I was surprised to see that “an empty bucket” was working even in contexts where I wasn’t running my code!]
That’s a real shame about your list writer extension! I’d really like to see it; the list writer is a bane of my existence sometimes. For one thing, there’s basically no way to make it play nicely with my code for using Text Capture to handle indefinite articles.