bug#44794: 28.0.50; Frame creation broken with (tool-bar-mode -1)

bug#44794: 28.0.50; Frame creation broken with (tool-bar-mode -1)

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

With a .emacs file containing only the line:

(tool-bar-mode -1)

Then ./emacs in the repo src directory.

On my system, the initial frame is blank except for a title bar, menu
bar and a scroll bar -- no mini-buffer and nothing at all in the main
window. If you resize the frame with the mouse or by keyboard shortcut
then the usual splash screen appears, along with the mini-buffer. The
symptoms differ somewhat if you add font specifications and/or frame
size specifications to the .emacs file, but it still doesn't work
right.

I bisected it to commit 36431e1679, which modifies xterm.c. Reverting
that commit and rebuilding brings back the previous behavior, and all
looks correct to me.

Many thanks,

David.

In GNU Emacs 28.0.50 (build 13, i686-pc-linux-gnu, GTK+ Version
3.18.9, cairo version 1.14.6)
 of 2020-11-22 built on newfont
Repository revision: 9490f12c4dc4deb16f4e900646319f6de033982c
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.11803000
System Description: Slackware 14.2

Configured using:
 'configure
 PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/local/share/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig'

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL GNUTLS LIBXML2 FREETYPE HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS
GTK3 X11 XDBE XIM MODULES THREADS PDUMPER LCMS2

Important settings:
  value of $LC_COLLATE: C
  value of $LANG: en_US.ISO8859-1
  locale-coding-system: iso-latin-1-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs text-property-search time-date mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils tex-site info
package easymenu browse-url url url-proxy url-privacy url-expand
url-methods url-history url-cookie url-domsuf url-util mailcap
url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json subr-x map url-vars seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 8 68901 8187)
 (symbols 24 8241 1)
 (strings 16 24876 1710)
 (string-bytes 1 834263)
 (vectors 8 14295)
 (vector-slots 4 196017 11392)
 (floats 8 26 24)
 (intervals 28 245 0)
 (buffers 560 11)
 (heap 1024 9566 759))

bug#44794: 28.0.50; Frame creation broken with (tool-bar-mode -1)

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

Just to add as part of the recipe that creating a new frame with C-x 5
b or C-x 5 f produces new blank frames -- resizing them makes their
contents visible.

David.

bug#44794: 28.0.50; Frame creation broken with (tool-bar-mode -1)

[Stefan Kangas]

[-- Attachment #1: Type: text/plain, Size: 1309 bytes --]

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

> With a .emacs file containing only the line:
>
> (tool-bar-mode -1)
>
> Then ./emacs in the repo src directory.
>
> On my system, the initial frame is blank except for a title bar, menu
> bar and a scroll bar -- no mini-buffer and nothing at all in the main
> window. If you resize the frame with the mouse or by keyboard shortcut
> then the usual splash screen appears, along with the mini-buffer. The
> symptoms differ somewhat if you add font specifications and/or frame
> size specifications to the .emacs file, but it still doesn't work
> right.
>
> I bisected it to commit 36431e1679, which modifies xterm.c. Reverting
> that commit and rebuilding brings back the previous behavior, and all
> looks correct to me.

Thank you for bisecting and the clear recipe.  This points at a recent
and fairly trivial patch by me, but I unfortunately can't reproduce the
issue here.

There is something subtle going on here that I don't understand.  Does
anyone else have an idea?

This might be a long-shot, but could you please try the attached patch
to see if it works better?  It's the best I could come up with; if it
doesn't work, I think someone else will have to help figure this one
out.

[-- Attachment #2: bug-44794-sk.patch --]
[-- Type: text/x-diff, Size: 1257 bytes --]

diff --git a/src/xterm.c b/src/xterm.c
index 0d2452de92..05353a2ec2 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -12927,24 +12927,19 @@ #define NUM_ARGV 10
   XSetAfterFunction (x_current_display, x_trace_wire);
 #endif
 
-  Lisp_Object system_name = Fsystem_name ();
   static char const title[] = "GNU Emacs";
+  static char const at[] = " at ";
+  Lisp_Object system_name = Fsystem_name ();
+  ptrdiff_t nbytes = sizeof (title) + sizeof (at);
+  if (STRINGP (system_name)
+      && INT_ADD_WRAPV (nbytes, SBYTES (system_name) + 1, &nbytes))
+    memory_full (SIZE_MAX);
+  dpyinfo->x_id = ++x_display_id;
+  dpyinfo->x_id_name = xmalloc (nbytes);
   if (STRINGP (system_name))
-    {
-      static char const at[] = " at ";
-      ptrdiff_t nbytes = sizeof (title) + sizeof (at);
-      if (INT_ADD_WRAPV (nbytes, SBYTES (system_name), &nbytes))
-	memory_full (SIZE_MAX);
-      dpyinfo->x_id_name = xmalloc (nbytes);
       sprintf (dpyinfo->x_id_name, "%s%s%s", title, at, SDATA (system_name));
-    }
   else
-    {
-      dpyinfo->x_id_name = xmalloc (sizeof (title));
       strcpy (dpyinfo->x_id_name, title);
-    }
-
-  dpyinfo->x_id = ++x_display_id;
 
   /* Figure out which modifier bits mean what.  */
   x_find_modifier_meanings (dpyinfo);

bug#44794: 28.0.50; Frame creation broken with (tool-bar-mode -1)

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Sun, 22 Nov 2020 07:20:09 -0800
> 
> > I bisected it to commit 36431e1679, which modifies xterm.c. Reverting
> > that commit and rebuilding brings back the previous behavior, and all
> > looks correct to me.
> 
> Thank you for bisecting and the clear recipe.  This points at a recent
> and fairly trivial patch by me, but I unfortunately can't reproduce the
> issue here.
> 
> There is something subtle going on here that I don't understand.  Does
> anyone else have an idea?

I suspect the WM might have something to do with this.

bug#44794: 28.0.50; Frame creation broken with (tool-bar-mode -1)

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

Thanks for the patch, Stefan, but I'm sorry to report that it didn't
make any difference. Since the commit is a week old, and lots of users
turn off the tool bar, and no one else has reported an issue, I guess
Eli's probably right. My WM is kwin (4.11.22), if that's any help.

Strange that the issue just turned up after that commit, though. My
.emacs hasn't changed in quite a while. Is there anything I can do to
help debug this? With some guidance from you both I can run emacs
under gdb if that might produce useful information.

David.

On Sun, 22 Nov 2020 at 15:50, Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Stefan Kangas <stefan@marxist.se>
> > Date: Sun, 22 Nov 2020 07:20:09 -0800
> >
> > > I bisected it to commit 36431e1679, which modifies xterm.c. Reverting
> > > that commit and rebuilding brings back the previous behavior, and all
> > > looks correct to me.
> >
> > Thank you for bisecting and the clear recipe.  This points at a recent
> > and fairly trivial patch by me, but I unfortunately can't reproduce the
> > issue here.
> >
> > There is something subtle going on here that I don't understand.  Does
> > anyone else have an idea?
>
> I suspect the WM might have something to do with this.

bug#44794: 28.0.50; Frame creation broken with (tool-bar-mode -1)

[Eli Zaretskii]

> From: David Fussner <dfussner@googlemail.com>
> Date: Sun, 22 Nov 2020 18:08:59 +0000
> Cc: Stefan Kangas <stefan@marxist.se>, 44794@debbugs.gnu.org
> 
> Strange that the issue just turned up after that commit, though. My
> .emacs hasn't changed in quite a while. Is there anything I can do to
> help debug this? With some guidance from you both I can run emacs
> under gdb if that might produce useful information.

I'd begin by establishing which of the two if/else branches of the
offending code your Emacs takes:

  Lisp_Object system_name = Fsystem_name ();
  static char const title[] = "GNU Emacs";
  if (STRINGP (system_name))
    {
      static char const at[] = " at ";
      ptrdiff_t nbytes = sizeof (title) + sizeof (at);
      if (INT_ADD_WRAPV (nbytes, SBYTES (system_name), &nbytes))
	memory_full (SIZE_MAX);
      dpyinfo->x_id_name = xmalloc (nbytes);
      sprintf (dpyinfo->x_id_name, "%s%s%s", title, at, SDATA (system_name));
    }
  else
    {
      dpyinfo->x_id_name = xmalloc (sizeof (title));
      strcpy (dpyinfo->x_id_name, title);
    }

bug#44794: 28.0.50; Frame creation broken with (tool-bar-mode -1)

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

Forgive my incompetence, but my idea for how to do that appears to be
faulty -- what would be the simplest way to detect which branch the
code takes?

On Sun, 22 Nov 2020 at 18:39, Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: David Fussner <dfussner@googlemail.com>
> > Date: Sun, 22 Nov 2020 18:08:59 +0000
> > Cc: Stefan Kangas <stefan@marxist.se>, 44794@debbugs.gnu.org
> >
> > Strange that the issue just turned up after that commit, though. My
> > .emacs hasn't changed in quite a while. Is there anything I can do to
> > help debug this? With some guidance from you both I can run emacs
> > under gdb if that might produce useful information.
>
> I'd begin by establishing which of the two if/else branches of the
> offending code your Emacs takes:
>
>   Lisp_Object system_name = Fsystem_name ();
>   static char const title[] = "GNU Emacs";
>   if (STRINGP (system_name))
>     {
>       static char const at[] = " at ";
>       ptrdiff_t nbytes = sizeof (title) + sizeof (at);
>       if (INT_ADD_WRAPV (nbytes, SBYTES (system_name), &nbytes))
>         memory_full (SIZE_MAX);
>       dpyinfo->x_id_name = xmalloc (nbytes);
>       sprintf (dpyinfo->x_id_name, "%s%s%s", title, at, SDATA (system_name));
>     }
>   else
>     {
>       dpyinfo->x_id_name = xmalloc (sizeof (title));
>       strcpy (dpyinfo->x_id_name, title);
>     }

bug#44794: 28.0.50; Frame creation broken with (tool-bar-mode -1)

[Stefan Kangas]

David Fussner <dfussner@googlemail.com> writes:

> Forgive my incompetence, but my idea for how to do that appears to be
> faulty -- what would be the simplest way to detect which branch the
> code takes?

Maybe one of these could work:

1. One way which doesn't involve any coding, but might require you to be
fast, is to type "emacs --no-desktop" to just use your normal init file.
If your init file takes sufficiently long to load, you can glean if the
default title says either "GNU Emacs at foo" or just "GNU Emacs" before
it has time to change.  (If it's too fast, maybe you could add a
(sleep-for 10) to the beginning of your init file.)

2. If that is impractical for some reason, you could just add a call to
exit() to each of them in turn and see when it doesn't start.

3. Or, less intrusively, I think you can just add to one branch:

    Fmessage ("one");

And to the other:

    Fmessage ("two");

Then check the "*Messages*" buffer for which one gave you any output.

bug#44794: 28.0.50; Frame creation broken with (tool-bar-mode -1)

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

Thanks for the tip -- it says "GNU Emacs at newfont" when it first
comes up, then prepends the buffer name to that later.

On Sun, 22 Nov 2020 at 19:16, Stefan Kangas <stefan@marxist.se> wrote:
>
> David Fussner <dfussner@googlemail.com> writes:
>
> > Forgive my incompetence, but my idea for how to do that appears to be
> > faulty -- what would be the simplest way to detect which branch the
> > code takes?
>
> Maybe one of these could work:
>
> 1. One way which doesn't involve any coding, but might require you to be
> fast, is to type "emacs --no-desktop" to just use your normal init file.
> If your init file takes sufficiently long to load, you can glean if the
> default title says either "GNU Emacs at foo" or just "GNU Emacs" before
> it has time to change.  (If it's too fast, maybe you could add a
> (sleep-for 10) to the beginning of your init file.)
>
> 2. If that is impractical for some reason, you could just add a call to
> exit() to each of them in turn and see when it doesn't start.
>
> 3. Or, less intrusively, I think you can just add to one branch:
>
>     Fmessage ("one");
>
> And to the other:
>
>     Fmessage ("two");
>
> Then check the "*Messages*" buffer for which one gave you any output.

bug#44794: 28.0.50; Frame creation broken with (tool-bar-mode -1)

[Eli Zaretskii]

> From: David Fussner <dfussner@googlemail.com>
> Date: Sun, 22 Nov 2020 19:23:16 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>, 44794@debbugs.gnu.org
> 
> Thanks for the tip -- it says "GNU Emacs at newfont" when it first
> comes up, then prepends the buffer name to that later.

What happens if you change this:

  Lisp_Object icon_title_name_format
    = pure_list (empty_unibyte_string,
		 build_pure_c_string ("%b - GNU Emacs at "),
		 intern_c_string ("system-name"));

to say this instead:

  Lisp_Object icon_title_name_format
    = pure_list (empty_unibyte_string,
		 build_pure_c_string ("GNU Emacs at "),
		 intern_c_string ("system-name"));

This code is in xdisp.c.  The change I propose removes the "%b - "
part from the argument to build_pure_c_string.

bug#44794: 28.0.50; Frame creation broken with (tool-bar-mode -1)

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

I'm sorry to report it didn't help (aside from modifying what appears
in the title bar).

On Sun, 22 Nov 2020 at 19:59, Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: David Fussner <dfussner@googlemail.com>
> > Date: Sun, 22 Nov 2020 19:23:16 +0000
> > Cc: Eli Zaretskii <eliz@gnu.org>, 44794@debbugs.gnu.org
> >
> > Thanks for the tip -- it says "GNU Emacs at newfont" when it first
> > comes up, then prepends the buffer name to that later.
>
> What happens if you change this:
>
>   Lisp_Object icon_title_name_format
>     = pure_list (empty_unibyte_string,
>                  build_pure_c_string ("%b - GNU Emacs at "),
>                  intern_c_string ("system-name"));
>
> to say this instead:
>
>   Lisp_Object icon_title_name_format
>     = pure_list (empty_unibyte_string,
>                  build_pure_c_string ("GNU Emacs at "),
>                  intern_c_string ("system-name"));
>
> This code is in xdisp.c.  The change I propose removes the "%b - "
> part from the argument to build_pure_c_string.

bug#44794: 28.0.50; Frame creation broken with (tool-bar-mode -1)

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

As no one else seems to be able to reproduce this bug, I thought I
would give a fuller list of the symptoms I've seen when using various
set-ups in my .emacs file, in case that might help.

If in addition to turning off the tool bar you add:

(add-to-list 'default-frame-alist
                '(height . 30)
                '(font . "Luxi Mono-16"))

Then the initial frame shows the splash page just fine, and all looks
well. After C-x 5 b return then the *scratch* buffer pops up with all
the problems described in the initial report: nothing visible in the
main window and no mini-buffer, either.

If you make the height too big for the screen, in my case with such a
big font I set it to 33, then the initial frame shows the splash page
just fine and is as tall as the screen allows. After C-x 5 b return
then the *scratch* buffer does appear, with text and mini-buffer
intact, only the second frame is about two-thirds the correct height.

After Eli's suggestion above about the WM I did try shutting down KDE
and running xfce4, with exactly the same results as with KDE, as far
as I could tell.

Thanks again to you both for all your help.

David.

On Sun, 22 Nov 2020 at 20:50, David Fussner <dfussner@googlemail.com> wrote:
>
> I'm sorry to report it didn't help (aside from modifying what appears
> in the title bar).
>
> On Sun, 22 Nov 2020 at 19:59, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > From: David Fussner <dfussner@googlemail.com>
> > > Date: Sun, 22 Nov 2020 19:23:16 +0000
> > > Cc: Eli Zaretskii <eliz@gnu.org>, 44794@debbugs.gnu.org
> > >
> > > Thanks for the tip -- it says "GNU Emacs at newfont" when it first
> > > comes up, then prepends the buffer name to that later.
> >
> > What happens if you change this:
> >
> >   Lisp_Object icon_title_name_format
> >     = pure_list (empty_unibyte_string,
> >                  build_pure_c_string ("%b - GNU Emacs at "),
> >                  intern_c_string ("system-name"));
> >
> > to say this instead:
> >
> >   Lisp_Object icon_title_name_format
> >     = pure_list (empty_unibyte_string,
> >                  build_pure_c_string ("GNU Emacs at "),
> >                  intern_c_string ("system-name"));
> >
> > This code is in xdisp.c.  The change I propose removes the "%b - "
> > part from the argument to build_pure_c_string.

bug#44794: 28.0.50; Frame creation broken with (tool-bar-mode -1)

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

I have an improved analysis of the bug.

Stefan's commit did _not_ cause the bug, merely uncovered it. Kwin was
setting a minimum frame size for frames that matched the original
initial frame title "emacs@system_name", so when Stefan changed that
to "GNU Emacs at system_name" kwin no longer resized the frame, and
that seems to be the root of the problem. (I haven't any idea whatever
where that kwin setting came from.)

Having eliminated the kwin setting, I was able to bisect again and
found that 2c0cd9008 was the culprit, which was J. Scott Berg's fix
for bug #44002 involving the vcxsrv X server on Windows. Reverting
that commit fixes my issue. Stepping through the code suggests that
his extra test in xterm.c (l. 8950) is preventing a resize event when
creating a new frame on my machine when tool-bar-mode is off. With
that mode on, the resize event still occurs, and new frames are
created normally.

I've done a little testing trying to find workarounds, so I'll include
a summary here in case that might help:

To reproduce the bug, I can simply start from ./emacs -Q, M-x
tool-bar-mode rtn, C-x 5 b rtn.

./configure --with-x-toolkit=lucid : works well (i.e., cairo build w/o
gtk works fine)
./configure --without-cairo : works well (i.e., w/ gtk3 and w/o cairo)
./configure --with-x-toolkit=gtk2 : shows same bug
./configure --with-x-toolkit=gtk2 --without-cairo : works well

So perhaps some interaction between cairo and gtk, possibly specific
to my library versions, seems to stop presentation of the main text
widget and also the mode line and minibuffer on new frames when no
tool bar is present. I should add that when the invisible buffer text
contains, say, a URL, rolling over it with the mouse still reveals the
tool tip describing the link, and clicking there does open the link in
the window, though the main text widget of that window remains
visually empty until I resize the frame.

Please let me know if I can provide any additional information.

David.

On Sun, 22 Nov 2020 at 21:47, David Fussner <dfussner@googlemail.com> wrote:
>
> As no one else seems to be able to reproduce this bug, I thought I
> would give a fuller list of the symptoms I've seen when using various
> set-ups in my .emacs file, in case that might help.
>
> If in addition to turning off the tool bar you add:
>
> (add-to-list 'default-frame-alist
>                 '(height . 30)
>                 '(font . "Luxi Mono-16"))
>
> Then the initial frame shows the splash page just fine, and all looks
> well. After C-x 5 b return then the *scratch* buffer pops up with all
> the problems described in the initial report: nothing visible in the
> main window and no mini-buffer, either.
>
> If you make the height too big for the screen, in my case with such a
> big font I set it to 33, then the initial frame shows the splash page
> just fine and is as tall as the screen allows. After C-x 5 b return
> then the *scratch* buffer does appear, with text and mini-buffer
> intact, only the second frame is about two-thirds the correct height.
>
> After Eli's suggestion above about the WM I did try shutting down KDE
> and running xfce4, with exactly the same results as with KDE, as far
> as I could tell.
>
> Thanks again to you both for all your help.
>
> David.
>
> On Sun, 22 Nov 2020 at 20:50, David Fussner <dfussner@googlemail.com> wrote:
> >
> > I'm sorry to report it didn't help (aside from modifying what appears
> > in the title bar).
> >
> > On Sun, 22 Nov 2020 at 19:59, Eli Zaretskii <eliz@gnu.org> wrote:
> > >
> > > > From: David Fussner <dfussner@googlemail.com>
> > > > Date: Sun, 22 Nov 2020 19:23:16 +0000
> > > > Cc: Eli Zaretskii <eliz@gnu.org>, 44794@debbugs.gnu.org
> > > >
> > > > Thanks for the tip -- it says "GNU Emacs at newfont" when it first
> > > > comes up, then prepends the buffer name to that later.
> > >
> > > What happens if you change this:
> > >
> > >   Lisp_Object icon_title_name_format
> > >     = pure_list (empty_unibyte_string,
> > >                  build_pure_c_string ("%b - GNU Emacs at "),
> > >                  intern_c_string ("system-name"));
> > >
> > > to say this instead:
> > >
> > >   Lisp_Object icon_title_name_format
> > >     = pure_list (empty_unibyte_string,
> > >                  build_pure_c_string ("GNU Emacs at "),
> > >                  intern_c_string ("system-name"));
> > >
> > > This code is in xdisp.c.  The change I propose removes the "%b - "
> > > part from the argument to build_pure_c_string.

bug#44794: 28.0.50; Frame creation broken with (tool-bar-mode -1)

[Eli Zaretskii]

> From: David Fussner <dfussner@googlemail.com>
> Date: Sun, 13 Dec 2020 18:17:41 +0000
> Cc: Stefan Kangas <stefan@marxist.se>, 44794@debbugs.gnu.org
> 
> Stefan's commit did _not_ cause the bug, merely uncovered it. Kwin was
> setting a minimum frame size for frames that matched the original
> initial frame title "emacs@system_name", so when Stefan changed that
> to "GNU Emacs at system_name" kwin no longer resized the frame, and
> that seems to be the root of the problem. (I haven't any idea whatever
> where that kwin setting came from.)
> 
> Having eliminated the kwin setting, I was able to bisect again and
> found that 2c0cd9008 was the culprit

If the original problem was due to kwin, and you solved it, then what
additional problem remains after that, for which you looked for the
culprit by bisection?

> which was J. Scott Berg's fix
> for bug #44002 involving the vcxsrv X server on Windows. Reverting
> that commit fixes my issue. Stepping through the code suggests that
> his extra test in xterm.c (l. 8950) is preventing a resize event when
> creating a new frame on my machine when tool-bar-mode is off. With
> that mode on, the resize event still occurs, and new frames are
> created normally.

Then what was the problem that kwin was responsible for?

bug#44794: 28.0.50; Frame creation broken with (tool-bar-mode -1)

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

I'm sorry I haven't been clear enough. The original bug -- the empty
new frame, with only a title bar, menu bar, and scroll bar, but with
an empty main window and no mode line or minibuffer -- still occurs
even after clearing the kwin setting I mentioned. Kwin was responsible
for the mistake I made in my original bisection, which showed that
Stefan's commit (36431e1679) was the first to produce the bug. In
fact, Stefan's commit only revealed a bug that had been produced, I
believe, by J Scott Berg's earlier commit (2c0cd9008) which altered a
test in xterm.c (l. 8950). That revised test, when I stepped through
the code, fails to trigger a resize when there is no tool bar, though
it does trigger a resize when there is a tool bar. (The old test,
pre-2c0cd9008, triggers a resize in both situations.) For reasons that
are still obscure to me, without that resize all text in the main
window is invisible after the creation of the new frame, and remains
so until I manually resize the frame. Compiling with different
toolkits and with or without cairo drawing affects whether the bug
appears or not, but in the default gtk3 + cairo build the bug is still
present, even without the spurious kwin setting. As I understood the
thread concerning bug #44002, that fix was not regarded as obviously
safe, and was therefore reserved for master. I'm suggesting,
therefore, that at least in my case that fix isn't safe, though it
would appear that I'm the only user running master who has run into
such an issue. I had hoped that someone might have an idea of how to
fix J Scott Berg's fix so that it worked both for vcxsrv and for
32-bit slackware 14.2. (None of my attempts have worked).

On Sun, 13 Dec 2020 at 18:53, Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: David Fussner <dfussner@googlemail.com>
> > Date: Sun, 13 Dec 2020 18:17:41 +0000
> > Cc: Stefan Kangas <stefan@marxist.se>, 44794@debbugs.gnu.org
> >
> > Stefan's commit did _not_ cause the bug, merely uncovered it. Kwin was
> > setting a minimum frame size for frames that matched the original
> > initial frame title "emacs@system_name", so when Stefan changed that
> > to "GNU Emacs at system_name" kwin no longer resized the frame, and
> > that seems to be the root of the problem. (I haven't any idea whatever
> > where that kwin setting came from.)
> >
> > Having eliminated the kwin setting, I was able to bisect again and
> > found that 2c0cd9008 was the culprit
>
> If the original problem was due to kwin, and you solved it, then what
> additional problem remains after that, for which you looked for the
> culprit by bisection?
>
> > which was J. Scott Berg's fix
> > for bug #44002 involving the vcxsrv X server on Windows. Reverting
> > that commit fixes my issue. Stepping through the code suggests that
> > his extra test in xterm.c (l. 8950) is preventing a resize event when
> > creating a new frame on my machine when tool-bar-mode is off. With
> > that mode on, the resize event still occurs, and new frames are
> > created normally.
>
> Then what was the problem that kwin was responsible for?

bug#44794: 28.0.50; Frame creation broken with (tool-bar-mode -1)

[Eli Zaretskii]

> From: David Fussner <dfussner@googlemail.com>
> Date: Sun, 13 Dec 2020 21:22:29 +0000
> Cc: Stefan Kangas <stefan@marxist.se>, 44794@debbugs.gnu.org
> 
> I'm sorry I haven't been clear enough. The original bug -- the empty
> new frame, with only a title bar, menu bar, and scroll bar, but with
> an empty main window and no mode line or minibuffer -- still occurs
> even after clearing the kwin setting I mentioned. Kwin was responsible
> for the mistake I made in my original bisection, which showed that
> Stefan's commit (36431e1679) was the first to produce the bug. In
> fact, Stefan's commit only revealed a bug that had been produced, I
> believe, by J Scott Berg's earlier commit (2c0cd9008) which altered a
> test in xterm.c (l. 8950). That revised test, when I stepped through
> the code, fails to trigger a resize when there is no tool bar, though
> it does trigger a resize when there is a tool bar. (The old test,
> pre-2c0cd9008, triggers a resize in both situations.) For reasons that
> are still obscure to me, without that resize all text in the main
> window is invisible after the creation of the new frame, and remains
> so until I manually resize the frame. Compiling with different
> toolkits and with or without cairo drawing affects whether the bug
> appears or not, but in the default gtk3 + cairo build the bug is still
> present, even without the spurious kwin setting. As I understood the
> thread concerning bug #44002, that fix was not regarded as obviously
> safe, and was therefore reserved for master. I'm suggesting,
> therefore, that at least in my case that fix isn't safe, though it
> would appear that I'm the only user running master who has run into
> such an issue. I had hoped that someone might have an idea of how to
> fix J Scott Berg's fix so that it worked both for vcxsrv and for
> 32-bit slackware 14.2. (None of my attempts have worked).

Thanks.  Does the patch below give good results?

Martin, given what was found during investigation of bug#44002, do you
agree the below should avoid re-introducing that bug?

diff --git a/src/xterm.c b/src/xterm.c
index 3de0d2e..7f8728e 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -8947,7 +8947,9 @@ handle_one_xevent (struct x_display_info *dpyinfo,
       if (!f
 	  && (f = any)
 	  && configureEvent.xconfigure.window == FRAME_X_WINDOW (f)
-	  && FRAME_VISIBLE_P(f))
+	  && (FRAME_VISIBLE_P(f)
+	      || !(configureEvent.xconfigure.width <= 1
+		   && configureEvent.xconfigure.height <= 1)))
         {
           block_input ();
           if (FRAME_X_DOUBLE_BUFFERED_P (f))
@@ -8962,7 +8964,10 @@ handle_one_xevent (struct x_display_info *dpyinfo,
           f = 0;
 	}
 #endif
-      if (f && FRAME_VISIBLE_P(f))
+      if (f
+	  && (FRAME_VISIBLE_P(f)
+	      || !(configureEvent.xconfigure.width <= 1
+		   && configureEvent.xconfigure.height <= 1)))
 	{
 #ifdef USE_GTK
 	  /* For GTK+ don't call x_net_wm_state for the scroll bar

bug#44794: 28.0.50; Frame creation broken with (tool-bar-mode -1)

[martin rudalics]

 > Martin, given what was found during investigation of bug#44002, do you
 > agree the below should avoid re-introducing that bug?

Hard to tell.  There configureEvent.xconfigure.height being 1 was never
explicitly mentioned.  It would be nice to have a backtrace where this
shows up.  OTOH Scott should notice any detrimental effect immediately.
Do you want to put this into Emacs 27.2?

martin

bug#44794: 28.0.50; Frame creation broken with (tool-bar-mode -1)

[Eli Zaretskii]

> Cc: stefan@marxist.se, 44794@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Sat, 19 Dec 2020 14:07:36 +0100
> 
>  > Martin, given what was found during investigation of bug#44002, do you
>  > agree the below should avoid re-introducing that bug?
> 
> Hard to tell.  There configureEvent.xconfigure.height being 1 was never
> explicitly mentioned.

My reading of

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44002#47

is that it was indeed 1x1.  Citation:

>  > I at least think I understand the width/height mystery. The bogus
>  > window size returned is 1x1.

Am I confused?

> Do you want to put this into Emacs 27.2?

No need, the problematic change is only on master, AFAICT.

bug#44794: 28.0.50; Frame creation broken with (tool-bar-mode -1)

[martin rudalics]

 > My reading of
 >
 >    https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44002#47
 >
 > is that it was indeed 1x1.  Citation:
 >
 >>   > I at least think I understand the width/height mystery. The bogus
 >>   > window size returned is 1x1.
 >
 > Am I confused?

I am.  I have severe problems reading the associated code with USE_CAIRO
and/or USE_GTK defined.  That's why I would have preferred to see these
1x1 assignments explicitly triggered by handle_one_xevent and/or
xg_frame_resized rather than via read xwininfo.

 >> Do you want to put this into Emacs 27.2?
 >
 > No need, the problematic change is only on master, AFAICT.

Then let's wait for Scott to answer.  Scott, can you check the patch Eli
posted in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44794#53 for
whether it breaks the previous patch for Bug#44002.

Thanks, martin

bug#44794: 28.0.50; Frame creation broken with (tool-bar-mode -1)

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

Thank you, Eli, the patch fixes my issue here, on a fresh pull of
master. (I know it's been said many times before, but you rock.) I
hope it works for #44002, as well.

David.

On Sat, 19 Dec 2020 at 15:55, martin rudalics <rudalics@gmx.at> wrote:
>
>  > My reading of
>  >
>  >    https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44002#47
>  >
>  > is that it was indeed 1x1.  Citation:
>  >
>  >>   > I at least think I understand the width/height mystery. The bogus
>  >>   > window size returned is 1x1.
>  >
>  > Am I confused?
>
> I am.  I have severe problems reading the associated code with USE_CAIRO
> and/or USE_GTK defined.  That's why I would have preferred to see these
> 1x1 assignments explicitly triggered by handle_one_xevent and/or
> xg_frame_resized rather than via read xwininfo.
>
>  >> Do you want to put this into Emacs 27.2?
>  >
>  > No need, the problematic change is only on master, AFAICT.
>
> Then let's wait for Scott to answer.  Scott, can you check the patch Eli
> posted in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44794#53 for
> whether it breaks the previous patch for Bug#44002.
>
> Thanks, martin

bug#44794: 28.0.50; Frame creation broken with (tool-bar-mode -1)

[Eli Zaretskii]

> From: David Fussner <dfussner@googlemail.com>
> Date: Sat, 19 Dec 2020 18:19:36 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>, Stefan Kangas <stefan@marxist.se>, 44794@debbugs.gnu.org, 
> 	"J. Scott Berg" <jsberg-bnl@outlook.com>
> 
> Thank you, Eli, the patch fixes my issue here, on a fresh pull of
> master. (I know it's been said many times before, but you rock.) I
> hope it works for #44002, as well.

Thanks for confirming.  Let's hope #44002 doesn't return.

bug#44794: 28.0.50; Frame creation broken with (tool-bar-mode -1)

[J. Scott Berg]

> -----Original Message-----
> From: martin rudalics <rudalics@gmx.at>
> Sent: Saturday, December 19, 2020 10:55 AM
> To: Eli Zaretskii <eliz@gnu.org>
> Cc: dfussner@googlemail.com; stefan@marxist.se; 44794@debbugs.gnu.org; J.
> Scott Berg <jsberg-bnl@outlook.com>
> Subject: Re: bug#44794: 28.0.50; Frame creation broken with (tool-bar-mode
> -1)
> 
> Then let's wait for Scott to answer.  Scott, can you check the patch Eli
> posted in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44794#53 for
> whether it breaks the previous patch for Bug#44002.

44002 is still fixed after applying the patch from comment 53.

Thanks,

-Scott

bug#44794: 28.0.50; Frame creation broken with (tool-bar-mode -1)

[martin rudalics]

 > 44002 is still fixed after applying the patch from comment 53.
 >
 > Thanks,

Thanks for checking, martin

bug#44794: 28.0.50; Frame creation broken with (tool-bar-mode -1)

[Eli Zaretskii]

> From: "J. Scott Berg" <jsberg-bnl@outlook.com>
> CC: "dfussner@googlemail.com" <dfussner@googlemail.com>, "stefan@marxist.se"
> 	<stefan@marxist.se>, "44794@debbugs.gnu.org" <44794@debbugs.gnu.org>, "J.
>  Scott Berg" <jsberg-bnl@outlook.com>
> Date: Mon, 21 Dec 2020 14:42:12 +0000
> 
> > -----Original Message-----
> > From: martin rudalics <rudalics@gmx.at>
> > Sent: Saturday, December 19, 2020 10:55 AM
> > To: Eli Zaretskii <eliz@gnu.org>
> > Cc: dfussner@googlemail.com; stefan@marxist.se; 44794@debbugs.gnu.org; J.
> > Scott Berg <jsberg-bnl@outlook.com>
> > Subject: Re: bug#44794: 28.0.50; Frame creation broken with (tool-bar-mode
> > -1)
> > 
> > Then let's wait for Scott to answer.  Scott, can you check the patch Eli
> > posted in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44794#53 for
> > whether it breaks the previous patch for Bug#44002.
> 
> 44002 is still fixed after applying the patch from comment 53.

Thanks, I therefore installed that change, and I'm marking this bug
done.

bug#44794: 28.0.50; Frame creation broken with (tool-bar-mode -1)

[Eli Zaretskii]

> From: David Fussner <dfussner@googlemail.com>
> Date: Sun, 22 Nov 2020 18:54:04 +0000
> Cc: Stefan Kangas <stefan@marxist.se>, 44794@debbugs.gnu.org
> 
> Forgive my incompetence, but my idea for how to do that appears to be
> faulty -- what would be the simplest way to detect which branch the
> code takes?

By stepping with GDB through that code.  (But you already found the
answer by a different method.)