From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: 8af8355c3f72500986f6f10b62714b228d6f35ee breaks minibuffer echo with Lucid Date: Wed, 07 Oct 2015 11:47:46 +0200 Message-ID: <5614EA42.9010308@gmx.at> References: <5613954A.2080804@yandex.ru> <5613A061.7030605@gmx.at> <83h9m4xd8v.fsf@gnu.org> <56140AE1.2010502@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1444212139 13275 80.91.229.3 (7 Oct 2015 10:02:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 7 Oct 2015 10:02:19 +0000 (UTC) Cc: dmantipov@yandex.ru, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 07 12:02:09 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZjlY1-0006YJ-GG for ged-emacs-devel@m.gmane.org; Wed, 07 Oct 2015 12:02:09 +0200 Original-Received: from localhost ([::1]:56743 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjlXv-0004BK-O8 for ged-emacs-devel@m.gmane.org; Wed, 07 Oct 2015 06:02:03 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52058) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjlKF-0007Ei-3P for emacs-devel@gnu.org; Wed, 07 Oct 2015 05:47:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZjlKB-00088t-Nk for emacs-devel@gnu.org; Wed, 07 Oct 2015 05:47:55 -0400 Original-Received: from mout.gmx.net ([212.227.15.15]:62495) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjlKB-00088Y-Cd; Wed, 07 Oct 2015 05:47:51 -0400 Original-Received: from [93.82.9.50] ([93.82.9.50]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LgptO-1aMerA1IMY-00oCaC; Wed, 07 Oct 2015 11:47:50 +0200 In-Reply-To: <56140AE1.2010502@gmx.at> X-Provags-ID: V03:K0:TfHzfMo82aClhMJBi0RTz/jBRFS/IuQ6MJp5ucP8JYpLQval2Ld ++opGLicvkK6Xlv2p7fr3q7MfQj+pULAzJfnbtp9YFDZeYkdP2yqJtZtPOwlEX0zS255pFz Rc6I2o5KO32BDrFZMhkExBNx89kYdzXLp1Ows5/qRtYaYr9vRRNYE37AlQtEAsTPZ1RHl38 d+QhqiCbEPP8NgxlI+qAw== X-UI-Out-Filterresults: notjunk:1;V01:K0:GHGTQ2dD+LU=:Qg/YwYYTjg9YvLPTAYzm1I ammg9GpuM8lW5uaW22RMYGDWwuSvIfswB4a9VxWNQ3gT5YH1MbGL8lkKZN1UVs3PaX7Uv7JqJ RvdckBioShjant+NgEs89g7gKxrTC8nAMXq+gytKN1etAKzsei9kNiuJYQhjdSvARFMPRvVp9 t0P3qxynm4Aafy6zKGLBs+m5yR3lunRvZyjyMkOiZTVDIEzOApuZRI1ylaQgzP33LYkD5Oeku VaZFx8WnKwvXfZVI9evYrv5njVFZ2LcOV+59Zrr6k8OcWfqu5R2oipmXBpmy8WWk5Oh64boZ5 G9/Km+artBQuoOBqD0+SXsJm+YXjzTxtvbg+ppiJCxdBumRAkoJHLKR1RP8twjVZT9VKZElST 1W0h4kt8/XWrzllcZTlEDwjXxEso3LoZ9Nv8Py0G/geTvUrt9NgzQ3fF13s617F6/CYcEcpoF JQ4I9eX7L+4U+tUObRGhNmyK+Gl17/iiAEh0e7KE8O7aC5Q1hb8ftutJf00Gv4twkObhRqghR /AVEr7OBir9r3ZJdmXV8/83Uhp3tsoKL6WHVIpr3RvJYv8dwpKH8GildO7fk12LA1WdVP/4+B z8Z/hdCBzncH+jL7+2is8HE9Mdh+LWonlGy4nfW47tejlkUMLG6tiO/CPoAEKCcclWnlFJAgw RmYudSXZiKqACHlH47+eW0F18uAyPxlmlhkkQTJaVqaJyyCEwFVPIk4wVcNpj+QUsynShabJh nG5JP4Pwmq2ga2wJ2vmI/gNOc/s8DQN18Fte4TdEBn1mzK2Q6mh2Ve7qShHeBxuzpgM4mR2n X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.15.15 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:191043 Archived-At: > We always do that whenever setting a frame parameter can change any of > the frame's dimensions. Here for some mysterious reason the top line of > the minibuffer is not set up correctly in resize_frame_windows. I'm yet > too silly to find out why. It was a silly bug. A more intuitive recipe to reproduce it was (progn (split-window) (tool-bar-mode 0) (scroll-bar-mode -1)) The old code contained this logic: adjust_frame_size calls resize_frame_windows a first time when (new_windows_width != old_windows_width) and a second time when (new_windows_height != old_windows_height /* When the top margin has changed we have to recalculate the top edges of all windows. No such calculation is necessary for the left edges. */ || WINDOW_TOP_PIXEL_EDGE (r) != FRAME_TOP_MARGIN_HEIGHT (f)) But the old resize_frame_windows code _unconditionally_ set r->top_line = FRAME_TOP_MARGIN (f); r->pixel_top = FRAME_TOP_MARGIN_HEIGHT (f); As a consequence, the first call of resize_frame_windows (the one assigning new widths to windows) did set the top pixel edge of the frame's root window to the new value of the frame's top margin (the one after removing the tool bar). The second call of resize_frame_windows (the one assigning the new height values) was not executed because adjust_frame_size decided that (1) the overall height of the frame's windows did not change (which is obvious when removing scroll bars but also when removing the tool bar while a frame is created) and (2) the top pixel edge of the root window already had the right value. martin