bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu

bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu

[Stephen Berman]

0. emacs -Q
1. Disable with menu bar with `M-x menu-bar-mode'
2. Press the F10 key to invoke `menu-bar-open'
=> In the shell the following warning is emitted:

(emacs-pgtk:6569): Gtk-WARNING **: 11:39:05.713: no trigger event for menu popup


In GNU Emacs 29.0.50 (build 11, x86_64-pc-linux-gnu, GTK+ Version 3.24.31, cairo version 1.17.4)
 of 2022-02-10 built on strobelfs2
Repository revision: d3c47011d5ace1e1c3fca830d3ff71d9c693ed5d
Repository branch: master
System Description: Linux From Scratch r11.0-115

Configured using:
 'configure --with-pgtk --with-xwidgets 'CFLAGS=-Og -g3'
 PKG_CONFIG_PATH=/opt/qt5/lib/pkgconfig'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PGTK PNG
RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP XIM
XWIDGETS GTK3 ZLIB

bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu

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

Stephen Berman <stephen.berman@gmx.net> writes:

> 0. emacs -Q
> 1. Disable with menu bar with `M-x menu-bar-mode'
> 2. Press the F10 key to invoke `menu-bar-open'
> => In the shell the following warning is emitted:
>
> (emacs-pgtk:6569): Gtk-WARNING **: 11:39:05.713: no trigger event for menu popup

That warning is harmless, though we could make it go away by installing
a log handler.  Someone else should chime in at this point to decide
whether or not that's worth it, since such a filter might end up
obscuring legitimate problems in the future.

Alternatively, we could do the same dance with "saved menu events" as on
X.  That would make the warning go away, but is very much not
recommended for a well-behaved GTK program (which the PGTK port already
isn't, but I don't see a reason to make that problem even worse.)

bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu

[Lars Ingebrigtsen]

Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:

> That warning is harmless, though we could make it go away by installing
> a log handler.  Someone else should chime in at this point to decide
> whether or not that's worth it, since such a filter might end up
> obscuring legitimate problems in the future.

My impression is that most of these warnings from GTK are harmless, so
perhaps having a log handler (and defaulting it to "off") would be good.
(But there should be a user option to switch them on.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu

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

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
> editors" <bug-gnu-emacs@gnu.org> writes:
>
>> That warning is harmless, though we could make it go away by installing
>> a log handler.  Someone else should chime in at this point to decide
>> whether or not that's worth it, since such a filter might end up
>> obscuring legitimate problems in the future.
>
> My impression is that most of these warnings from GTK are harmless, so
> perhaps having a log handler (and defaulting it to "off") would be good.
> (But there should be a user option to switch them on.)

I'm okay with doing that for this particular warning, and the
appropriate option already exists (the G_DEBUG environment variable can
be set to `fatal-warnings', which will cause GLib to abort upon
encoutering such a warning, even if we filter it out.)

But I don't know whether or not it's okay to treat all warnings that
way.  For example, bug#53900 is a serious bug that got caught by someone
noticing a warning emitted by GTK, and presumably wouldn't have been
reported if the warning had been filtered out.

Thanks.

bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu

[Robert Pluim]

>>>>> On Thu, 10 Feb 2022 20:12:58 +0800, Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org> said:

    Po> Stephen Berman <stephen.berman@gmx.net> writes:
    >> 0. emacs -Q
    >> 1. Disable with menu bar with `M-x menu-bar-mode'
    >> 2. Press the F10 key to invoke `menu-bar-open'
    >> => In the shell the following warning is emitted:
    >> 
    >> (emacs-pgtk:6569): Gtk-WARNING **: 11:39:05.713: no trigger event for menu popup

    Po> That warning is harmless, though we could make it go away by installing
    Po> a log handler.  Someone else should chime in at this point to decide
    Po> whether or not that's worth it, since such a filter might end up
    Po> obscuring legitimate problems in the future.

Can such a log handler put those warnings in *Messages*?

Robert
-- 

bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu

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

Robert Pluim <rpluim@gmail.com> writes:

>     Po> That warning is harmless, though we could make it go away by installing
>     Po> a log handler.  Someone else should chime in at this point to decide
>     Po> whether or not that's worth it, since such a filter might end up
>     Po> obscuring legitimate problems in the future.
>
> Can such a log handler put those warnings in *Messages*?

Yes.

bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu

[Eli Zaretskii]

> Resent-From: Po Lu <luangruo@yahoo.com>
> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>
> Resent-CC: bug-gnu-emacs@gnu.org
> Resent-Sender: help-debbugs@gnu.org
> Cc: Stephen Berman <stephen.berman@gmx.net>, 53916@debbugs.gnu.org
> Date: Thu, 10 Feb 2022 21:31:17 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Robert Pluim <rpluim@gmail.com> writes:
> 
> >     Po> That warning is harmless, though we could make it go away by installing
> >     Po> a log handler.  Someone else should chime in at this point to decide
> >     Po> whether or not that's worth it, since such a filter might end up
> >     Po> obscuring legitimate problems in the future.
> >
> > Can such a log handler put those warnings in *Messages*?
> 
> Yes.

I wouldn't recommend mixing GTK diagnostics with *Messages*.  Why not
have a separate buffer for the GTK messages?

bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu

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

Eli Zaretskii <eliz@gnu.org> writes:

>> Resent-From: Po Lu <luangruo@yahoo.com>
>> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>
>> Resent-CC: bug-gnu-emacs@gnu.org
>> Resent-Sender: help-debbugs@gnu.org
>> Cc: Stephen Berman <stephen.berman@gmx.net>, 53916@debbugs.gnu.org
>> Date: Thu, 10 Feb 2022 21:31:17 +0800
>> From:  Po Lu via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> 
>> Robert Pluim <rpluim@gmail.com> writes:
>> 
>> >     Po> That warning is harmless, though we could make it go away by installing
>> >     Po> a log handler.  Someone else should chime in at this point to decide
>> >     Po> whether or not that's worth it, since such a filter might end up
>> >     Po> obscuring legitimate problems in the future.
>> >
>> > Can such a log handler put those warnings in *Messages*?
>> 
>> Yes.
>
> I wouldn't recommend mixing GTK diagnostics with *Messages*.  Why not
> have a separate buffer for the GTK messages?

I think it would be confusing to have such a buffer suddenly appear.
How about prefixing the messages with "GTK diagnostic"?

bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> But I don't know whether or not it's okay to treat all warnings that
> way.  For example, bug#53900 is a serious bug that got caught by someone
> noticing a warning emitted by GTK, and presumably wouldn't have been
> reported if the warning had been filtered out.

That's true.  Perhaps redirecting the messages to *Messages* instead of
stderr (and do no filtering per default?) is a better solution indeed.
(I think the having the warnings in the terminal looks a bit
unprofessional and untidy, so keeping them inside Emacs would help.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu

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

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> But I don't know whether or not it's okay to treat all warnings that
>> way.  For example, bug#53900 is a serious bug that got caught by someone
>> noticing a warning emitted by GTK, and presumably wouldn't have been
>> reported if the warning had been filtered out.
>
> That's true.  Perhaps redirecting the messages to *Messages* instead of
> stderr (and do no filtering per default?) is a better solution indeed.
> (I think the having the warnings in the terminal looks a bit
> unprofessional and untidy, so keeping them inside Emacs would help.)

Great, does anyone know what "%s" parameters to `add_to_log' are
expected in?  UTF-8?

Thanks in advance.

bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu

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

Po Lu <luangruo@yahoo.com> writes:

> Great, does anyone know what "%s" parameters to `add_to_log' are
> expected in?  UTF-8?

About 5 seconds after sending this, I realized that it accepts Lisp
objects and format control strings like `format'.

So hopefully that means it will be okay to print out unibyte strings via
that mechanism, since I don't want to go down the rabbit hole of what
text encodings various libraries using the GLib logging system subject
it to.

Thanks.

bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: rpluim@gmail.com,  stephen.berman@gmx.net,  53916@debbugs.gnu.org
> Date: Fri, 11 Feb 2022 08:59:08 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> > Can such a log handler put those warnings in *Messages*?
> >> 
> >> Yes.
> >
> > I wouldn't recommend mixing GTK diagnostics with *Messages*.  Why not
> > have a separate buffer for the GTK messages?
> 
> I think it would be confusing to have such a buffer suddenly appear.

Why confusing?  We already have in Emacs 28 and later a buffer named
*Async-native-compile-log* that "suddenly appears" as soon as Emacs
needs for the first time to natively-compile a Lisp file.  How is this
case different?

bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu

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

Eli Zaretskii <eliz@gnu.org> writes:

> Why confusing?  We already have in Emacs 28 and later a buffer named
> *Async-native-compile-log* that "suddenly appears" as soon as Emacs
> needs for the first time to natively-compile a Lisp file.  How is this
> case different?

That one is a log of things Emacs is doing, while this one usually
appears without context, and could contain scary error messages from
various different libraries.

bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu

[Eli Zaretskii]

> Cc: Stephen Berman <stephen.berman@gmx.net>, 53916@debbugs.gnu.org
> Date: Fri, 11 Feb 2022 14:26:21 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Po Lu <luangruo@yahoo.com> writes:
> 
> > Great, does anyone know what "%s" parameters to `add_to_log' are
> > expected in?  UTF-8?
> 
> About 5 seconds after sending this, I realized that it accepts Lisp
> objects and format control strings like `format'.

Yes, the arguments are Lisp strings.

> So hopefully that means it will be okay to print out unibyte strings via
> that mechanism, since I don't want to go down the rabbit hole of what
> text encodings various libraries using the GLib logging system subject
> it to.

Just use DECODE_SYSTEM, the encoding is already figured out for you.

Please do NOT use the original unibyte strings, they are likely to
display as gibberish in some cases.

bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: rpluim@gmail.com,  stephen.berman@gmx.net,  53916@debbugs.gnu.org
> Date: Fri, 11 Feb 2022 15:25:49 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Why confusing?  We already have in Emacs 28 and later a buffer named
> > *Async-native-compile-log* that "suddenly appears" as soon as Emacs
> > needs for the first time to natively-compile a Lisp file.  How is this
> > case different?
> 
> That one is a log of things Emacs is doing, while this one usually
> appears without context, and could contain scary error messages from
> various different libraries.

I don't see the crucial difference.

From my POV, having GTK messages in *Messages* will make debugging
Emacs's own problems harder.  Some redisplay problems are only
visible in *Messages* (because we cannot signal an error), and having
the buffer filled up by irrelevant GTK stuff will make reading the
messages harder, and could even make the important messages disappear,
if the GTK stuff overflows message-log-max.

So I really prefer a separate buffer.

bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu

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

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: Stephen Berman <stephen.berman@gmx.net>, 53916@debbugs.gnu.org
>> Date: Fri, 11 Feb 2022 14:26:21 +0800
>> From:  Po Lu via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> 
>> Po Lu <luangruo@yahoo.com> writes:
>> 
>> > Great, does anyone know what "%s" parameters to `add_to_log' are
>> > expected in?  UTF-8?
>> 
>> About 5 seconds after sending this, I realized that it accepts Lisp
>> objects and format control strings like `format'.
>
> Yes, the arguments are Lisp strings.
>
>> So hopefully that means it will be okay to print out unibyte strings via
>> that mechanism, since I don't want to go down the rabbit hole of what
>> text encodings various libraries using the GLib logging system subject
>> it to.
>
> Just use DECODE_SYSTEM, the encoding is already figured out for you.
>
> Please do NOT use the original unibyte strings, they are likely to
> display as gibberish in some cases.

Thanks.

bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu

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

Eli Zaretskii <eliz@gnu.org> writes:

> I don't see the crucial difference.
>
> From my POV, having GTK messages in *Messages* will make debugging
> Emacs's own problems harder.  Some redisplay problems are only
> visible in *Messages* (because we cannot signal an error), and having
> the buffer filled up by irrelevant GTK stuff will make reading the
> messages harder, and could even make the important messages disappear,
> if the GTK stuff overflows message-log-max.
>
> So I really prefer a separate buffer.

Okay, reasonable enough, thanks.