I just did some beta-testing for an Inform 7 game using a recent version of Lectrote, and used transcripting.
I noticed after using the menu system in the game, the menu text has been added to the transcript (this doesn’t happen in TADS by default). Every single time I hit the down arrow to point to a different menu item, the whole menu is printed again to the transcript. For a menu-style in-game walkthrough of 75 hints, all viewed hints were printed anew in the transcript every time I hit “next” for the next hint. My transcript was as long as an encyclopedia with a bunch of text that is no help to the game author.
Surely nobody wants this behavior! Is this the way Inform handles things by default? Or is it interpreter specific? If it’s Inform, somebody definitely needs to make a modified transcripting module!
I am not currently an Inform user myself, but I’ve just recently started doing some parser game beta-testing, so I expect this issue might crop up again. Thanks if anyone has input!
I’ve run into this quirk as well using Gargoyle, so I suspect it’s not interpreter-specific (my sense is most I7 authors use Emily Short’s Menu’s extension, so could be something in the implementation there is the reason why?)
This is one reason I typically ask testers to preface their comments with an asterisk or some other lesser-used character; among the many other upsides, that allows a simple CTRL-F to skip over a clog of menu-text to get to the next significant bit!
I do preface comments with an asterisk, but as an author, I’m interested in looking over more than just what my testers flag. I see blocks of text out of place or special responses that didn’t show, that a tester wouldn’t know to flag. So I can only assume other authors would be interested in scanning the whole transcript also…
If a menu is being displayed in a window that is being echoed to a transcript, and the way the menu is updated is by clearing the window and reprinting it, then yes, it will be sent to the transcript multiple times. There’s no way around that.
That said, the Glk TADS port does seem to be closing and reopening windows more than it should really need to.
Surely a few lines of code could suspend the transcript writing when a menu is entered? TADS doesn’t transcript the menu navigating, and even if it did by default, it seems like it would be an easy thing to suspend…
Hmm, potentially that could work. I’d know how to do it in Glulx, but not TADS3.
The game in question doesn’t credit Emily Short’s extension, so I don’t know that that’s it…
Yeah, the behaviour you describe is simply the output behaviour of that famous extension. You can’t avoid it in a game that was built on it.
That behaviour was one of the motivations for me to make a new Menus extension, which is also in the public library. Menus are navigated with single keypresses. So I can’t help you on a pre-existing game, but if you want to avoid this behaviour in something you make, I would recommend my extension. (I note the OP isn’t actually using Inform, but this post still serves as a public service announcement for my extension that almost nobody remembers is there, or uses.)
-Wade
Good for you, Wade… hopefully more people will take notice of your work. Perhaps Emily could be persuaded to make (or let be made) a few modifications to hers too?
I doubt she’ll want to revisit hers 
Mine reproduces hers, minus the menu-navigation spam, and adds a few other things. The presence of out-of-world menus overall has become a lot less popular in parser games since the heyday of her extension.
-Wade
FWIW I’ve been using it, Wade. It has some really cool features.