From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode Date: Mon, 14 Mar 2016 08:42:39 +0100 Message-ID: <56E66B6F.1050103@gmx.at> References: <4FF36A52-32D5-4AF3-A36E-621A57519C4F@raeburn.org> <83h9gen6yp.fsf@gnu.org> <83egbin5n9.fsf@gnu.org> <6D1E5FE8-518D-4433-8C11-7AF1C9D932ED@raeburn.org> <83oaaljdbb.fsf@gnu.org> <2AB9AB18-952B-4597-AB89-63D8F68D0434@raeburn.org> <83bn6kiypm.fsf@gnu.org> <8737rwyc07.fsf@linux-m68k.org> <83y49ohgha.fsf@gnu.org> <83d1r0ggmb.fsf@gnu.org> <56E55826.9010802@gmx.at> <8360wqfhqu.fsf@gnu.org> <56E5C8F6.2000909@gmx.at> <83fuvudsrf.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 1457941402 22573 80.91.229.3 (14 Mar 2016 07:43:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 14 Mar 2016 07:43:22 +0000 (UTC) Cc: 22975@debbugs.gnu.org, raeburn@raeburn.org, schwab@linux-m68k.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Mar 14 08:43:09 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1afN9g-0001Rd-3c for geb-bug-gnu-emacs@m.gmane.org; Mon, 14 Mar 2016 08:43:08 +0100 Original-Received: from localhost ([::1]:39458 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afN9f-00007X-BS for geb-bug-gnu-emacs@m.gmane.org; Mon, 14 Mar 2016 03:43:07 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52315) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afN9b-00007F-BO for bug-gnu-emacs@gnu.org; Mon, 14 Mar 2016 03:43:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1afN9a-0003Kd-Df for bug-gnu-emacs@gnu.org; Mon, 14 Mar 2016 03:43:03 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50255) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afN9a-0003KZ-AX for bug-gnu-emacs@gnu.org; Mon, 14 Mar 2016 03:43:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1afN9a-00041E-62 for bug-gnu-emacs@gnu.org; Mon, 14 Mar 2016 03:43: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: Mon, 14 Mar 2016 07:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22975 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22975-submit@debbugs.gnu.org id=B22975.145794137615420 (code B ref 22975); Mon, 14 Mar 2016 07:43:02 +0000 Original-Received: (at 22975) by debbugs.gnu.org; 14 Mar 2016 07:42:56 +0000 Original-Received: from localhost ([127.0.0.1]:47382 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1afN9U-00040e-7B for submit@debbugs.gnu.org; Mon, 14 Mar 2016 03:42:56 -0400 Original-Received: from mout.gmx.net ([212.227.17.20]:51191) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1afN9S-000408-3z for 22975@debbugs.gnu.org; Mon, 14 Mar 2016 03:42:54 -0400 Original-Received: from [192.168.1.100] ([212.95.7.73]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M5r89-1ZvWj10Ayf-00xtve; Mon, 14 Mar 2016 08:42:46 +0100 In-Reply-To: <83fuvudsrf.fsf@gnu.org> X-Provags-ID: V03:K0:zjbA6e29PTsZFtUhkFEIqdmUKg3jU9D9Dg6d2uPydWy03rsasFG Wr2bPQC4d23pju5TQUha8uZIc4obXLa9m51URQyWZmCDQ7bhRXsUI8tG+3jR13Jj6tHcpkG 2eAMb9C5lW6zktB+uqmOerOkpb2xQKMFA/Z1JgD4Xw8LCV5xTte6Qv2PqfpiDF8RcdRp6ox 88TgW7aJzICTu4J0T0JZA== X-UI-Out-Filterresults: notjunk:1;V01:K0:xzvVTmSmJ70=:LVRCSBCTjJQpZRLrlP3Lk8 VjnMd/5uF+Cp6QXWiqQXsy1aNwIDTRHqIPl9yADhaRUrBMzrSJWJzQvvbU0oTeAhvtQKaNDk0 jhcZPS2mxWUKuXAELS4cEAeh2kjYhyU/LRKnYLwsmn54K0FmY774kUeuwbaB5fEN/uzFNmbGq nZB/sunPR+4uLNYH1TyThpBNbRG7GZBnZ8i7eIVtt/qS2ngd6Cmz7Ce/6loJTr7mdMThC5gUu sPT0v6qCqwxykXQFg3/LdO7l8LDFK9fbHkKkfAGrnJpQKw5VEGT0DB9SIhtxXphkX4odJVBnR FO3oIIOewWwfrGQ8f0vMC5nIRl+NyB4mSMRIPqWI71r2T0Wb7HWWdsn0mKTypUsmCOX+4tE5z GsdhMCY8V79ebXsz8J99voFBE5/WCtwDawQPtxbY+vXBV4Kf46zqy/Jwr5DaFHouRM7IeoBd1 JgKt3X/V31HPAqmKdBOI88Cr8XguaAzYSt6IlqHnIGUKkdLvRpL5Hj73462jSm+g5d+EvkAo8 +wrAdRQLOms1fncIwfOjBD2mZu56A2pGl5AQ0TIwYGlG70ckAGMUYUdPSk8xCgVk+r9iRkc2V 84CoaEo2mWahG/d/opxPQsq1wNBz6IkfTDvWSFu6TaBb53rIa1G5xawAWIMYR62Jjbzvfh14E yzqPg3aJNzt6bT7w21VMyPytPMwnTAmZGVV4+MJ6D/Brkd13cgUS3/qBf5SrZrCQC1XtEEyzb NDPZzw4KxH5pIuKdC8w6I94ne7ZRVraJIMj1caUpnLyIi2AIdf0ahwkcn8fZzMuOXlDr10RI X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 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.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:114884 Archived-At: > But the return value might need to be something specific to steer the > rest of execution where we want it. For example, grow_mini_window > does this: > > if (delta > 0) > { > root = FRAME_ROOT_WINDOW (f); > r = XWINDOW (root); > height = call3 (Qwindow_resize_root_window_vertically, > root, make_number (- delta), pixelwise ? Qt : Qnil); > if (INTEGERP (height) && window_resize_check (r, false)) > { > block_input (); > window_resize_apply (r, false); > > which means we need the placeholder return nil to do what we want. If > it returns something else, who knows what will happen next? If it doesn't return an integer, this check if (INTEGERP (height) && window_resize_check (r, false)) will fail and nothing will happen. > IOW, we need to study the actual calls to know what to do in the > placeholders. The same examination could tell us how to avoid the > calls to those functions altogether. E.g., binding > resize-mini-windows to nil around the code that runs loadup.el would > prevent the call to grow_mini_window in the first place. Maybe that's > better, I didn't yet make up my mind. This would be probably better. Mine was just a proposal to work around the current situation without any definitive fix. martin