Let's say I enter X TV, and the parser finds two reachable objects which could be referred to as "TV".

I will get something like this:

Which do you mean?
  the new TV
  the old TV

I'd prefer this:

Which do you mean?
  1. the new TV
  2. the old TV

From there, I could type either "new TV" or "old TV", or "new" or "old", or enter 1 or 2.

That is my dream.

Getting close . . .

function showMenu(title, options, fn) {
  const opts = {article:DEFINITE, capital:true}
  parser.overrideWith(fn) // KV added this line so the player can type the answer if that's preferable.
  io.input(title, options, fn, function(options) {
    for (let i = 0; i < options.length; i++) {
      let s = parseInt(i+1) + '.<a class="menu-option" onclick="io.menuResponse(' + i + ');$(\'.menu-option\').hide();">' //KV added to onclick to hide the menu
      s += (typeof options[i] === 'string' ? options[i] : lang.getName(options[i], opts))
      s += '</a>';
      msg(s);
    }
  })
}

Now:

• The player can click or manually enter a response (thanks to parser.overrideWith).
• The menu will disappear after clicking, but I have to figure out how to make it disappear when the response is entered via parser.
• Hopefully, I'll figure out how to let the player manually enter the number of the choice as an extra option.

This code does not work with the disambiguation menu.

(I just learned this fact.)

I've given up trying to make the parser work with showMenu,.

Now, I just really want to learn how to make the input element disappear during the process and reappear afterwards. I can make it happen with a setTimeout, but it's sloppy.

I have had a look, and this is not trivial. I have got it to work, but hit other related issues with output, so still in progress.

ETA: I have uploaded to Github. It does what you want, plus you can also type in "old" to pick the old TV.

It has screwed up the text effects, so that is still a work in progress.

I have had a look, and this is not trivial. I have got it to work, but hit other related issues with output, so still in progress.

Yay!

Note that I thought I was smart adding the code to "onclick" that hides the menu after a selection, but I recently found out that is not good when nesting showMenus. With onclick hiding the menu element, the second showMenu has no menu. (Probably something simple I messed up.)

Also, maybe disabling showMenu links when the ui finishes the turn would keep the player from clicking a showMenu after it has been ignored?

Printing text to the screen is surprisingly complex. This has prompted me to start documenting it better.
https://github.com/ThePix/QuestJS/wiki/The-Output-Queue

Note that I thought I was smart adding the code to "onclick" that hides the menu after a selection, but I recently found out that is not good when nesting showMenus. With onclick hiding the menu element, the second showMenu has no menu. (Probably something simple I messed up.)

Order of execution, I think.

You're running menuResponse, which I would assume handles the response (such as displaying a submenu), and then hides all menu options on the screen.

You might need to swap the order of those instructions in the 'onclick' attribute, so the options are hidden before displaying the second menu.

Or even better, put the hide instruction inside the menuResponse method (assuming it's equivalent to Quest5.8's ShowMenuResponse), so that if you can get the parser working the options will still disappear.

(If I were doing it using the method you showed, I'd likely change it to: onclick="$(\'.menu-option\').not($(this).removeProp(\'onclick\')).hide();io.menuResponse(' + i + ');" - maybe not for disambiguation menus, but I often find games confusing when a menu disappears. I prefer the version that disables the option they clicked on (so they can't click it again), and removes all the others)

Printing text to the screen is surprisingly complex. This has prompted me to start documenting it better.

Rock on!

I was just gave up trying to get msg, _msg, or printRaw to do what I wanted (which was, admittedly, something weird) about three minutes ago, to no avail.

I often find games confusing when a menu disappears. I prefer the version that disables the option they clicked on (so they can't click it again), and removes all the others)

This is a good point. Now that you mention it, I do prefer this behavior.

This disables existing showMenu links:

$(".menu-option").attr('onclick','').attr('style','color:inherit')

Think I got this right:
.attr('onclick','') or .removeAttr('onclick') has no effect in Internet Explorer 6, 7, or 8.

.prop('onclick', null) or .removeProp('onclick') is the usual way to do this ("attr" is only guaranteed to affect the text attribute stored in the HTML tree; "prop" affects the JS in the DOM even if it's already been compiled)

.prop('onclick', null).off('click') is the recommended method which is supposed to work with any browser and version; but I've never seen anyone use it in the real world because it's overkill.

Though I doubt anyone's using IE 8 anymore, so using whichever you're used to is probably just as good.

Oh, that cross-browser compatibility . . .

It's very discouraging at times.