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#18136: 24.4.50; crash in redisplay when calling load-theme Date: Thu, 31 Jul 2014 10:49:11 +0200 Message-ID: <53DA0307.6040004@gmx.at> References: <87d2cpxaq1.fsf@holos.localdomain> <8338dkh6wo.fsf@gnu.org> <53D77B06.8040907@gmx.at> <83tx60fjnh.fsf@gnu.org> <53D7A965.30700@gmx.at> <83mwbste5o.fsf@gnu.org> <53D7C0C4.7070406@gmx.at> <83iomgt9d2.fsf@gnu.org> <53D7E6B6.6070007@gmx.at> <83fvhkt3wm.fsf@gnu.org> <53D9210E.2030800@gmx.at> <8361ieu5nr.fsf@gnu.org> <53D92D00.7070600@gmx.at> <831tt2u428.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1406796632 14431 80.91.229.3 (31 Jul 2014 08:50:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 31 Jul 2014 08:50:32 +0000 (UTC) Cc: mvoteiza@udel.edu, 18136@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jul 31 10:50:24 2014 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 1XCm48-0004F6-72 for geb-bug-gnu-emacs@m.gmane.org; Thu, 31 Jul 2014 10:50:24 +0200 Original-Received: from localhost ([::1]:55023 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XCm47-0007tn-NR for geb-bug-gnu-emacs@m.gmane.org; Thu, 31 Jul 2014 04:50:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60714) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XCm3w-0007ll-9Q for bug-gnu-emacs@gnu.org; Thu, 31 Jul 2014 04:50:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XCm3n-00083o-RL for bug-gnu-emacs@gnu.org; Thu, 31 Jul 2014 04:50:12 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:45517) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XCm3n-00082k-No for bug-gnu-emacs@gnu.org; Thu, 31 Jul 2014 04:50:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XCm3m-0004p0-HD for bug-gnu-emacs@gnu.org; Thu, 31 Jul 2014 04:50: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: Thu, 31 Jul 2014 08:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18136 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 18136-submit@debbugs.gnu.org id=B18136.140679657418482 (code B ref 18136); Thu, 31 Jul 2014 08:50:02 +0000 Original-Received: (at 18136) by debbugs.gnu.org; 31 Jul 2014 08:49:34 +0000 Original-Received: from localhost ([127.0.0.1]:52457 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XCm3I-0004o1-VS for submit@debbugs.gnu.org; Thu, 31 Jul 2014 04:49:33 -0400 Original-Received: from mout.gmx.net ([212.227.15.19]:55460) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XCm3F-0004nl-9g for 18136@debbugs.gnu.org; Thu, 31 Jul 2014 04:49:30 -0400 Original-Received: from [62.46.214.118] ([62.46.214.118]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MMT1y-1X6khi2q1W-008G6m; Thu, 31 Jul 2014 10:49:20 +0200 In-Reply-To: <831tt2u428.fsf@gnu.org> X-Provags-ID: V03:K0:sBmGd2q2r5eDMW4Bu5UBEqMKpEFuWaznG31N3BhYuJGFOYit2BE 3e7NEbjRPajNvoP2q8M4SC9vD1pfY4FJRi7mFeCMKZgc0pu6sY0xNA4pSchMdJ4rTJfais7 mjysS7SXksL/9yFA1BQrW/nVKcndWcp/DUqzu6EDoaUQhqEVydZ7UTdnUY3BiTK96+fPtIQ Hcq7ROJr2nz6TMjA3SXTA== X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.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:91997 Archived-At: > I thought we agreed that TTY frames should include the menu bar in > their height, and therefore change_frame_size should not have its 3rd > argument decreased by FRAME_MENU_BAR_LINES for TTY frames. I'm afraid that doing so might run into problems in adjust_frame_size. Basically, the flow of things for turning on/off menubars should be as follows where "outer frame" stands for what Windows calls the client area and what on a TTY would stand for the screen space within a terminal window allotted to Emacs. (1) The user decides to enable/disable the menubar. The request is passed to adjust_frame_size. (2) adjust_frame_size (or better, frame_inhibit_resize) decides that we're on TTY and therefore the outer frame should _not_ be resized. Thus inhibit_horizontal and inhibit_vertical should be both true after frame_inhibit_resize has been called. This means that removing the menu bar must be handled internally by calling resize_frame_windows to either enlarge or shrink the root window by the menubar line. But I don't really understand about `set-frame-height' and friends on a TTY and what they are supposed to do. Should these be allowed to change the frame size? If not we should assure that inhibit_horizontal and inhibit_vertical are always true (regardless of the INHIBIT argument) on TTYs. Now about the change_frame_size (XFRAME (selected_frame), FrameCols (t->display_info.tty), FrameRows (t->display_info.tty) - FRAME_MENU_BAR_LINES (f), 0, 0, 1, 0); call in init_display. What precisely is this supposed to accomplish? Note one thing: change_frame_size is just a relay to detect whether applying (Emacs-)window changes and running Lisp is safe in the current state. If it is not, it simply waits. Otherwise, it passes all information to adjust_frame_size with INHIBIT set to 5 which means that the size of the outer frame has been set already and adjust_frame_size should only care about how to handle these sizes internally by resizing (Emacs-)windows appropriately. Now what does init_display? IIUC it just gets the height and width values from t->display_info.tty and passes them on to change_frame_size. That is, the outer frame sizes are set and adjust_frame_size has only to deal with resizing the (Emacs-)windows corectly. This is done by setting the new height of these windows from the height of the outer frame via new_windows_height = (new_pixel_height - FRAME_TOP_MARGIN_HEIGHT (f) - 2 * FRAME_INTERNAL_BORDER_WIDTH (f)); where new_pixel_height was earlier calculated from new_text_height as new_pixel_height = ((inhibit_vertical && (inhibit < 5)) ? old_pixel_height : max (FRAME_TEXT_TO_PIXEL_HEIGHT (f, new_text_height), min_windows_height + FRAME_TOP_MARGIN_HEIGHT (f) + 2 * FRAME_INTERNAL_BORDER_WIDTH (f))); where new_text_height is the normalized value passed to adjust_frame_size via the HEIGHT argument. This sounds contrived (why don't I call adjust_frame_size directly with the size of the outer frame?) but note that adjust_frame_size is more often called from inside Emacs and there we don't care about the outer frame (on GTK we certainly don't). Back to init_display and the question I asked earlier: Why should the subsequent adjust_frame_size call do if ((FRAME_TERMCAP_P (f) && !pretend) || FRAME_MSDOS_P (f)) FrameRows (FRAME_TTY (f)) = new_lines; here? IIUC this _has_ already been set correctly when calling change_frame_size and so should not be set here any more. Agreed? Now please tell me one thing: Which calls of change_frame_size or adjust_frame_size _should_ set FrameRows or FrameCols and how can I distinguish them? martin