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: Tue, 06 Oct 2015 19:54:41 +0200 Message-ID: <56140AE1.2010502@gmx.at> References: <5613954A.2080804@yandex.ru> <5613A061.7030605@gmx.at> <83h9m4xd8v.fsf@gnu.org> 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 1444169003 4599 80.91.229.3 (6 Oct 2015 22:03:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 6 Oct 2015 22:03:23 +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 00:03:15 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 1ZjaKJ-0001aG-Er for ged-emacs-devel@m.gmane.org; Wed, 07 Oct 2015 00:03:15 +0200 Original-Received: from localhost ([::1]:54293 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjaKI-0004ws-WA for ged-emacs-devel@m.gmane.org; Tue, 06 Oct 2015 18:03:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42247) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjaK6-0004wk-Jb for emacs-devel@gnu.org; Tue, 06 Oct 2015 18:03:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZjaK3-00017h-Ia for emacs-devel@gnu.org; Tue, 06 Oct 2015 18:03:02 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:51241) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjWRq-0004yU-6n; Tue, 06 Oct 2015 13:54:46 -0400 Original-Received: from [188.22.40.180] ([188.22.40.180]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lp3Qu-1aDNYX1Loi-00esTP; Tue, 06 Oct 2015 19:54:45 +0200 In-Reply-To: <83h9m4xd8v.fsf@gnu.org> X-Provags-ID: V03:K0:nOhNs9VN8peikhBl00+E0s6qzeHr3uOR2MuGI8BOdH6Mfk5UEcP 726tj9o6sskyPJmFXQFdFwqdbmSft+TF3B6DvGnhYGRAOrr8uaWqYpB2FcS7B7nAjDCwKYP IGnilkBDQBBFffBbUHRNIzeTYB6KGk2SpUa2Lz4VSjFV5ey7O7v6YlukzYOF0J6XxpISQS/ rPoDyMb0ytMoRNB2S+0NA== X-UI-Out-Filterresults: notjunk:1;V01:K0:H9mfXu8PTkU=:tFoLdPU2VRi+vtkpu2D30R 83fOwkACRQ8EhcqARkFUECiURznyhKwRODJERZHTHidJF6LihYLWJZl6ocq195yAb5J7LjXMT XMfL27/NuuVHtSV+zP6hMO3FPotN7A0YCl1zJWR8CaBYo24GwlYN/ekan2KMA3E1V0ukokQ5h rd+2xARiN3kunfoOghXSM8+7XCoi+52ge219gwLXKBJi+t355HdDHrX8cjVNr7lRPCiSEAcg1 kFTTHpN+NAfR2WXDmBLVLOSwt62wPlr1xLLkRe1UK7KyaTGoZvqZrgN8T07c7gnUbQfnSrnjm c2OhqdBhGvoqR1DfcQnmkigamy2qrjV5rRk+EpeusRy0+GBo1lVowlajnLUvOh00hbwG+Q9uO AVcBCCpK1GtLnESbO5QKClHG+uSZZUxRexIXsJxva943ulm2fD+GmvqA+PQ6vlILobIoKuXmC 3J3Rr0pdEi2+4a9xDw226MBPvOYsPo1aJFqYYF4m1/RNm+pF8XLPr+AtjmEUoivZyqLLhhAtR ylGPJp4axsjvVHy+lag+4PDAVhXQJd3wSwnWb2CNTb24T7f8kCjo936xGwSh7bffivf4G/Hss Tkm3zlxRAd7piuYE0O8RWVlGOg4PU7RLqyYYooUk2Or4cjmfzCTVUg13o+LPxujsSMAwmrjSQ I7oRn1yrW5rP6QYvhIL3hAtgE7Umj89MQUa1l+E6FYoym1wLWJFq3VGwwk7kw0TUlHDFUqQhs JVL8/8K49dIE9YlT++B0ormhCB4fgh+2qkEW6RLSEv0bOdfWEB0gOWJj+yz7r9bPTGfrzXDU X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.17.22 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:191026 Archived-At: > My guess is that we don't call adjust_frame_size when the toolbar and > the scroll bar are removed, so no one tells the display engine that > the dimensions changed, and so the echo-area display is produced in a > glyph row that is now beyond the frame's lower end. This guess is > backed up by the fact that if I drag the frame's edge even one pixel, > the problem immediately goes away. Yes. The minibuffer should appear on line 34 but does so on line 35, hence it's virtually invisible. You can't guess that from looking at the screen - apparently everything has been drawn correctly. The root window and its mode line are both OK. > So I think we need to arrange to call adjust_frame_size from > x_set_frame_parameters, when the parameters in question affect the > frame's dimensions. 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. martin