bug#50067: Context menus

[Eli Zaretskii]

> Date: Wed, 18 Aug 2021 21:12:58 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: alan@idiocy.org, mattiase@acm.org, homeros.misasa@gmail.com,
>  tkk@misasa.okayama-u.ac.jp, larsi@gnus.org, 50067@debbugs.gnu.org
> 
> > > I see you already pushed this, but it's a bad idea: it makes ugly
> > > context menus on TTYs (and AFAIU also on non-toolkit X builds): these
> > > _require_ the menu name because they display a caption which looks bad
> > > with an empty name.
> > 
> > I guess the presence of the title should be platform-dependent.
> > For example, without a title it looks great on the GTK build.
> 
> What happens if the GTK build displays a TTY frame?  Isn't the menu
> definition global, and thus doesn't distinguish between frame types?

Come to think about it: aren't menu keymaps _required_ to have this
string?  The ELisp manual says:

   -- Function: make-sparse-keymap &optional prompt
       This function creates and returns a new sparse keymap with no
       entries.  (A sparse keymap is the kind of keymap you usually want.)
       The new keymap does not contain a char-table, unlike ‘make-keymap’,
       and does not bind any events.

            (make-sparse-keymap)
                ⇒ (keymap)

       If you specify PROMPT, that becomes the overall prompt string for
       the keymap.  You should specify this only for menu keymaps (*note
       Defining Menus::).  A keymap with an overall prompt string will
       always present a mouse menu or a keyboard menu if it is active for
       looking up the next input event.

Stefan, did we remove this requirement at some point, or is it still a
requirement?

If this is still needed (and it seems to be, at least on some frame
types), I guess it's the code which produces native menus that wants
not to have this caption (e.g., on macOS and GTK) -- that code should
ignore this string and not stuff it into the native menu widget.  But
internally the menu name should still be present in the Lisp data
structure.