I was looking for an old version of I7, which I need to compile an old project, and was unable to find it on the website. The website only goes back to 4S08, but should contain links to all previous versions so that old story files can be re-compiled in the original version of I7 that they were written in.

If the older versions are not available, then whenever an old project needs to be rebuilt you will also need to do a full code review to ensure that it compiles in the latest version of I7, followed by another round of testing to ensure that there have been no breakages. Being able to recompile on the original I7 version removes the need to do either of these time-consuming tasks.

They don't need to be given such prominence on the download page - an 'older versions' link to a separate page would be enough - but they need to be present somewhere!

A better way to refer to a single item with a given
specification, in a situation where it's known that it must be the only
one. At present "a random..." is sometimes used for this, so for instance:

try inserting the item into a random pocket that is part of the garment;

Here the author knows that the garment has exactly one pocket, and is
really trying to say "the pocket which is a part of this particular
garment" - no actual randomness is really involved, and the source text is
therefore misleading to read.

Various alternatives are proposed. At the moment, the one we like best is
to use articles more naturally here, so that

try inserting the item into the pocket that is part of the clothing.

...would assert that there is only one such pocket, and throw a run-time
problem message if that proves to be false.

Comments in extension examples are currently treated differently from examples in the manual. The annoying upshot is that, if an extension author wants to walk users through an example with commentary, the source code will be broken up into multiple segments, each with its own paste button that must be clicked (worse, in the Mac IDE at least, pasted text is selected, so the user must deselect the text in the source panel before returning to the extension documentation panel to press the next paste button in the series).

Details: In the manual, comments appear as text that goes the full width of the page (whereas code is indented); when the paste button is pressed, the comments appear in the source surrounded by brackets.

In extension documentation, comments appear in the same way as in the manual, but they are not included in paste blocks. Instead, such a comment terminates a paste block; this means that comments must break a single piece of code into multiple paste-able segments.

Inform has a very useful feature whereby extensions can refer to one another and include (or not) code based on whether other extensions are installed. This generally works well, but doesn't go quite far enough for all situations. I will use my experience authoring a recent extension (Glulx Status Window Control) to illustrate where I think the functionality still falls short:

GSWC can be used with any Glulx project, and it also has special provisions when it is used in conjunction with the Simple Graphical Window and Flexible Windows windowing systems. GSWC requires Glulx Text Effects, but so do these other two extensions. So, if it is used with either of these extensions, we do not want GSWC to include Glulx Text Effects; however, if neither of these extensions is installed, GSWC should include GTE, since it is required for operation.

Inform should probably simply ignore repeated calls to include the same extension, but it doesn't. So, we can't just place an include directive in the extension; we need to protect it somehow. We could try using something like this:

<code>
Section - Include GTE if needed (for use without Glulx Text Effects by Emily Short)

Include Glulx Text Effects by Emily Short.
</code>

But that doesn't work, because Inform only looks for the inclusion of Glulx Text Effects in the current project, not in the other extensions.

Barring this, the next-best thing would be to protect the GTE inclusion from Simple Graphical Window, Flexible Windows, or any other project that includes GTE. This, though, would require OR logic in the conditional inclusion directives, which Inform also doesn't allow.

It turns out that there is no solution that allows us to include Glulx Status Window Control's only dependency if another extension used alongside it includes GTE; compilation errors result. It was necessary to release it with an instruction in the documentation to the effect that the author would need to include Glulx Text Effects if none of her other have already done it. (Which means the extension will generate errors if the author fails to do this.)

I've walked through this step by step to show how all three of my proposed enhancements fill potential needs:

(1) Inform should ignore repeated include directives to the same extension;
(2) Inform should allow OR and AND logic in the "for use with/without..." include directives;
(3) Inform should search all included extensions in the "tree" before deciding whether an extension meets the "for use with/without condition".

As in the Inform 6 code

if (a == 2 or 4 or 6) ...
if (leader ~= bill or martin or fred) ...

Which might be syntactically rendered in I7 as, say:

if a is either 2 or 4 or 6...
if the leader is neither Bill nor Martin nor Fred...

This should work with all verbs, so that we could have, e.g.

if the player is carrying either a knife or a sword...

A variant with positive "and" conjunctions would also be welcome:

if the player is carrying both the flint and the steel and the firewood...

And if it worked on the left hand side too, then all the better:

if either the dragon or the troll is on the bridge...

We would have to watch out for over-complicated, ambiguous sentences
though:

if the player is carrying either a knife or a sword which is made of
either steel or bronze or a spear or a halberd...

And allowing these constructs on both sides would be difficult:

if both the large door and the small door are either open or broken...

There are several common mistake patterns for erroneous Glk calls:

- Calling a window function (e.g. glk_window_clear) with a window argument of zero, or a window argument that doesn't refer to a real window

- Ditto for stream and sound-channel function.

- Printing to a text window which is awaiting line input.

These are fatal errors on some Glk libraries, but are ignored on others. (Or they're ignored by default, with a "strict mode" preference.) This leads authors into a trap, like the "vile zero" situation on the Z-machine a decade ago.

To avoid this, the IDE interpreter's Glk library should be strict about these errors, and always bring them to the author's notice.