From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#38181: Actual height of mode-line not taken into account Date: Sat, 16 May 2020 10:44:38 +0200 Message-ID: <012a6909-f4b7-8863-5b59-aedf8149b764@gmx.at> References: <87eeyd3ul0.fsf@bernoul.li> <83d0dt2qt6.fsf@gnu.org> <83r2290w24.fsf@gnu.org> <83pnhs6wwp.fsf@gnu.org> <83k1806qca.fsf@gnu.org> <8336en7giv.fsf@gnu.org> <81264049-4f88-fae7-6448-e0ac5d977268@gmx.at> <83a78u5s8y.fsf@gnu.org> <01cee2f7-aeb5-4eb1-b2d5-e056c91eab8b@gmx.at> <83wo5rolsc.fsf@gnu.org> <4682372c-e25a-dc62-842f-c3971f79bb16@gmx.at> <838si6mnsy.fsf@gnu.org> <86491f07-ed68-2880-17a0-a60ed40d5059@gmx.at> <83ftcdktrm.fsf@gnu.org> <6713049b-49e2-64ca-902d-1f972952f590@gmx.at> <83v9l3dflc.fsf@gnu.org> <96da8d16-0691-7b26-ec33-0b8ec25e3f3e@gmx.at> <838shtgs59.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="ciao.gmane.io:159.69.161.202"; logging-data="84811"; mail-complaints-to="usenet@ciao.gmane.io" Cc: jonas@bernoul.li, 38181@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat May 16 10:45:32 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 1jZsRn-000LxM-FB for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 16 May 2020 10:45:31 +0200 Original-Received: from localhost ([::1]:37056 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZsRl-0001Nr-J9 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 16 May 2020 04:45:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55174) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jZsRK-0001Nk-Bc for bug-gnu-emacs@gnu.org; Sat, 16 May 2020 04:45:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56435) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jZsRK-0001kY-1P for bug-gnu-emacs@gnu.org; Sat, 16 May 2020 04:45:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jZsRK-0003kQ-04 for bug-gnu-emacs@gnu.org; Sat, 16 May 2020 04:45:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 May 2020 08:45:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38181 X-GNU-PR-Package: emacs Original-Received: via spool by 38181-submit@debbugs.gnu.org id=B38181.158961869114371 (code B ref 38181); Sat, 16 May 2020 08:45:01 +0000 Original-Received: (at 38181) by debbugs.gnu.org; 16 May 2020 08:44:51 +0000 Original-Received: from localhost ([127.0.0.1]:39748 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZsR8-0003jj-LS for submit@debbugs.gnu.org; Sat, 16 May 2020 04:44:50 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]:59561) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZsR6-0003jT-O9 for 38181@debbugs.gnu.org; Sat, 16 May 2020 04:44:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1589618681; bh=CmycTmNWgxCHEjKeWKSHN7ldRyfoIM8fkRoQud4N+zg=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=ECvGlZgpDk2tnaWxvjAoiDFMYYWKXd47AfF+N15UajONgVY1jDGoR20loY9eA9h+a k2S9WiddsVlo9vZ435ZZBf6HrzCp2zoQSveYPv6wcUVSXXBr8emf6Vll7blJq4vB59 MX0eoz+9r1jFKhzJKqTVbk4cVXXbseZMi8kl2KIw= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([212.95.5.16]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MDQiS-1jPO2R2WFK-00AUKc; Sat, 16 May 2020 10:44:41 +0200 In-Reply-To: <838shtgs59.fsf@gnu.org> Content-Language: en-US X-Provags-ID: V03:K1:RczREYQZdqVgADMH8MK9jBQnnSpP9xpa5DpQ/DJ89Xo1Ah/lTST XIKyq7fd7Nyb8x/+Ee+zkFRAU/QWAzyKrLPWUFcvpkbdGXs2TEpz0XyLoxyoevLzTi6FT3A BVsRv7/sKREL7E9Aim1mbYHtZqrwCPfxu6tcux5VzMVIdaGZfbR7kAUS3BwChQy17PxPPLs VwwvnK02P1lXgJlBfrRVw== X-UI-Out-Filterresults: notjunk:1;V03:K0:u2u9/8Y68ME=:zsMhRFRXpwRC3tRSHIvdAt 2L2QG6R1dnajr1qda8wcadk65SS17/VR/bo8rB7Hs16n86eMCZOOpAr2QobF7ddEHfyXXUOyz wqJTHEMtlZ5bmARlHsL/TriRFvgI6jffUT5PDY5Az7vid/1eF67XkWyLEZ+o3m9pmG8xzM1Do FAxDglW/1RGYnwraDCOV1T8319TJCYxOh1wlTYwTTvKFtd6R3KqP3hj3BsaUX79Ho+aTmmiKb FT9oANpbRMe7kQYwXawv5ZqDAnfd0ilvstGj3wXkWwR6vbc2ACobI2SZQYAmDSeiUdiYSLVeF tgVB+Tf763n+NNBaMKUO75NmgbA1oeBZuIHsxzBiyW0BOZSP0/C6RyP+icdaQ9xwOKjZM2wTo Tdm+CpAiAOkXeV85EpR1y4UP11bK1w66OfvdY6rTmORvmFoUsOQPcsAW/f8U2B2br7noERO6t 8GWU88ByJP0RgpW9XMhkXxj+pfrGoDJ4R0uSE4rG6/J4P+EC8PYcGqbVieIC9XYeCzzilgCfW fRy8wnV5Udh+AK5Q1yH22qmh9kywJjt09th2PGeehujROwcDVhrFJdICwDQUvMzCp+iJ8Tx5f 72C1wLNABHjFk/sCw4avUbL1z1P0f8sy/cnv2APHPk3FLcNhY25y1/cZ8yeNVzI+fsRehsPeW Nbka1Ep4p18BBUTxCrst+cVjkQ4CUZgNR+mhJe4N/AKQOisVz5wGooINP+nlmXx4eVLGdq6eh u1M2z0sGq5jH+DFu3IeYI1vQ7Kgylv6TGnToUVV7nsu2xEYtOlhDedokcDoKZGqqJ/nh9knG 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:180378 Archived-At: >> And obviously native tooltip frames which suffer the >> same problem using >> >> (progn >> (setq x-gtk-use-system-tooltips nil) >> (set-face-background 'internal-border "red")) >> >> would still not display borders correctly. Or should we set their >> titles too? > > Is that a serious question? Given my current knowledge of the matter, yes. Note that ATK apparently even mandates that tooltip windows have some sort of title set. > Anyway, if we want to be able create frames without titles, Our tooltips are frames and don't have titles so we do that already. >> This way of setting things confuses me. What is then that global >> face_change bool needed for? > > For when we don't want to loop over all the frames setting their > individual flags, I guess. Agreed. But does our code adhere to that idea? gui_set_font_backend sets face_change to true and so does IT_set_frame_parameters (not that it matters here - I'm just talking about the idea) while working on a specific frame. And in x_create_tip_frame and w32_create_tip_frame we even have to save the value of it via face_change_before even though these two functions really should only affect the tip frame about to be created. All other settings of face_change happen in xfaces.c and that one really should know better. > "Initially run with old character sizes" doing what? AFAIR, we do the > frame title thingy quite early during the redisplay cycle. What is > done before that that needs to know about the faces change? Earlier, when debugging this issue, I spent some time stepping through the iterator with the old faces in place and just wondered why the new faces would not get applied. Whenever I'm back there I might be able to tell more. But before that I'd rather wait whether your > I guess we > should simply arrange for the face cache to be cleared and the basic > faces recomputed somewhere near the beginning of redisplay_internal. could be implemented and solve all these problems in one rush. >> >> Sheer luck, I presume. Couldn't PRODUCE_GLYPHS set >> >> inhibit_free_realized_faces iff redisplaying_p is true? >> > >> > No, because some functions we call from Lisp actually write into the >> > current matrix. For example, tool-bar-height and tab-bar-height. >> >> Then there's more to it than the above "the flag must be set during >> redisplay, until update_frame finished its job"? > > More in what way? This just means we sometimes set it elsewhere as > well. With the inevitable consequence that redisplay_internal restores it to true when it exits. Is that the idea behind "we sometimes set it elsewhere as well" or just some sort of collateral damage? >> We should say that in the doc-string of 'inhibit-free-realized-faces', >> maybe. > > We should? why? Because it might help people like me understand this issue. Do you think that my questions are provocative? Maybe they are, but then that's a consequence of the fact that I don't get the picture of our implementation of faces. martin