From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: David Fussner via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#44794: 28.0.50; Frame creation broken with (tool-bar-mode -1) Date: Sun, 13 Dec 2020 18:17:41 +0000 Message-ID: References: <838satxufx.fsf@gnu.org> <83o8jpw813.fsf@gnu.org> <83lfetw4bf.fsf@gnu.org> Reply-To: David Fussner Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40644"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Kangas , 44794@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Dec 13 19:21:16 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1koVzf-000ART-RS for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 13 Dec 2020 19:21:15 +0100 Original-Received: from localhost ([::1]:34800 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1koVze-0008UP-Sn for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 13 Dec 2020 13:21:14 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39340) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1koVzU-0008TG-0O for bug-gnu-emacs@gnu.org; Sun, 13 Dec 2020 13:21:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38625) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1koVzS-0000mT-Iv for bug-gnu-emacs@gnu.org; Sun, 13 Dec 2020 13:21:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1koVzS-000350-Fc for bug-gnu-emacs@gnu.org; Sun, 13 Dec 2020 13:21:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: David Fussner Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 13 Dec 2020 18:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44794 X-GNU-PR-Package: emacs Original-Received: via spool by 44794-submit@debbugs.gnu.org id=B44794.160788361311730 (code B ref 44794); Sun, 13 Dec 2020 18:21:02 +0000 Original-Received: (at 44794) by debbugs.gnu.org; 13 Dec 2020 18:20:13 +0000 Original-Received: from localhost ([127.0.0.1]:50168 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1koVye-000338-O0 for submit@debbugs.gnu.org; Sun, 13 Dec 2020 13:20:13 -0500 Original-Received: from mail-qk1-f172.google.com ([209.85.222.172]:34711) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1koVyc-00032q-RM for 44794@debbugs.gnu.org; Sun, 13 Dec 2020 13:20:11 -0500 Original-Received: by mail-qk1-f172.google.com with SMTP id c7so13677805qke.1 for <44794@debbugs.gnu.org>; Sun, 13 Dec 2020 10:20:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NmIa/q+4Lr6vZqTnRXChvDk89fnSvpMnef4h+Ut+Azo=; b=YSW1C0zbMWRFeIyn6jnkB0mT6I3sYFqr41zdnU1Gj6Svv94OkU7t5BuSbWd0nGUb3e dRbs2fsLja7GZeS4pxVLePjEweiwgjNH8TKxxMfXvYqBiOu+Xvcxkh9n7sBBvPxf3B5x LlG8ZMrqz123GtjEmORqlwFBLrT+/MuArlyd1YibJz0xbUQIeXuOpHY7zzkPMyXpY2Xl irFpQCNZoVvicnPEMrd5Zw7yTZMkjsl08oTrpRIlXWzr254b0+k/9L6xS9phR8F+243D oNqtg1YsyUMzjlRK2w53EtAy4/8BJ3v91GMhdHmIwLAtZbPqy3PmZtbO6g8i/+7yhAhO HK1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NmIa/q+4Lr6vZqTnRXChvDk89fnSvpMnef4h+Ut+Azo=; b=cxkuXCra+veywin8MSxU0hVhky1n7bnZ2vHet2ynbxo9+YNIUA0vrkwFHkOsN11mIs d1lYFE9nvonext3ia8xAcx0lK4VSBDBeSU+E32UgU/8r2eHZokEanURNF32VZVWCYsX0 W3c96zQ0T8Zme+8zg1E0OIjWqo9rkgbHbc7E80HzBerBRG31EIH4SNg+yqD8VWE+I7Az LtJsn5yWLgkjvpDDp/Eg4YzWSb+SMuhDC7wjMe5jyek6MJ67PQMjUTtsYd1L9e9xOVdU lI3DT9HxWlONVYnZq+rsvXUznVdYFWe/jlql2ZXwZRjj8soWn64DdGbb6kDiXdF3PfuD EXwA== X-Gm-Message-State: AOAM533x53iU5GgAMW53j/bLffUjLAWWBtuntuuil8EXtP1euO79EXBk zbu1Pzo8zGOLnzUAjnltGIDntqfW4Gu6EJ3+G2Y= X-Google-Smtp-Source: ABdhPJz5PMrP6KGtiYVaX1G5BZBORLqdlPGAuf5/RLS6YHjYhyIuZGeFkiEbihVOqxyXAHLvYFt4nd3Ow2UtElrh3kc= X-Received: by 2002:a05:620a:218e:: with SMTP id g14mr31046759qka.243.1607883605293; Sun, 13 Dec 2020 10:20:05 -0800 (PST) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:195991 Archived-At: 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 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 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 wrote: > > > > > > > From: David Fussner > > > > Date: Sun, 22 Nov 2020 19:23:16 +0000 > > > > Cc: Eli Zaretskii , 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.