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: Fri, 15 May 2020 18:00:18 +0300 Message-ID: <838shtgs59.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> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="104586"; 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 Fri May 15 17:01:44 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 1jZbqK-000R23-Pa for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 15 May 2020 17:01:44 +0200 Original-Received: from localhost ([::1]:58628 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZbqJ-00073f-Rp for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 15 May 2020 11:01:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47898) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jZbpe-0006Qu-M4 for bug-gnu-emacs@gnu.org; Fri, 15 May 2020 11:01:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55158) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jZbpe-00060x-BW for bug-gnu-emacs@gnu.org; Fri, 15 May 2020 11:01:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jZbpe-00024b-9s for bug-gnu-emacs@gnu.org; Fri, 15 May 2020 11:01:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 15 May 2020 15:01:02 +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.15895548446865 (code B ref 38181); Fri, 15 May 2020 15:01:02 +0000 Original-Received: (at 38181) by debbugs.gnu.org; 15 May 2020 15:00:44 +0000 Original-Received: from localhost ([127.0.0.1]:38471 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZbpL-0001mF-Vy for submit@debbugs.gnu.org; Fri, 15 May 2020 11:00:44 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:40392) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZbpL-0001gF-2o for 38181@debbugs.gnu.org; Fri, 15 May 2020 11:00:43 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:43021) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZbpE-0005iC-GG; Fri, 15 May 2020 11:00:36 -0400 Original-Received: from [176.228.60.248] (port=3415 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jZbpD-0005dy-9q; Fri, 15 May 2020 11:00:36 -0400 In-Reply-To: <96da8d16-0691-7b26-ec33-0b8ec25e3f3e@gmx.at> (message from martin rudalics on Mon, 11 May 2020 10:30:45 +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:180337 Archived-At: > Cc: jonas@bernoul.li, 38181@debbugs.gnu.org > From: martin rudalics > Date: Mon, 11 May 2020 10:30:45 +0200 > > > The second call happens before the first one, so it looks more correct > > to me. Why did you think you didn't need to set the frame title for > > child frames? > > Because on all systems excluding Windows child frames do not show their > titles. Calculating something that cannot be displayed doesn't strike > me as a good idea. 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? Anyway, if we want to be able create frames without titles, 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. > >> Disclaimer: In all those runs I do not know whether the > >> > >> (set-face-background 'internal-border "red") > >> > >> set the face_change flag or something else did. > > > > It doesn't. It sets the face_change flag of each frame instead. See > > internal-set-lisp-face-attribute. > > 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. > I have not tried yet but I'm convinced that we would fail for a normal > frame as well if we didn't set its frame title. This reliance of one > (internal border color) upon the conceptually unrelated other (setting > the frame title) looks fishy to me and IIRC causes redisplay_internal to > initially run with old character sizes until the actual ones get > realized when setting the frame title. "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? > >> 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. > >> So it's not so entirely trivial to do that in Elisp. > > > > Why do we need to do this in Lisp? > > Didn't you propose to calculate the mode-line height from > 'fit-window-to-buffer'? I don't remember, but if so, it doesn't yet mean everything must be done in Lisp. > >> OK. But IIUC so far we do not allow inhibit_free_realized_faces nil > >> outside of redisplay_internal. Unless someone sets > >> 'inhibit-free-realized-faces' which is, in general, to recommended. > >> Right? > > > > Yes, but I see no reason not to reset it in other places, provided > > that we do it carefully and only when absolutely needed. > > We should say that in the doc-string of 'inhibit-free-realized-faces', > maybe. We should? why?