From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#38181: Actual height of mode-line not taken into account Date: Sat, 16 May 2020 13:46:41 +0300 Message-ID: <83tv0gcg32.fsf@gnu.org> 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> <012a6909-f4b7-8863-5b59-aedf8149b764@gmx.at> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="71258"; mail-complaints-to="usenet@ciao.gmane.io" Cc: jonas@bernoul.li, 38181@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat May 16 12:48:09 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 1jZuMT-000IOZ-9d for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 16 May 2020 12:48:09 +0200 Original-Received: from localhost ([::1]:50130 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZuMS-0001t6-Aq for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 16 May 2020 06:48:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37814) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jZuMM-0001s3-4e for bug-gnu-emacs@gnu.org; Sat, 16 May 2020 06:48:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56547) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jZuML-0006ZX-RT for bug-gnu-emacs@gnu.org; Sat, 16 May 2020 06:48:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jZuML-0006rF-Ql for bug-gnu-emacs@gnu.org; Sat, 16 May 2020 06:48:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 May 2020 10:48: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.158962602226271 (code B ref 38181); Sat, 16 May 2020 10:48:01 +0000 Original-Received: (at 38181) by debbugs.gnu.org; 16 May 2020 10:47:02 +0000 Original-Received: from localhost ([127.0.0.1]:39851 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZuLN-0006pV-KA for submit@debbugs.gnu.org; Sat, 16 May 2020 06:47:02 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:58462) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZuLL-0006pB-M5 for 38181@debbugs.gnu.org; Sat, 16 May 2020 06:47:00 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40017) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZuLF-0006OA-DG; Sat, 16 May 2020 06:46:53 -0400 Original-Received: from [176.228.60.248] (port=4591 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jZuLE-0005q2-Af; Sat, 16 May 2020 06:46:53 -0400 In-Reply-To: <012a6909-f4b7-8863-5b59-aedf8149b764@gmx.at> (message from martin rudalics on Sat, 16 May 2020 10:44:38 +0200) 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:180382 Archived-At: > Cc: jonas@bernoul.li, 38181@debbugs.gnu.org > From: martin rudalics > Date: Sat, 16 May 2020 10:44:38 +0200 > > > 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. Yes, of course. I hope you don't assume I didn't know that. > >> 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. Could you please tell where is this discussion going? Because I no longer understand that. We seem to be talking around the issue, but to what end? Why are these details important for whatever job you have in mind? I'd like to help you do that job, but I'm lost in "twisty little passages, all alike". > > 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. All it takes is to call free_all_realized_faces for the frame in question, and then do what init_iterator does: if (FRAME_FACE_CACHE (it->f) == NULL) init_frame_faces (it->f); if (FRAME_FACE_CACHE (it->f)->used == 0) recompute_basic_faces (it->f); > 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? I don't think it matters that this flag is set when we are outside redisplay.