From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#46827: Broken initial size of GTK3 frame Date: Wed, 03 Mar 2021 11:05:59 +0200 Message-ID: <83eegw61zc.fsf@gnu.org> References: <6caa020a-084c-e3f2-7a34-262f7127b21b@gmx.at> <87eegz41ui.fsf@gmail.com> <875z2b3srx.fsf@gmail.com> <87ft1fyo88.fsf@gmail.com> <8a346498-e7e3-ca92-e518-86f6fc2c37b7@gmx.at> <87y2f6spgm.fsf@gmail.com> <87v9aaslh9.fsf@gmx.net> <689ba08c-639f-af40-5c30-95dcceac552f@gmx.at> <359cec57-48d3-dc97-df0f-a778a0786001@gmx.at> <83zgzl63y0.fsf@gnu.org> <83tupt5x95.fsf@gnu.org> <83a5e0e7-a55d-48bf-00f6-942d6c6c3be5@gmx.at> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40500"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 46827@debbugs.gnu.org, rpluim@gmail.com, stephen.berman@gmx.net To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Mar 03 10:07:10 2021 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 1lHNTK-000ANn-NH for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Mar 2021 10:07:10 +0100 Original-Received: from localhost ([::1]:59058 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lHNTJ-0007zv-5M for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Mar 2021 04:07:09 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47984) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lHNTC-0007zY-6P for bug-gnu-emacs@gnu.org; Wed, 03 Mar 2021 04:07:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43563) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lHNTB-0004v4-VG for bug-gnu-emacs@gnu.org; Wed, 03 Mar 2021 04:07:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lHNTB-0007wI-Nr for bug-gnu-emacs@gnu.org; Wed, 03 Mar 2021 04:07:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Mar 2021 09:07:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46827 X-GNU-PR-Package: emacs Original-Received: via spool by 46827-submit@debbugs.gnu.org id=B46827.161476238330464 (code B ref 46827); Wed, 03 Mar 2021 09:07:01 +0000 Original-Received: (at 46827) by debbugs.gnu.org; 3 Mar 2021 09:06:23 +0000 Original-Received: from localhost ([127.0.0.1]:55109 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHNSY-0007vI-Oh for submit@debbugs.gnu.org; Wed, 03 Mar 2021 04:06:23 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:58216) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHNSX-0007v5-AD for 46827@debbugs.gnu.org; Wed, 03 Mar 2021 04:06:21 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:33377) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lHNSR-0004kB-LJ; Wed, 03 Mar 2021 04:06:15 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2574 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lHNSN-00022q-Ox; Wed, 03 Mar 2021 04:06:15 -0500 In-Reply-To: <83a5e0e7-a55d-48bf-00f6-942d6c6c3be5@gmx.at> (message from martin rudalics on Wed, 3 Mar 2021 09:48:16 +0100) 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:201265 Archived-At: > From: martin rudalics > Cc: stephen.berman@gmx.net, rpluim@gmail.com, 46827@debbugs.gnu.org > Date: Wed, 3 Mar 2021 09:48:16 +0100 > > > Thanks, but is there any reason to remove the call before updating the > > tool bar? You see, I believe one of the reasons for the need to > > clear_garbaged_frames is that call you suggest to remove. Why not > > leave it there, and _add_ one more call after prepare_menu_bars (and > > perhaps condition it on the same condition as prepare_menu_bars)? > > We can obviously do that (see attached patch). But is there any reason > we cannot run the > > do_pending_window_change (true); > clear_garbaged_frames (); > > _after_ the > > prepare_menu_bars (); > do_pending_window_change (true); > > block? I have no idea, and don't know how to check that. We could try, and then be ready to fix any adverse effects this could cause. > In either case, the more I look into this, the more things confuse me. > For example, why does > > if (!must_finish) > { > do_pending_window_change (true); > /* If selected_window changed, redisplay again. */ > if (WINDOWP (selected_window) > && (w = XWINDOW (selected_window)) != sw) > goto retry; > > not check for windows_or_buffers_changed too just as we do after the > third do_pending_window_change call? Because going to 'retry' will eventually make that check again. Or maybe I don't understand what exactly are you asking here? > But then I don't understand why we > check for windows_or_buffers_changed at all. adjust_frame_size doesn't > set that IIUC but it does garbage the frame - why don't we check that in > redisplay_internal? Sorry, I don't understand the question. We _are_ talking about redisplay_internal, right? and redisplay_internal does check windows_or_buffers_changed, right? so what do you mean by "why don't we check that in redisplay_internal"? and what is "that" in this case? > >> While frame resizing can make the > >> selected window small, it will neither remove nor change it. > > > > Never-ever? > > Never-ever. Fdelete_window_internal, Fdelete_other_windows_internal and > Fset_window_configuration are the only functions allowed to delete > windows. Not even due to some Lisp hook run directly or indirectly when the frame is resized? If this can never happen, we should replace the test with an assertion, and wait for it to fire if we are missing something. > run_window_change_functions could delete the selected window > so we probably should do the w == sw check after that now. Yes, I think so. Patches welcome.