I don’t believe so. As @johnnywz00 said, there’s three source files that implement the menu system:
menusys.t (base classes),
menucon.t (subclasses for console/HTML interpreters), and
menuweb.t (for web-based TADS, I don’t think you need to worry about that).
Now, those classes do rely on the Banner API to some degree as part of the menu display, placing the menus’ topmost title and some key help in the status line. I believe the Banner API is ultimately implemented by the interpreter.
The above three files are in both adv3 and adv3Lite. The adv3Lite docs on menus claim its system “is identical to the adv3 module of the same name,” but I haven’t done a diff to verify that. (I would think any differences are minor. When I tried the
INSTRUCTIONS command on both libraries, it looked and operated fundamentally the same with both.)
When I run a TADS 3 game with FrobTADS and QTads, the menus display a single
> for the cursor and blanks everywhere else, with no reversed characters.
At least I thought that until I noticed in the code this being done:
* To get the alignment right, we have to print '>' on
* each and every line. However, we print it in the
* background color to make it invisible everywhere but
* in front of the current selection.
if (selection != i)
"<font color=<<bgcolor>> >></font>";
Perhaps that’s what you’re seeing, the
>") being printed in the background color in order to hide it?
To make sure we’re on the same page, my understanding is that FrobTADS is considered an HTML interpreter even though it’s a console/terminal application. It’s “HTML-aware.” So, I believe it and QTads are executing the above code.
An HTML-aware interpreter will “eat” extraneous whitespace. (Actually, I think all TADS interpreters do that, but let’s set that aside for the moment.) The above trick ensures the menu text is left-aligned down the screen, with the visible
> cursor moving up and down to their immediate left.
I don’t know who, if anyone, is maintaining the libraries at the moment. More importantly, updating the libraries today won’t fix all the compiled TADS games already out there with this behavior. If I’m right and the above code is the issue, perhaps it can be easily worked around by the interpreters?