unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu
@ 2022-02-10 10:43 Stephen Berman
  2022-02-10 12:12 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 17+ messages in thread
From: Stephen Berman @ 2022-02-10 10:43 UTC (permalink / raw)
  To: 53916

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





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu
  2022-02-10 10:43 bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu Stephen Berman
@ 2022-02-10 12:12 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-02-10 12:52   ` Lars Ingebrigtsen
  2022-02-10 13:30   ` Robert Pluim
  0 siblings, 2 replies; 17+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-02-10 12:12 UTC (permalink / raw)
  To: Stephen Berman; +Cc: 53916

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





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu
  2022-02-10 12:12 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-02-10 12:52   ` Lars Ingebrigtsen
  2022-02-10 13:03     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-02-10 13:30   ` Robert Pluim
  1 sibling, 1 reply; 17+ messages in thread
From: Lars Ingebrigtsen @ 2022-02-10 12:52 UTC (permalink / raw)
  To: Stephen Berman; +Cc: Po Lu, 53916

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





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu
  2022-02-10 12:52   ` Lars Ingebrigtsen
@ 2022-02-10 13:03     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-02-11  6:20       ` Lars Ingebrigtsen
  0 siblings, 1 reply; 17+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-02-10 13:03 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Stephen Berman, 53916

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.





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu
  2022-02-10 12:12 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-02-10 12:52   ` Lars Ingebrigtsen
@ 2022-02-10 13:30   ` Robert Pluim
  2022-02-10 13:31     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  1 sibling, 1 reply; 17+ messages in thread
From: Robert Pluim @ 2022-02-10 13:30 UTC (permalink / raw)
  To: Stephen Berman; +Cc: Po Lu, 53916

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





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu
  2022-02-10 13:30   ` Robert Pluim
@ 2022-02-10 13:31     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-02-10 17:40       ` Eli Zaretskii
  0 siblings, 1 reply; 17+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-02-10 13:31 UTC (permalink / raw)
  To: Robert Pluim; +Cc: Stephen Berman, 53916

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.





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu
  2022-02-10 13:31     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-02-10 17:40       ` Eli Zaretskii
  2022-02-11  0:59         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 17+ messages in thread
From: Eli Zaretskii @ 2022-02-10 17:40 UTC (permalink / raw)
  To: Po Lu; +Cc: rpluim, stephen.berman, 53916

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





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu
  2022-02-10 17:40       ` Eli Zaretskii
@ 2022-02-11  0:59         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-02-11  7:18           ` Eli Zaretskii
  0 siblings, 1 reply; 17+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-02-11  0:59 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: rpluim, stephen.berman, 53916

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"?





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu
  2022-02-10 13:03     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-02-11  6:20       ` Lars Ingebrigtsen
  2022-02-11  6:24         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 17+ messages in thread
From: Lars Ingebrigtsen @ 2022-02-11  6:20 UTC (permalink / raw)
  To: Po Lu; +Cc: Stephen Berman, 53916

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





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu
  2022-02-11  6:20       ` Lars Ingebrigtsen
@ 2022-02-11  6:24         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-02-11  6:26           ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 17+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-02-11  6:24 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Stephen Berman, 53916

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.





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu
  2022-02-11  6:24         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-02-11  6:26           ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-02-11  7:59             ` Eli Zaretskii
  0 siblings, 1 reply; 17+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-02-11  6:26 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Stephen Berman, 53916

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.





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu
  2022-02-11  0:59         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-02-11  7:18           ` Eli Zaretskii
  2022-02-11  7:25             ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 17+ messages in thread
From: Eli Zaretskii @ 2022-02-11  7:18 UTC (permalink / raw)
  To: Po Lu; +Cc: rpluim, stephen.berman, 53916

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





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu
  2022-02-11  7:18           ` Eli Zaretskii
@ 2022-02-11  7:25             ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-02-11  8:10               ` Eli Zaretskii
  0 siblings, 1 reply; 17+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-02-11  7:25 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: rpluim, stephen.berman, 53916

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.





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu
  2022-02-11  6:26           ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-02-11  7:59             ` Eli Zaretskii
  2022-02-11 11:11               ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 17+ messages in thread
From: Eli Zaretskii @ 2022-02-11  7:59 UTC (permalink / raw)
  To: Po Lu; +Cc: larsi, stephen.berman, 53916

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





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu
  2022-02-11  7:25             ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-02-11  8:10               ` Eli Zaretskii
  2022-02-11 11:12                 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 17+ messages in thread
From: Eli Zaretskii @ 2022-02-11  8:10 UTC (permalink / raw)
  To: Po Lu; +Cc: rpluim, stephen.berman, 53916

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





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu
  2022-02-11  7:59             ` Eli Zaretskii
@ 2022-02-11 11:11               ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 0 replies; 17+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-02-11 11:11 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, stephen.berman, 53916

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.





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu
  2022-02-11  8:10               ` Eli Zaretskii
@ 2022-02-11 11:12                 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 0 replies; 17+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-02-11 11:12 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: rpluim, stephen.berman, 53916

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.





^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2022-02-11 11:12 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-02-10 10:43 bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu Stephen Berman
2022-02-10 12:12 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-10 12:52   ` Lars Ingebrigtsen
2022-02-10 13:03     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-11  6:20       ` Lars Ingebrigtsen
2022-02-11  6:24         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-11  6:26           ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-11  7:59             ` Eli Zaretskii
2022-02-11 11:11               ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-10 13:30   ` Robert Pluim
2022-02-10 13:31     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-10 17:40       ` Eli Zaretskii
2022-02-11  0:59         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-11  7:18           ` Eli Zaretskii
2022-02-11  7:25             ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-11  8:10               ` Eli Zaretskii
2022-02-11 11:12                 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).