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

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

[Tomas Hlavaty]

Hi

I would like to switch to no-toolkit gui emacs 28 but popped up menus do
not respect emacs font configuration.  This looks like the only thing
preventing me from switching.  (Unlike any toolkit emacs, menu bar with
no-toolkit uses the right font.)

I have this in my gui .emacs:

(custom-set-faces
 '(default ((t (:inherit nil :stipple nil :background "white" :foreground "black" :inverse-video nil :box nil :strike-through nil :overline nil :underline nil :slant normal :weight normal :height 200 :width normal :foundry "PfEd" :family "DejaVu Sans Mono")))))

and it seems that the only thing which does not respect that
configuration is the popped up menu text.

I often use C-+ and C-- to resize the default font and this does not
work in menus (except with the console emacs obviously, where there is
one font only and is resized by the console and not emacs).

emacs font resizing I found in emacs works per buffer but I want
it to work globally so I use:

(defun text-height ()
  (face-attribute 'default :height))
(defun set-text-height (new-height)
  (set-face-attribute 'default nil :height new-height))
(defvar text-height-factor (sqrt (sqrt 2)))
(defvar text-height-min 50)
(defvar text-height-max 500)
(defvar text-height-default (text-height))
(defun increase-text-height ()
  (interactive)
  (set-text-height
    (min text-height-max
         (round (* (text-height) text-height-factor)))))
(defun decrease-text-height ()
  (interactive)
  (set-text-height
    (max text-height-min
         (round (/ (text-height) text-height-factor)))))
(defun reset-text-height ()
  (interactive)
  (set-text-height text-height-default))
(global-set-key (kbd "C-+") 'increase-text-height)
(global-set-key (kbd "C--") 'decrease-text-height)
(global-set-key (kbd "C-0") 'reset-text-height)
(global-set-key (kbd "C-<mouse-4>") 'increase-text-height)
(global-set-key (kbd "C-<mouse-5>") 'decrease-text-height)

Would it be possible for no-toolkit emacs also respect the default font
in popped up menus?

Regards

Tomas

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

[Eli Zaretskii]

> From: Tomas Hlavaty <tom@logand.com>
> Date: Tue, 23 Aug 2022 22:47:42 +0200
> 
> I often use C-+ and C-- to resize the default font and this does not
> work in menus (except with the console emacs obviously, where there is
> one font only and is resized by the console and not emacs).

The font used for menus in the no-toolkit build is not the default
face's font, so it doesn't resize.  That font is determined by X
resources, see the relevant node in the Emacs manual.

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

[Tomas Hlavaty]

Hi Eli,

On Wed 24 Aug 2022 at 05:29, Eli Zaretskii <eliz@gnu.org> wrote:
>> I often use C-+ and C-- to resize the default font and this does not
>> work in menus (except with the console emacs obviously, where there is
>> one font only and is resized by the console and not emacs).
>
> The font used for menus in the no-toolkit build is not the default
> face's font, so it doesn't resize.  That font is determined by X
> resources, see the relevant node in the Emacs manual.

yes, and that is not good and would be nice if it was improved.

For example, on my system, the default X resources font used in
no-toolkit emacs is too small and changing it is rather inconvenient.
So when I choose a default face in .emacs, most of the no-toolkit emacs
does what I expect, except the popped up menu text, which is unreadable.

Would it be possible to change it so that even this popped up menu text
font is not determined by X resources but by the usual emacs face
mechanism?

Regards,

Tomas

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Tomas Hlavaty <tom@logand.com> writes:

> Would it be possible to change it so that even this popped up menu text
> font is not determined by X resources but by the usual emacs face
> mechanism?

No.

The no toolkit menu is implemented with a copy of a library deleted from
the X11 distribution in X11R3, which was released during Oct 1988.  The
library has not seen any updates since then.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  57372@debbugs.gnu.org
> Date: Wed, 24 Aug 2022 18:56:17 +0800
> 
> Tomas Hlavaty <tom@logand.com> writes:
> 
> > Would it be possible to change it so that even this popped up menu text
> > font is not determined by X resources but by the usual emacs face
> > mechanism?
> 
> No.

Well, "no" is never correct when we deal with software ;-)

But yes, it should be quite a project.  The basic problem here is that
menus are not displayed by the Emacs display engine, they are
displayed by a separate code (which we "stole" from X11).

Displaying pop-down menus with our display engine is "tricky", as the
TTY menus experience amply shows.

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

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

>> Would it be possible to change it so that even this popped up menu text
>> font is not determined by X resources but by the usual emacs face
>> mechanism?
>
> No.

Of course it's possible.  We have the code, and we can change it to do
whatever we want.

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> Well, "no" is never correct when we deal with software ;-)
>
> But yes, it should be quite a project.  The basic problem here is that
> menus are not displayed by the Emacs display engine, they are
> displayed by a separate code (which we "stole" from X11).
>
> Displaying pop-down menus with our display engine is "tricky", as the
> TTY menus experience amply shows.

Indeed, though it should be easier if each pane is a separate frame.

I've been trying to figure out if it is possible to implement menus as
frames, mostly in Lisp.

The problem is that creating frames is too slow for responsive menus,
and from skimming various pieces of documentation, it seems that there
is no portable way to transfer the grab from the first frame to other
leaf frames as they are created.  The main problems here are Wayland and
macOS, where the APIs required to implement correct menu grabbing
behavior are not exposed by GTK or Cocoa.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: tom@logand.com,  57372@debbugs.gnu.org
> Date: Wed, 24 Aug 2022 20:11:54 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Displaying pop-down menus with our display engine is "tricky", as the
> > TTY menus experience amply shows.
> 
> Indeed, though it should be easier if each pane is a separate frame.

Frames are a bad basis for menus: they (the frames) are too
heavyweight for a menu, so the resulting menus will look ugly.

And there are other issues that make this unattractive: e.g., how do
you make a frame unmovable (which is required for sub-menus)?

If we want good-looking menus independent of any toolkit, we should
try to find a small library capable of producing them on popular GUI
platforms.

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> Frames are a bad basis for menus: they (the frames) are too
> heavyweight for a menu, so the resulting menus will look ugly.

Well, undecorated frames don't look bad, but creating them takes a long
time.  The next thing I'll try is to create menu frames with something
similar to the tooltip frame code, but that will probably have other
consequences too, and move more code into C.

> And there are other issues that make this unattractive: e.g., how do
> you make a frame unmovable (which is required for sub-menus)?

By setting the `override-redirect' frame parameter (or `undecorated' on
platforms where the former isn't supported), like any other program.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: tom@logand.com,  57372@debbugs.gnu.org
> Date: Wed, 24 Aug 2022 20:34:33 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Frames are a bad basis for menus: they (the frames) are too
> > heavyweight for a menu, so the resulting menus will look ugly.
> 
> Well, undecorated frames don't look bad

They do, they do.  The look nothing like menus.  They look like text
panes.

> > And there are other issues that make this unattractive: e.g., how do
> > you make a frame unmovable (which is required for sub-menus)?
> 
> By setting the `override-redirect' frame parameter (or `undecorated' on
> platforms where the former isn't supported), like any other program.

And then the user has some defaults for frame parameters that break
this, yes?

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> They do, they do.  The look nothing like menus.  They look like text
> panes.

Still better than what the current status quo for no toolkit builds is,
which is a giant text pane, but without anti-aliasing.

> And then the user has some defaults for frame parameters that break
> this, yes?

You can't break `override-redirect'; besides, we could simply ignore
those defaults on menu frames.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: tom@logand.com,  57372@debbugs.gnu.org
> Date: Wed, 24 Aug 2022 21:01:42 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > They do, they do.  The look nothing like menus.  They look like text
> > panes.
> 
> Still better than what the current status quo for no toolkit builds is,
> which is a giant text pane, but without anti-aliasing.

"Still better" and "good enough" aren't necessarily the same.

> > And then the user has some defaults for frame parameters that break
> > this, yes?
> 
> You can't break `override-redirect'; besides, we could simply ignore
> those defaults on menu frames.

As soon as people understand these are frames, you're done: they will
want every frame-related feature to work there.

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> "Still better" and "good enough" aren't necessarily the same.

At least, it will be enough to close this bug.

> As soon as people understand these are frames, you're done: they will
> want every frame-related feature to work there.

What about tooltip frames? They are also override-redirect (and in a way
that can't be turned off.)

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: tom@logand.com,  57372@debbugs.gnu.org
> Date: Wed, 24 Aug 2022 21:23:12 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > "Still better" and "good enough" aren't necessarily the same.
> 
> At least, it will be enough to close this bug.
> 
> > As soon as people understand these are frames, you're done: they will
> > want every frame-related feature to work there.
> 
> What about tooltip frames?

What about them?

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> What about them?

They are also implemented as a special kind of override-redirect frame,
and I don't see people complaining.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: tom@logand.com,  57372@debbugs.gnu.org
> Date: Wed, 24 Aug 2022 21:39:33 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > What about them?
> 
> They are also implemented as a special kind of override-redirect frame,
> and I don't see people complaining.

How many tooltips do you see in a production session of Emacs?

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

[Tomas Hlavaty]

On Wed 24 Aug 2022 at 18:56, Po Lu <luangruo@yahoo.com> wrote:
> The no toolkit menu is implemented with a copy of a library deleted from
> the X11 distribution in X11R3, which was released during Oct 1988.  The
> library has not seen any updates since then.

Maybe this could be a good opportunity to get rid of that library?

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

[Tomas Hlavaty]

On Wed 24 Aug 2022 at 14:23, Eli Zaretskii <eliz@gnu.org> wrote:
> Displaying pop-down menus with our display engine is "tricky", as the
> TTY menus experience amply shows.

What does the tty menus experience show?

TTY menus seem fine except the extra > in menu-bar overlaps the next
menu-bar item text.  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.

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

[Eli Zaretskii]

> From: Tomas Hlavaty <tom@logand.com>
> Cc: 57372@debbugs.gnu.org
> Date: Wed, 24 Aug 2022 18:15:14 +0200
> 
> On Wed 24 Aug 2022 at 14:23, Eli Zaretskii <eliz@gnu.org> wrote:
> > Displaying pop-down menus with our display engine is "tricky", as the
> > TTY menus experience amply shows.
> 
> What does the tty menus experience show?

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.

> TTY menus seem fine except the extra > in menu-bar overlaps the next
> menu-bar item text.

That's by design, btw.

> 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.

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

[Tomas Hlavaty]

On Wed 24 Aug 2022 at 15:27, Eli Zaretskii <eliz@gnu.org> wrote:
> Frames are a bad basis for menus: they (the frames) are too
> heavyweight for a menu, so the resulting menus will look ugly.

I find the alien X resource fonts the ugliest, unreadable and very
inconvenient because the font size is completely wrong and inconvenient
to control.

> If we want good-looking menus independent of any toolkit, we should
> try to find a small library capable of producing them on popular GUI
> platforms.

I do not care much for whatever ugly look the popped up menus have as
long as they respect faces.  It is just a few lines of text so surely
that cannot be that ugly if the font fits with the chosen emacs face and
not some alien X resource or toolkit/desktop font specific configuration
which is completely out of sync from my emacs face configuration.

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

[Eli Zaretskii]

> From: Tomas Hlavaty <tom@logand.com>
> Cc: 57372@debbugs.gnu.org
> Date: Wed, 24 Aug 2022 19:49:23 +0200
> 
> On Wed 24 Aug 2022 at 15:27, Eli Zaretskii <eliz@gnu.org> wrote:
> > Frames are a bad basis for menus: they (the frames) are too
> > heavyweight for a menu, so the resulting menus will look ugly.
> 
> I find the alien X resource fonts the ugliest, unreadable and very
> inconvenient because the font size is completely wrong and inconvenient
> to control.

But you can customize that via the X resources, can't you?  Just tell
the menus to use the same font Emacs uses for its default face.

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.

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

[Tomas Hlavaty]

On Wed 24 Aug 2022 at 20:59, Eli Zaretskii <eliz@gnu.org> wrote:
>> I find the alien X resource fonts the ugliest, unreadable and very
>> inconvenient because the font size is completely wrong and inconvenient
>> to control.
>
> But you can customize that via the X resources, can't you?  Just tell
> the menus to use the same font Emacs uses for its default face.

I suppose it is possible, but complex and inconvenient.
Why do I need to do that in the first place?

In my example, I had a function like this:

(defun set-text-height (new-height)
  (set-face-attribute 'default nil :height new-height))

How could I achieve what you suggest so that setting the font height
would also apply to menu item X resource font?

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

[Tomas Hlavaty]

On Wed 24 Aug 2022 at 17:23, Eli Zaretskii <eliz@gnu.org> wrote:
>> They are also implemented as a special kind of override-redirect frame,
>> and I don't see people complaining.
>
> How many tooltips do you see in a production session of Emacs?

For example tool-bar has fancy icons but no text.  I have no idea what
those icons mean so I have to wait for the tooltips to show up.  They
are essential for tool-bar because somehow including text in tool-bar
stopped being a thing a few years ago?  Or is it possible?

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

[Eli Zaretskii]

> From: Tomas Hlavaty <tom@logand.com>
> Cc: luangruo@yahoo.com, 57372@debbugs.gnu.org
> Date: Wed, 24 Aug 2022 20:54:24 +0200
> 
> 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 drop-down menu also hides part of the window's text, doesn't
it?  More generally, _something_ has to be hidden, because this is a
text-mode terminal: the menu cannot move outside of the frame, where
it wouldn't overlap any of the windows.

So why is it important that the Edit menu is hidden, but not that the
whole text below the File menu is suddenly unreadable.

> 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.

That already exists: use tmm-menubar.

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

[Eli Zaretskii]

> From: Tomas Hlavaty <tom@logand.com>
> Cc: luangruo@yahoo.com, 57372@debbugs.gnu.org
> Date: Wed, 24 Aug 2022 21:01:20 +0200
> 
> On Wed 24 Aug 2022 at 20:59, Eli Zaretskii <eliz@gnu.org> wrote:
> >> I find the alien X resource fonts the ugliest, unreadable and very
> >> inconvenient because the font size is completely wrong and inconvenient
> >> to control.
> >
> > But you can customize that via the X resources, can't you?  Just tell
> > the menus to use the same font Emacs uses for its default face.
> 
> I suppose it is possible, but complex and inconvenient.
> Why do I need to do that in the first place?
> 
> In my example, I had a function like this:
> 
> (defun set-text-height (new-height)
>   (set-face-attribute 'default nil :height new-height))
> 
> How could I achieve what you suggest so that setting the font height
> would also apply to menu item X resource font?

Make the function write to the ~/.Xresources file?

Of course, X doesn't necessarily understand the Emacs units of
measuring fonts, for example the relative units.  So eventually you'll
need separate customizations.  However, I don't expect you to have to
change these customizations too frequently.

More generally, I don't see a way around the fact that different parts
of the system need to be customized differently.  Many programs have
their own init files, and some even have more than one: for example,
Bash, GDB, and any other program that uses Readline will typically
have customizations in ~/.inputrc, in addition to the program-specific
init file, such as ~/.gdbinit for GDB.

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

[Eli Zaretskii]

> From: Tomas Hlavaty <tom@logand.com>
> Cc: 57372@debbugs.gnu.org
> Date: Wed, 24 Aug 2022 21:07:01 +0200
> 
> On Wed 24 Aug 2022 at 17:23, Eli Zaretskii <eliz@gnu.org> wrote:
> >> They are also implemented as a special kind of override-redirect frame,
> >> and I don't see people complaining.
> >
> > How many tooltips do you see in a production session of Emacs?
> 
> For example tool-bar has fancy icons but no text.  I have no idea what
> those icons mean so I have to wait for the tooltips to show up.

That is very strange for me to hear.  Most GUI programs I deal with
every day don't have any text to go with their tool bars.

> They are essential for tool-bar because somehow including text in
> tool-bar stopped being a thing a few years ago?  Or is it possible?

I believe the GTK tool bar shows text near the icons.  To my opinion,
that is a waste of space, but I guess to everyone their own.

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

[Tomas Hlavaty]

On Wed 24 Aug 2022 at 22:33, Eli Zaretskii <eliz@gnu.org> wrote:
>> (defun set-text-height (new-height)
>>   (set-face-attribute 'default nil :height new-height))
>> 
>> How could I achieve what you suggest so that setting the font height
>> would also apply to menu item X resource font?
>
> Make the function write to the ~/.Xresources file?
>
> Of course, X doesn't necessarily understand the Emacs units of
> measuring fonts, for example the relative units.  So eventually you'll
> need separate customizations.  However, I don't expect you to have to
> change these customizations too frequently.

The point of C-+ and C-- bindings is that I can just press a key and
grow or shrink the font.  That is essential for me.  My gui terminal can
do that out of the box, my console can do that with a bit of elisp
calling setfont, firefox can do that out of the box, and gui Emacs can
do that using the code I showed earlier; except the menu text we are
discussing.

This font size change happens on demand, when a key is pressed.

I guess writing to the ~/.Xresources file would work only on startup.

Then there seems to be the issue you said that Emacs and X has different
idea of describing fonts/units.

It is just complex and inconvenient.

> More generally, I don't see a way around the fact that different parts
> of the system need to be customized differently.

Why?

At the moment, it is the consequence of the way the no-toolkit menu is
implemented.

But surely it could be possible to change it to customize no-toolkit
menu text the same way as any other face.

> Many programs have
> their own init files, and some even have more than one: for example,
> Bash, GDB, and any other program that uses Readline will typically
> have customizations in ~/.inputrc, in addition to the program-specific
> init file, such as ~/.gdbinit for GDB.

This is not only about init files.

This is about making it not to have more init files, because unlike
customizing and changing faces, customizing a different system out of
Emacs is complex, fragile, inconvenient and might be impossible (is it
possible to change the menu text X resource on key press?).

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

[Tomas Hlavaty]

On Wed 24 Aug 2022 at 22:28, 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 drop-down menu also hides part of the window's text, doesn't
> it?  More generally, _something_ has to be hidden, because this is a
> text-mode terminal: the menu cannot move outside of the frame, where
> it wouldn't overlap any of the windows.

That is not the issue.
Why does the Edit menu dissappear?
Because there are three extra charactes drawn over it.
Say the menu-bar looks like this:
File Edit Options
Press F10 and it looks like this:
 File > t Options
Where is my Edit menu?
What should I do now?

> So why is it important that the Edit menu is hidden, but not that the
> whole text below the File menu is suddenly unreadable.

Because when I want to open the Edit menu, my attention is on the Edit
menu and not on some other stuff somewhere else.  After pressing F10,
the Edit menu I saw earlier disappears.  I expect to see the Edit menu
the whole time I am trying to navigate to it.

>> 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.
>
> That already exists: use tmm-menubar.

Thank you for the pointer.
It looks like the thing that pops up on F10 when menu-bar-mode is nil.
iirc I haven't used it because I found it unuseable
but a solution like that could probably work for me.
I'll have to try it a bit more.

Is there a reason, why is tmm-menubar restricted to tty?
The choice seems hardcoded in menu-bar-open.
I had to do this:
(defun x-menu-bar-open (frame)
  (with-selected-frame (or frame (selected-frame))
    (tmm-menubar)))
in order to use tmm-menubar on no-toolkit Emacs.
It would be nicer, if the cond in menu-bar-open was replaced
with run-hook-with-args-until-success and a customizable
open-menu-bar-functions variable.

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

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> I believe the GTK tool bar shows text near the icons.  To my opinion,
> that is a waste of space, but I guess to everyone their own.

Agreed.

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> How many tooltips do you see in a production session of Emacs?

Not many, but still nobody has complained about the special-ness of
their frames.

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Tomas Hlavaty <tom@logand.com> writes:

> Maybe this could be a good opportunity to get rid of that library?

What would the replacement be?

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Tomas Hlavaty <tom@logand.com> writes:

> I find the alien X resource fonts the ugliest, unreadable and very
> inconvenient because the font size is completely wrong and inconvenient
> to control.

Isn't that a misnomer?  Those are not "X resource fonts", those are core
X fonts, the legacy X font subsystem.

> I do not care much for whatever ugly look the popped up menus have as
> long as they respect faces.  It is just a few lines of text so surely
> that cannot be that ugly if the font fits with the chosen emacs face and
> not some alien X resource or toolkit/desktop font specific configuration
> which is completely out of sync from my emacs face configuration.

Well, that will be very difficult to do ith most toolkits as well.

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Tomas Hlavaty <tom@logand.com> writes:

> I suppose it is possible, but complex and inconvenient.
> Why do I need to do that in the first place?

Because that is how the old XMenu library, and most other X programs,
work.

> In my example, I had a function like this:
>
> (defun set-text-height (new-height)
>   (set-face-attribute 'default nil :height new-height))
>
> How could I achieve what you suggest so that setting the font height
> would also apply to menu item X resource font?

X core fonts are not scalable, so they do not support having their
height set.

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> Make the function write to the ~/.Xresources file?

FTR, you have to install the resources onto the root window as well:

  xrdb -merge ~/.Xresources

> Of course, X doesn't necessarily understand the Emacs units of
> measuring fonts, for example the relative units.  So eventually you'll
> need separate customizations.  However, I don't expect you to have to
> change these customizations too frequently.

Yes.  The X core fonts used by the XMenu library aren't scalable, so
there is no way to tell it a desired height.  You should probably pick
from the fonts in x-fixed-font-alist (6x10 is a fixed font where glyphs
are 6 pixels wide and 10 pixels tall, 8x13 has glyphs that are 8 pixels
wide and 13 pixels tall, etc.)

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Tomas Hlavaty <tom@logand.com> writes:

> The point of C-+ and C-- bindings is that I can just press a key and
> grow or shrink the font.  That is essential for me.  My gui terminal can
> do that out of the box, my console can do that with a bit of elisp
> calling setfont, firefox can do that out of the box, and gui Emacs can
> do that using the code I showed earlier; except the menu text we are
> discussing.
>
> This font size change happens on demand, when a key is pressed.
>
> I guess writing to the ~/.Xresources file would work only on startup.
>
> Then there seems to be the issue you said that Emacs and X has different
> idea of describing fonts/units.
>
> It is just complex and inconvenient.

That's what happens if you use libraries for menus, since they obviously
know nothing about what faces are.

>> More generally, I don't see a way around the fact that different parts
>> of the system need to be customized differently.
>
> Why?
>
> At the moment, it is the consequence of the way the no-toolkit menu is
> implemented.
>
> But surely it could be possible to change it to customize no-toolkit
> menu text the same way as any other face.

Possible, but very difficult.  It's easier to do that on Motif and
Lucid, but that is still not reliable, since different font subsystems
are being used.

> This is about making it not to have more init files, because unlike
> customizing and changing faces, customizing a different system out of
> Emacs is complex, fragile, inconvenient and might be impossible (is it
> possible to change the menu text X resource on key press?).

No, Emacs only loads the X resource database on display initialization.

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

[Eli Zaretskii]

> From: Tomas Hlavaty <tom@logand.com>
> Cc: luangruo@yahoo.com, 57372@debbugs.gnu.org
> Date: Wed, 24 Aug 2022 23:57:44 +0200
> 
> > Of course, X doesn't necessarily understand the Emacs units of
> > measuring fonts, for example the relative units.  So eventually you'll
> > need separate customizations.  However, I don't expect you to have to
> > change these customizations too frequently.
> 
> The point of C-+ and C-- bindings is that I can just press a key and
> grow or shrink the font.  That is essential for me.  My gui terminal can
> do that out of the box, my console can do that with a bit of elisp
> calling setfont, firefox can do that out of the box, and gui Emacs can
> do that using the code I showed earlier; except the menu text we are
> discussing.
> 
> This font size change happens on demand, when a key is pressed.

Do you really need to do this frequently?  If so, why is that? why not
set the size that is convenient for you, and more or less forget about
it?

I guess I don't understand why one would need to change the size
frequently, especially the size of the menu items, which basically
stay unchanged.

> Then there seems to be the issue you said that Emacs and X has different
> idea of describing fonts/units.
> 
> It is just complex and inconvenient.

But you should only need to do this once, or very infrequently.  So
how is this such a grave problem?

> > More generally, I don't see a way around the fact that different parts
> > of the system need to be customized differently.
> 
> Why?

Because they are different subsystems developed by different agencies
with different goals in mind.

> > Many programs have
> > their own init files, and some even have more than one: for example,
> > Bash, GDB, and any other program that uses Readline will typically
> > have customizations in ~/.inputrc, in addition to the program-specific
> > init file, such as ~/.gdbinit for GDB.
> 
> This is not only about init files.
> 
> This is about making it not to have more init files, because unlike
> customizing and changing faces, customizing a different system out of
> Emacs is complex, fragile, inconvenient and might be impossible (is it
> possible to change the menu text X resource on key press?).

I find it neither complex nor fragile: just edit a file, and that's
it.  If it's something you don't need to do frequently (as I think
what should happen with font sizes), it's a fire-and-forget thing.

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

[Eli Zaretskii]

> From: Tomas Hlavaty <tom@logand.com>
> Cc: luangruo@yahoo.com, 57372@debbugs.gnu.org
> Date: Thu, 25 Aug 2022 00:59:22 +0200
> 
> >> Strange design.  Say I want to open the Edit menu.  I press F10 and
> >> suddenly I cannot see the Edit menu anymore.
> >
> > ??? The drop-down menu also hides part of the window's text, doesn't
> > it?  More generally, _something_ has to be hidden, because this is a
> > text-mode terminal: the menu cannot move outside of the frame, where
> > it wouldn't overlap any of the windows.
> 
> That is not the issue.
> Why does the Edit menu dissappear?

Because the File menu has certain width requirements, and because the
screen estate is at premium.

> Say the menu-bar looks like this:
> File Edit Options
> Press F10 and it looks like this:
>  File > t Options
> Where is my Edit menu?
> What should I do now?

If you need to use the File menu, you shouldn't be bothered about the
Edit menu.  If you want to use the Edit menu, press C-f or the <RIGHT>
arrow key, and Emacs will close the File menu and open the Edit menu
instead.

> > So why is it important that the Edit menu is hidden, but not that the
> > whole text below the File menu is suddenly unreadable.
> 
> Because when I want to open the Edit menu, my attention is on the Edit
> menu and not on some other stuff somewhere else.  After pressing F10,
> the Edit menu I saw earlier disappears.  I expect to see the Edit menu
> the whole time I am trying to navigate to it.

If you have a mouse that works on the TTY frames (either GPM or
xterm-mouse mode), you can click directly at Edit and open the Edit
menu instead of (the default) File menu.  Otherwise, use the arrow
keys or C-f/C-b to move between the top-level menus.

> Is there a reason, why is tmm-menubar restricted to tty?

It isn't.  It's only the F10 binding that works differently on TTY
frames, for reasons of backward compatibility (before TTY menus were
available).  On GUI frames, you need to invoke tmm-menubar by name
instead.  (You can, of course, bind F10 to tmm-menubar globally, if
that's what you want.)

> It would be nicer, if the cond in menu-bar-open was replaced
> with run-hook-with-args-until-success and a customizable
> open-menu-bar-functions variable.

That's a lot of complexity for very little gain.  Binding F10 globally
is much easier.  And, given the fact that almost no one uses
tmm-menubar on GUI frames, I don't see the justification for the added
complexity.

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

[Tomas Hlavaty]

On Thu 25 Aug 2022 at 09:42, Eli Zaretskii <eliz@gnu.org> wrote:
>> This font size change happens on demand, when a key is pressed.
>
> Do you really need to do this frequently?  If so, why is that? why not
> set the size that is convenient for you, and more or less forget about
> it?

Frequency is not that relevant.  Convenience is relevant.  It should
happen after key press.  Not after changing configuration and restarting
Emacs.  I thought I explained that well enough already.  It is not
something I invented, it is important use-case and pretty much essential
part of GUI programs these days.  Try for example C-+ and C-- in firefox
or xfce4-terminal.

> I guess I don't understand why one would need to change the size
> frequently, especially the size of the menu items, which basically
> stay unchanged.

We already discussed several issues with the X resources based text:

- The font configuration is alien to emacs with many issues and downsides.
- It is not possible to change it dynamically.

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

[Eli Zaretskii]

> From: Tomas Hlavaty <tom@logand.com>
> Cc: luangruo@yahoo.com, 57372@debbugs.gnu.org
> Date: Thu, 25 Aug 2022 20:21:43 +0200
> 
> On Thu 25 Aug 2022 at 09:42, Eli Zaretskii <eliz@gnu.org> wrote:
> >> This font size change happens on demand, when a key is pressed.
> >
> > Do you really need to do this frequently?  If so, why is that? why not
> > set the size that is convenient for you, and more or less forget about
> > it?
> 
> Frequency is not that relevant.  Convenience is relevant.  It should
> happen after key press.

This is an exaggeration, and as such, not useful.  It is unreasonable
to expect everything be done at a keypress.  Infrequent operations can
be less convenient than frequent ones, because that inconvenience
basically happens once in a blue moon.

> It is not something I invented, it is important use-case and pretty
> much essential part of GUI programs these days.  Try for example C-+
> and C-- in firefox or xfce4-terminal.

When I do that in Firefox, the displayed text is resized, but not the
menus or the tool bar.

> > I guess I don't understand why one would need to change the size
> > frequently, especially the size of the menu items, which basically
> > stay unchanged.
> 
> We already discussed several issues with the X resources based text:
> 
> - The font configuration is alien to emacs with many issues and downsides.
> - It is not possible to change it dynamically.

That's nowhere near a catastrophe for such an infrequent setting.

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

[Tomas Hlavaty]

On Thu 25 Aug 2022 at 09:51, Eli Zaretskii <eliz@gnu.org> wrote:
> If you need to use the File menu, you shouldn't be bothered about the
> Edit menu.

If I want to use the Edit menu, it disappears half way through getting
to it.

> If you have a mouse that works on the TTY frames (either GPM or
> xterm-mouse mode), you can click directly at Edit and open the Edit
> menu instead of (the default) File menu.  Otherwise, use the arrow
> keys or C-f/C-b to move between the top-level menus.

The problem is not with mouse or keyboard.  The problem is with how the
selected menu-bar item is presented.

Anyway, it seems to me that all the existing menu implementations are
dead end for what I want to achieve, except tmm-menubar.

>> Is there a reason, why is tmm-menubar restricted to tty?
>
> It isn't.  It's only the F10 binding that works differently on TTY
> frames, for reasons of backward compatibility (before TTY menus were
> available).  On GUI frames, you need to invoke tmm-menubar by name
> instead.  (You can, of course, bind F10 to tmm-menubar globally, if
> that's what you want.)

I tried binding tmm-menubar to F10 but that does not work:

$ emacs -q \
--eval "(global-set-key [F10] 'tmm-menubar)" \
--eval '(describe-key [F10])'

This shows that tmm-menubar is bound to <F10> and M-`.
Pressing M-` opens tmm-menubar which is correct.
But pressing F10 pops up the X resources based menu which is wrong.
It seems that something in Emacs does not respect my F10 key binding.

>> It would be nicer, if the cond in menu-bar-open was replaced
>> with run-hook-with-args-until-success and a customizable
>> open-menu-bar-functions variable.
>
> That's a lot of complexity for very little gain.  Binding F10 globally
> is much easier.

Agree that it would be much easier, if it worked.

> And, given the fact that almost no one uses tmm-menubar on GUI frames,
> I don't see the justification for the added complexity.

It seems to me that tmm-menubar is the only menu implementation which
respects faces and does not depend on anything alien which means I can
customize it the usual Emacs way and change it dynamically.  That is a
huge plus and looks like the way to go for what I want to achieve.
Thanks again for the pointer.

It looks quite nice with this customisation:
(setq tmm-mid-prompt " ")
(setq tmm-completion-prompt nil)

However, if I click on the menu-bar I still get the X resource based
menu instead of tmm-menubar.  What do I need to do to get tmm-menubar
after clicking on the menubar (not only after pressing F10 or M-`)?

I tried to discover, what gets called in such case.  Unfortunatelly, C-h
k (describe-key) does not work in that case.  How can one discover, what
code handles particular click?

Unlike other implementations, it seems that tmm-menubar does not show
checkboxes.

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

[Eli Zaretskii]

> From: Tomas Hlavaty <tom@logand.com>
> Cc: luangruo@yahoo.com, 57372@debbugs.gnu.org
> Date: Thu, 25 Aug 2022 21:07:25 +0200
> 
> I tried binding tmm-menubar to F10 but that does not work:
> 
> $ emacs -q \
> --eval "(global-set-key [F10] 'tmm-menubar)" \
> --eval '(describe-key [F10])'
> 
> This shows that tmm-menubar is bound to <F10> and M-`.
> Pressing M-` opens tmm-menubar which is correct.
> But pressing F10 pops up the X resources based menu which is wrong.
> It seems that something in Emacs does not respect my F10 key binding.

It's [f10], lower-case.

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

[Tomas Hlavaty]

On Thu 25 Aug 2022 at 09:09, Po Lu <luangruo@yahoo.com> wrote:
> Tomas Hlavaty <tom@logand.com> writes:
>
>> Maybe this could be a good opportunity to get rid of that library?
>
> What would the replacement be?

I am looking for something which:
- is customizable the Emacs way
- is possible to change dynamically

It looks like tmm-menubar is the only existing menu implementation which
satisfies my requirements and is probably the only reasonable way
forward.

I think I need to first find a way to configure my emacs so that all
those X resource based menus are replaced with tmm-menubar.

After that, that library will not affect me anymore and can stay there
in case somebody happens to like it.

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Tomas Hlavaty <tom@logand.com> writes:

> I am looking for something which:
> - is customizable the Emacs way

I guess a good recommendation would be to lower your expectations, since
no toolkit provides face customization in as detailed a fashion as
Emacs.

> It looks like tmm-menubar is the only existing menu implementation which
> satisfies my requirements and is probably the only reasonable way
> forward.

tmm-menubar doesn't even pop up menus.  How can it be the only
reasonable way forward?

> I think I need to first find a way to configure my emacs so that all
> those X resource based menus are replaced with tmm-menubar.

X resource based menus?

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Tomas Hlavaty <tom@logand.com> writes:

> Frequency is not that relevant.  Convenience is relevant.  It should
> happen after key press.  Not after changing configuration and restarting
> Emacs.  I thought I explained that well enough already.  It is not
> something I invented, it is important use-case and pretty much essential
> part of GUI programs these days.  Try for example C-+ and C-- in firefox
> or xfce4-terminal.

Neither of which result in the menu font being resided, not in
xfce4-terminal or in Firefox.

> - The font configuration is alien to emacs with many issues and downsides.

There is no toolkit that uses the same font configuration we do, since
we wrote our own font display code.

> - It is not possible to change it dynamically.

It is on the Lucid and Motif builds.

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

[Tomas Hlavaty]

On Fri 26 Aug 2022 at 09:11, Po Lu <luangruo@yahoo.com> wrote:
> Tomas Hlavaty <tom@logand.com> writes:
>
>> I am looking for something which:
>> - is customizable the Emacs way
>
> I guess a good recommendation would be to lower your expectations, since
> no toolkit provides face customization in as detailed a fashion as
> Emacs.

Yes, I am doing exactly that: lowering my expectations.  The first word
of this bug report is no-toolkit after all.

>> It looks like tmm-menubar is the only existing menu implementation which
>> satisfies my requirements and is probably the only reasonable way
>> forward.
>
> tmm-menubar doesn't even pop up menus.  How can it be the only
> reasonable way forward?

It does not pop up menus in the alien widget toolkit sense.

It does pop up menus in the emacs sense, i.e. the *Completions* buffer
pops up.  (After lowering my expectations, this is good enough.)

Maybe there is a more precise terminology to distinguish the two cases?

>> I think I need to first find a way to configure my emacs so that all
>> those X resource based menus are replaced with tmm-menubar.
>
> X resource based menus?

I think you called it XMenu.

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

[Tomas Hlavaty]

On Thu 25 Aug 2022 at 22:02, Eli Zaretskii <eliz@gnu.org> wrote:
>> Frequency is not that relevant.  Convenience is relevant.  It should
>> happen after key press.
>
> This is an exaggeration, and as such, not useful.  It is unreasonable
> to expect everything be done at a keypress.  Infrequent operations can
> be less convenient than frequent ones, because that inconvenience
> basically happens once in a blue moon.

It happens as frequently or as rarely as the user chooses to press the
relevant key.  In other words, it is under control of the user, not
somebody else.

>> It is not something I invented, it is important use-case and pretty
>> much essential part of GUI programs these days.  Try for example C-+
>> and C-- in firefox or xfce4-terminal.
>
> When I do that in Firefox, the displayed text is resized, but not the
> menus or the tool bar.

True.

I gave the example because it seed to me you did not understand why
would somebody want to press C-+ or C-- to resize font instead of
changing a configuration and restarting.

Now I see that you mean specifically the Firefox menu.
Well, the Firefox menu uses a widget toolkit.

no-toolkit Emacs is not supposed to use a widget toolkit as far as I
understand it.  I was hoping that there would not be an alien library
with all the negatives of alien widget toolkit, or in this case even
worse (XMenu does not respect my desktop font settings, font
configuration is inconvenient, it looks bad and is unreadable by
default).

>> > I guess I don't understand why one would need to change the size
>> > frequently, especially the size of the menu items, which basically
>> > stay unchanged.
>> 
>> We already discussed several issues with the X resources based text:
>> 
>> - The font configuration is alien to emacs with many issues and downsides.
>> - It is not possible to change it dynamically.
>
> That's nowhere near a catastrophe for such an infrequent setting.

Dismissing the use-case is one way to solve this.

What I would like to have is kind of similar behaviour as tty emacs on
xfce4-terminal except with additional benefits of graphics capabilities
built into the GUI Emacs.  I like the way Emacs buffers work and that
they have dynamically customizable faces.  I do not like alien widget
toolkits getting in the way.

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

[Tomas Hlavaty]

On Thu 25 Aug 2022 at 22:15, Eli Zaretskii <eliz@gnu.org> wrote:
> It's [f10], lower-case.

That works, thank you!

Is there a way to show tmm-menubar also after clicking on the menubar?
I still get the alien XMenu.

Is there a way to discover what function handles a click in a similar
way there is describe-key?  (describe-key seems to work with clicks
except on the menubar.)

Is it an intention or a bug that tmm-menubar does not show checkboxes,
unlike other menu implementations?

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Tomas Hlavaty <tom@logand.com> writes:

> no-toolkit Emacs is not supposed to use a widget toolkit as far as I
> understand it.  I was hoping that there would not be an alien library
> with all the negatives of alien widget toolkit, or in this case even
> worse (XMenu does not respect my desktop font settings, font
> configuration is inconvenient, it looks bad and is unreadable by
> default).

"No toolkit" simply means Emacs doesn't use the X toolkit or GTK.

("X toolkit" has a very strict definition: any toolkit based upon the X
toolkit intrinsics.)

Since the oldXMenu library is not based on the toolkit intrinsics, it's
not an X toolkit.

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

[Eli Zaretskii]

> From: Tomas Hlavaty <tom@logand.com>
> Cc: luangruo@yahoo.com, 57372@debbugs.gnu.org
> Date: Fri, 26 Aug 2022 09:19:40 +0200
> 
> Is there a way to show tmm-menubar also after clicking on the menubar?
> I still get the alien XMenu.

You could try binding [menu-bar mouse-1], but I'm not sure it will
work in every build configuration.

> Is there a way to discover what function handles a click in a similar
> way there is describe-key?  (describe-key seems to work with clicks
> except on the menubar.)

If the clicks are intercepted before they get to Emacs, you cannot use
describe-key with them.

> Is it an intention or a bug that tmm-menubar does not show checkboxes,
> unlike other menu implementations?

That's how tmm-menubar was written.  I don't know what were the
intentions.

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> If the clicks are intercepted before they get to Emacs, you cannot use
> describe-key with them.

It should work on the no toolkit build.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Tomas Hlavaty <tom@logand.com>,  57372@debbugs.gnu.org
> Date: Fri, 26 Aug 2022 18:54:46 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If the clicks are intercepted before they get to Emacs, you cannot use
> > describe-key with them.
> 
> It should work on the no toolkit build.

That depends on the implementation: if the no-toolkit menu
implementation intercepts the clicks before they get to Emacs, "C-h c"
will not work for the individual clicks, only for a complete selection
from the menu.

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> That depends on the implementation: if the no-toolkit menu
> implementation intercepts the clicks before they get to Emacs, "C-h c"
> will not work for the individual clicks, only for a complete selection
> from the menu.

Clicks on the menu bar aren't intercepted at all.  Instead, some code in
keyboard.c (not exactly sure where) will call menu_show_hook (through
read_char_x_menu_prompt) with the contents of the submenu that was
clicked if nothing was bound, AFAIR.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: tom@logand.com,  57372@debbugs.gnu.org
> Date: Fri, 26 Aug 2022 19:18:36 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > That depends on the implementation: if the no-toolkit menu
> > implementation intercepts the clicks before they get to Emacs, "C-h c"
> > will not work for the individual clicks, only for a complete selection
> > from the menu.
> 
> Clicks on the menu bar aren't intercepted at all.  Instead, some code in
> keyboard.c (not exactly sure where) will call menu_show_hook (through
> read_char_x_menu_prompt) with the contents of the submenu that was
> clicked if nothing was bound, AFAIR.

That's what I call "intercepted".

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

[Tomas Hlavaty]

On Thu 25 Aug 2022 at 22:02, Eli Zaretskii <eliz@gnu.org> wrote:
>> It is not something I invented, it is important use-case and pretty
>> much essential part of GUI programs these days.  Try for example C-+
>> and C-- in firefox or xfce4-terminal.
>
> When I do that in Firefox, the displayed text is resized, but not the
> menus or the tool bar.

Interestingly, the Web Developer Tools menu does change the font size,
e.g. press F12 and C-+ and the font size of the Web Developer Tools menu
changes too.

Only the widget toolkit based menu does not change the font size.

I never understood why web browsers depend on widget toolkits
when they already implement everything needed
and do not adhere to "native" look-and-feel anyway.
Widget toolkits impose such inflexible restrictions
and import annoying problems.

Like somebody recently complained about 2sec delay when opening Emacs menu.
tmm-menubar does not solve it fully, because in gui emacs,
menu invocations by mouse are hardcoded to use toolkit based menu.

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Tomas Hlavaty <tom@logand.com> writes:

> I never understood why web browsers depend on widget toolkits
> when they already implement everything needed
> and do not adhere to "native" look-and-feel anyway.
> Widget toolkits impose such inflexible restrictions
> and import annoying problems.

Firefox uses its own code to display right-click menus.  It just tries
to style it like GTK.

> Like somebody recently complained about 2sec delay when opening Emacs menu.
> tmm-menubar does not solve it fully, because in gui emacs,
> menu invocations by mouse are hardcoded to use toolkit based menu.

A 2 second delay is too long, unless GC runs during menu bar
initialization.