unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: David Fussner <dfussner@googlemail.com>,
	martin rudalics <rudalics@gmx.at>
Cc: stefan@marxist.se, 44794@debbugs.gnu.org
Subject: bug#44794: 28.0.50; Frame creation broken with (tool-bar-mode -1)
Date: Sat, 19 Dec 2020 12:42:22 +0200	[thread overview]
Message-ID: <83zh2at6up.fsf@gnu.org> (raw)
In-Reply-To: <CADF+RthMDw7MiMrTef3sj_fYgTsA99J1TKen1rXLATuTYYQ7tA@mail.gmail.com> (message from David Fussner on Sun, 13 Dec 2020 21:22:29 +0000)

> 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





  reply	other threads:[~2020-12-19 10:42 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-22 12:46 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
2020-11-22 13:43 ` David Fussner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-11-22 15:20 ` Stefan Kangas
2020-11-22 15:49   ` Eli Zaretskii
2020-11-22 18:08     ` David Fussner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-11-22 18:39       ` Eli Zaretskii
2020-11-22 18:54         ` David Fussner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-11-22 19:16           ` Stefan Kangas
2020-11-22 19:23             ` David Fussner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-11-22 19:59               ` Eli Zaretskii
2020-11-22 20:50                 ` David Fussner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-11-22 21:47                   ` David Fussner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-12-13 18:17                     ` David Fussner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-12-13 18:53                       ` Eli Zaretskii
2020-12-13 21:22                         ` David Fussner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-12-19 10:42                           ` Eli Zaretskii [this message]
2020-12-19 13:07                             ` martin rudalics
2020-12-19 13:22                               ` Eli Zaretskii
2020-12-19 15:55                                 ` martin rudalics
2020-12-19 18:19                                   ` David Fussner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-12-19 18:31                                     ` Eli Zaretskii
2020-12-21 14:42                                   ` J. Scott Berg
2020-12-21 15:33                                     ` martin rudalics
2020-12-21 17:29                                     ` Eli Zaretskii
2020-11-22 19:37           ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83zh2at6up.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=44794@debbugs.gnu.org \
    --cc=dfussner@googlemail.com \
    --cc=rudalics@gmx.at \
    --cc=stefan@marxist.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).