GNU bug report logs -
#57372
no-toolkit menu popups do not respect emacs font configuration
Previous Next
Full log
View this message in rfc822 format
On Wed 24 Aug 2022 at 19:32, Eli Zaretskii <eliz <at> 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.
This bug report was last modified 2 years and 283 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.