bug#57372: no-toolkit menu popups do not respect emacs font configuration

[Tomas Hlavaty]

On Wed 24 Aug 2022 at 19:32, Eli Zaretskii <eliz@gnu.org> wrote:
>> TTY menus seem fine except the extra > in menu-bar overlaps the next
>> menu-bar item text.
>
> That's by design, btw.

Strange design.  Say I want to open the Edit menu.  I press F10 and
suddenly I cannot see the Edit menu anymore.

> The implementation is extremely tricky, and basically blocks any input
> as long as the menu is dropped down.  It works by overwriting portions
> of the frame display's glyph matrices.  There are also complications
> with binding keys to menu commands and with calculating the
> coordinates where we need to drop down the menu.
[...]
>> In principle, it would be enough for me if the no-toolkit menus
>> worked similar to TTY menus but respected faces instead of alien X
>> resources.
>
> TTY menus work, the tricky issues notwithstanding, because there's
> only one font on TTY frames, and thus each line of the menu text
> overwrites some part of exactly one line of the frame display.  That
> is not possible to achieve on GUI frames, because faces and fonts
> differ.  So the same technique as we use for TTY menus will not work
> for GUI frame,s unfortunately, and if we try going that way in the X
> no-toolkit build, the code will have to be much more complicated (if
> it's at all feasible), and I think the result will be uglier.

I see that there are a lot of complications.

What about doing it differently?  For no-toolkit Emacs, it would be
enough for me if the menu simply opened a *Menu* buffer with the
relevant menu items.  All those issues would suddenly disappear.