bug#15576: 24.3.50; Some minor issues regarding the new TTY menus

[Stefan Monnier <monnier@iro.umontreal.ca>]

> I think "Select Buffer" is wrong simply because it is different from
> "Buffers".  I mean, what is the point of showing one text (Buffers)
> when the menu is not selected, and another text (Select Buffer) when
> it is?  I've not seen such a thing before anywhere, and I don't see
> what sense it does make.

You'd see it if you build Emacs with X11 but without GUI toolkit.
This used to be the only case where the "keymap prompt" is used for the
menus (it's also used for the title of the popup menus, tho).

It's largely a historical accident, but here's the technical background:
menus are represented in Emacs as keymaps which (as a first
approximation) are alists mapping events to "menu-items".  A menu-item
is (again, to a first approximation) a pair of a chunk of text (to be
displayed in the menu) and the corresponding binding (either a command
or another keymap if it's a submenu).
When you get a "submenu", the submenu is just the (sub)keymap, rather
than the menu-item that holds this sub-keymap, so you don't know the
name that was displayed for that submenu.  So in order to display
a "title", you need the keymap to carry a "name" (which is called the
keymap-prompt).
IOW for each submenu, you have 3 more or less equivalent/redundant "names":
- the text to display in the parent menu (i.e. the only thing usually
  displayed).
- the "prompt" (which is only displayed if you pass that submenu to
  directly popup-menu, or if you use the non-toolkit version of Emacs,
  or now in the tty-menu code).
- the event associated with this submenu.  It's usually a symbol rather
  than a string (because it's compared with `eq'; and it can also be an
  integer), but it's often just a symbol version of the "menu name".
Those 3 can all be completely different, but normally/usually
they're identical.

> That's a pity.  It would be nice to have those drop-down text menus
> also on GUI sessions.

Why?

>> I tend to close this as not-a-bug.  Any reasons not to?
> See above, but you are the maintainer, so you decide.

IIUC the issue is that fixing those things can represent a lot of work,
whereas they fix only "cosmetic" issues, so it's difficult to justify
the effort.


        Stefan