Yes indeed, the 1.0 document is mostly useless right now IMO. Redirecting each page to the corresponding 1.1 document would be what I’d recommend.
But David wants to keep maintaining both, which I’m okay with.
(There is value with having all versions of the document preserved for history, and we don’t want to lose that. But it would also be great for there to be consistent reliable links to the latest version. But so long as someone is willing to maintain both documents I guess we have that.)
We could make https://www.inform-fiction.org/zmachine/standards/current/ a symlink to https://www.inform-fiction.org/zmachine/standards/z1point1/.
(Not that 1.2 is expected any time.)
We stopped using output stream 3 in PunyInform after it was found that this didn’t work in one or more of Infocom’s v3 interpreters - the printed text would just appear on screen instead. I can’t remember exactly which interpreters though.
Not important, really, but easy enough to do, and the sort of mindless work that makes me feel like I’m making progress when I don’t want to figure out how to rewrite/reword stuff. So, yeah, why not.
Huh! That seems like good evidence that it wasn’t intended for use in v3, and stream 4 was back-ported because it was easier to implement, perhaps?
Sorry, I should clarify: I don’t think having both versions (ie. option 2) makes things ambiguous. I do think option 1 is equally unambiguous, since as Dannii says the 1.1-specific changes are clearly marked. And given that, having just one copy of the standard is simpler and less confusing.
As an analogy: should we break out different standards for V3, V5, V6, V8? I think it’s pretty clear we shouldn’t! While each of them have differences, they have so much in common that it’s much simpler to keep them together. And 1.0 and 1.1 have much more in common than, say, V5 and V6.
Of course, the folks who are volunteering to do the work should get to do it in whatever way they find most motivating! If folks decide to keep both versions alive, the changes that Dannii suggests to steer folks hard towards 1.1 for anything other than historical interest would go a long way too.
The Remarks in Section 16 go into great detail on how Beyond Zork decides whether to use Font 3 or not, and then says “A similarly tangled process is used in ‘Journey’.”
I feel it’s probably worth making explicit what Journey does.
I’ve been curious about it since I first read that remark, but never had the time to look into it.
Looking at the source for Journey, it seem fairly simple. Font 3 usage is turned on by default, but then the platform is checked. On PC and Apple II it is turned off, on Mac and Amiga it is turned on.
This looks like if the interpreter number is anything else (that is, not a platform Infocom released Journey on) then Font 3 will be used.
The one fairly significant change to the structure of the Standard that I would like to make is to move all the information about the header from Appendix B into section 11, where most of the header information is.
It’s not really an important point, but it has bugged me on several occasions over the years when I needed to look in two separate parts of the spec for header information.
I may be alone in this. I also don’t know what we’d do with Appendix B.
Makes sense to me. Obviously you’d want to maintain the clear distinction between mandated behavior and conventional behavior.
I also don’t know what we’d do with Appendix B.
Either delete it, or leave it up with “This space intentionally left Blank” so that the old URLs like http://www.inform-fiction.org/zmachine/standards/z1point1/appd.html continue to work. I don’t have a strong opinion.
Put a link in the appendix pointing to the other page. People will have linked to the appendix and we don’t want those links to go to a 404.
Yeah, this seems like the best plan. Just a small page explaining what it was, why it’s gone, and linking back to section 11.
Section 8.7.2.1.1 states
It is unclear exactly what split_window should do if the upper
window is currently selected. The author suggests that it should
work as usual, leaving the cursor where it is if the cursor is
still inside the new upper window, and otherwise moving the
cursor back to the top left. (This is analogous to the Version 6
practice.)
I understand why this was worded this way, but I would like, in version 1.1, to remove the implication that this is a suggestion. It is clear what to do, because that’s what the standard is for. There may be other similar language elsewhere that needs a little change.
Section 8, remarks:
Some ports of ITF apply buffering (i.e. word-wrapping) and
scrolling to the upper window, with unfortunate consequences.
This is why the standard Inform status line is one character
short of the width of the screen.
Is the standard Inform status line still one character short of the width of the screen?
The answer to this is “no”. The standard library definitely uses the whole width of the upper window for the status line. I may try to determine when this change occurred, if I can be bothered.
I’m not sure it’s really important anyway since the standard calls out the proper thing to do. The remark is really about Inform working around bugs in existing interpreters.
It’s not important for writing an interpreter, but I feel like, in the 1.1 spec at least, comments like this should be accurate about the current state of stuff. I’ll probably just change it to “early versions of the standard Inform status line” or something.
“ITF” was the first reverse engineered interpreter, right? I really doubt it would have any usage at all now, or any time in the past 20 years!
Hang on. I always read this as meaning that the DrawStatusLine() routine does not write text into the last column of the status window. This was true in I6 and it’s still true in I7. The standard moves/score message (or just score in I7) (with “Use scoring”) is drawn to leave one character of whitespace on the left margin and at least two on the right margin.