From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#46827: Broken initial size of GTK3 frame Date: Wed, 3 Mar 2021 10:40:04 +0100 Message-ID: <735366e4-389c-1c71-438d-6d928de02e44@gmx.at> 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> <83eegw61zc.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28645"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 46827@debbugs.gnu.org, rpluim@gmail.com, stephen.berman@gmx.net To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Mar 03 10:41:25 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 1lHO0S-0007LN-B8 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Mar 2021 10:41:24 +0100 Original-Received: from localhost ([::1]:49506 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lHO0R-00086i-7T for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Mar 2021 04:41:23 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55392) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lHO05-00084c-WD for bug-gnu-emacs@gnu.org; Wed, 03 Mar 2021 04:41:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43642) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lHO05-0007LF-O4 for bug-gnu-emacs@gnu.org; Wed, 03 Mar 2021 04:41:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lHO05-0000MJ-Km for bug-gnu-emacs@gnu.org; Wed, 03 Mar 2021 04:41:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Mar 2021 09:41: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.16147644171321 (code B ref 46827); Wed, 03 Mar 2021 09:41:01 +0000 Original-Received: (at 46827) by debbugs.gnu.org; 3 Mar 2021 09:40:17 +0000 Original-Received: from localhost ([127.0.0.1]:55188 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHNzN-0000LE-JA for submit@debbugs.gnu.org; Wed, 03 Mar 2021 04:40:17 -0500 Original-Received: from mout.gmx.net ([212.227.17.21]:34865) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lHNzL-0000Ku-1R for 46827@debbugs.gnu.org; Wed, 03 Mar 2021 04:40:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1614764408; bh=2O8RuRbwcyVUjeU/7lVkcKF/j+hLDJXTN66zJybUeIo=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=ToYyYquTvvHEHlYbVN8RgKkogfIo4B8YNMIB5r5TMYZBzMWps7Ku3cVW720WL5RNH I4mcWxSt9xCqgrJB7llAxPayX/nZpBPz8poT0TzpdmOgXQvNBIwg0zrlk7EF6praeO NaHWjGR7zmIyQzpakpU5qdT5VEwN9X5jfvVWPH2s= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.100] ([212.95.7.233]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MI5UN-1l2HgG28TX-00FCAd; Wed, 03 Mar 2021 10:40:07 +0100 In-Reply-To: <83eegw61zc.fsf@gnu.org> Content-Language: en-US X-Provags-ID: V03:K1:+4tWN2VLzldscvWxDK6ql4lVDJwp77IKwE3ZX9nNbp1zQD7+sgT mVuTvIpbUEf8nnAOJg/RpL5mPb3KINSPDHXQLJidq5AilXIjNP6leukqZAQTw+9Rv14LMxh Nr+zaLii7hbQmgPCYzeKAdbl0r7rE8wzQKjMZbRscIgLurCOOb5I2A79AdCmV/FBIXwTCl0 R8W4kC3oxuOS8nhsB00oA== X-UI-Out-Filterresults: notjunk:1;V03:K0:XAk6MPg9ytM=:2cfbF1d53EWpk+3/u1wpST n22oLpxzeq4602lMfxN9Cz9JnKehb0S7x3+qLGjoOqgIxV0W7NMDeo2Vo4aen7miEruEmdodL +Lnon7SGuLMjQz6oLvgqhCkFYqdEG2TxCwogWjx9Cocm5umAgGWiYKJbo/PXQ79M7rJ/ucOR4 iRu624c+8Y98aUs75NHGrIAWnNXCtmZXe9Ka0ilNYSoFYRwx++0MlGEzilwmO0z84kGBHW2Kv OA5MWqvY8FIUK2AY5QVPyYjEpq8Q0pqAVz0Njf4ZcAjm0I7fBb7K6l6vVgopDzf0cwUNPgWlL 53ryHp48fIUWDj/AW4vuMsFjT1+O7PEmFyZ9nP5PaLpkvXshPcwd9WSTnjT7EdGWnvF2x+rwi FwBOu+E7/pvQJXVhu8zueKlnREJeTzqHU11T1qnGdBoYVlbibqOdmwtBFXHN+a3Z3nXvLJNP+ ePaqoBkRVU8dWEj2gQLrtx+ir7T0i+aWuEa2XW1h9ESr2FmE6L7LsF6sIKWlW6LWR9egSQTSa SCWruyQuOrg8bl1iZ8gBDnPWBG3tlJCo3WgqJfuqmDqBD5dJUX1Z9Thk4h/83AH4lBCeUY6kl jDv5nAbIQYYOMe8LFq/eOwtAPI5Fr2Cc2/+/UrjlOEro0evIJO2dICevQ8rXVNPJGlXI5y7/c RB+hUli7VLqub5BexTekpakt2APvXHZIC36oMB8NBPYV2+eKZZjvNJxs7Q0YIjbThf6iPrAXO P3g/Oe+HDKYxJ6xqNuTvRWFSLWcHodEJG+OzgxTPIFkWgspmrwlBtHSPXed/2fXri1yKb7j4 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:201268 Archived-At: >> 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? The check above doesn't care about windows_or_buffers_changed. The last one in redisplay_internal does: /* Change frame size now if a change is pending. */ do_pending_window_change (true); /* If we just did a pending size change, or have additional visible frames, or selected_window changed, redisplay again. */ if ((windows_or_buffers_changed && !pending) || (WINDOWP (selected_window) && (w = XWINDOW (selected_window)) != sw)) goto retry; So if in the (!must_finish) guarded check windows_or_buffers_changed was set but the selected window remained unchanged, we don't go to retry. >> 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? I meant to ask why we don't check the f->garbaged flag of the frame instead of windows_or_buffers_changed. do_pending_window_change to my knowledge does not set windows_or_buffers_changed but sets the garbaged flag. >> 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? run_window_scroll_functions could do it later on, but that is run by redisplay itself. > If this can never happen, we should replace the test with an > assertion, and wait for it to fire if we are missing something. I'll try that here. martin