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: Fri, 01 Aug 2014 10:57:06 +0200 Message-ID: <53DB5662.8020909@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> <53DA0307.6040004@gmx.at> <83oaw5ssuf.fsf@gnu.org> <53DA748D.4010201@gmx.at> <83d2cls9a8.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 1406883514 9149 80.91.229.3 (1 Aug 2014 08:58:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 1 Aug 2014 08:58:34 +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 Fri Aug 01 10:58:26 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 1XD8fR-0003EX-Ls for geb-bug-gnu-emacs@m.gmane.org; Fri, 01 Aug 2014 10:58:25 +0200 Original-Received: from localhost ([::1]:60524 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XD8fR-0005PR-D5 for geb-bug-gnu-emacs@m.gmane.org; Fri, 01 Aug 2014 04:58:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33238) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XD8fC-0005GX-Dt for bug-gnu-emacs@gnu.org; Fri, 01 Aug 2014 04:58:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XD8f4-0003Os-Rf for bug-gnu-emacs@gnu.org; Fri, 01 Aug 2014 04:58:10 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46684) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XD8f4-0003Oo-O6 for bug-gnu-emacs@gnu.org; Fri, 01 Aug 2014 04:58:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XD8f4-0007zP-6O for bug-gnu-emacs@gnu.org; Fri, 01 Aug 2014 04:58: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: Fri, 01 Aug 2014 08:58:01 +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.140688344730649 (code B ref 18136); Fri, 01 Aug 2014 08:58:01 +0000 Original-Received: (at 18136) by debbugs.gnu.org; 1 Aug 2014 08:57:27 +0000 Original-Received: from localhost ([127.0.0.1]:53624 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XD8eU-0007yG-Ay for submit@debbugs.gnu.org; Fri, 01 Aug 2014 04:57:26 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:53341) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XD8eS-0007y0-8I for 18136@debbugs.gnu.org; Fri, 01 Aug 2014 04:57:25 -0400 Original-Received: from [194.118.142.230] ([194.118.142.230]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MbaS9-1WwIBd465N-00J47e; Fri, 01 Aug 2014 10:57:17 +0200 In-Reply-To: <83d2cls9a8.fsf@gnu.org> X-Provags-ID: V03:K0:p6g9A/pbgTgoLO15aT5t3kBK9dhbXr/IOhFeMGag0gHQ2vusXME dvCjgW7VzNpTBKMduyLjuVRiNbq7oVLsXrlWVAzrRpgFnYtrg4v2Cl3L+LJi6/jZN7obkQz u2gWAuPDtdXwpbvQT71qNi/V37RRFMOjHgMvTMUf5fuFHUO1mGVCquPkgVdOQmgO5jn11E9 v9/GBnRsP3ywWSzXlb4sg== 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:92024 Archived-At: > That will not work well (you can try and see yourself). But the > opposite, i.e. having a 80-line frame on a 100-line terminal, is quite > usable. In fact, some people seem to use that to have minibuffer-only > frames on a TTY. Weird. Such setting gets lost immediately when the terminal window is resized. > /* Add in menu bar lines, if any. */ > matrix_dim.height += top_window_y; Doesn't this add an extra glyph row? >> Can I call adjust_frame_size directly from init_display? > > If all the rest is a no-op, yes, why not? You mean it must not call Lisp? >> IIUC FrameRows is the height of the terminal window and when I change >> the height of that window I want to change the height of the Emacs frame >> as well via handle_window_change_signal/change_frame_size. This means I >> can set FrameCols where I do it now because whenever I change the size >> of the outer frame that of the frame's windows changes too. > > Sorry, you lost me here. First, you use "window" in several > overloaded meanings, or so it seems. And second, why are we suddenly > talking about SIGWINCH and its handling? This is not the scenario in > which this bug happens. Because adjust_frame_size has to handle SIGWINCH as well. >> Still it seems to me contrived to set FrameCols/FrameRows when adjusting >> the sizes of a frame's windows. > > How else will FrameCols/FrameRows be updated if the user calls > set-frame-size and its ilk? I thought that FrameCols/FrameRows store the sizes of the terminal window. IIUC this means that `set-frame-size' makes us lie about the terminal sizes. >> And setting FrameCols when called from init_display is certainly not >> TRT IMHO. > > If you are sure they are already set by then, OK. Evidently, in this > case, the call to change_frame_size tried to decrease the frame size > by one line, so something is still out of sync somewhere. Obviously. >> > In any case, this begs the question: why do you at all call >> > adjust_frame_size in this case, if the frame already has the required >> > size? I think the answer is that adjust_frame_size does something >> > else: it calls adjust_frame_glyphs. That call is required at >> > init_display time for obvious reasons, but it is inside >> > adjust_frame_size which is only called when the frame size changes, >> > which sounds like a contradiction in the design. >> >> Think of turning off/on the menubar of a maximized frame. In this case >> I do not change the size of the frame either. Yet I have to call >> adjust_frame_glyphs. > > Is that supposed to be the answer to my question, or just say what I > said in other words? A complement to what you said. > I can reproduce it with the current trunk on GNU/Linux where I invoke > "emacs -Q -nw" via PuTTY. The resize is _after_ I invoke frame-height > the second time, which is already the sign of a problem. Unfortunately, restoring the init_display change as you proposed earlier by simply doing === modified file 'src/dispnew.c' --- src/dispnew.c 2014-07-28 09:39:09 +0000 +++ src/dispnew.c 2014-08-01 08:23:58 +0000 @@ -6069,8 +6069,7 @@ t->display_info.tty->top_frame = selected_frame; 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); + FrameRows (t->display_info.tty), 0, 0, 1, 0); /* Delete the initial terminal. */ if (--initial_terminal->reference_count == 0 doesn't remove the cmcheckmagic abort here. IUUC the problem is with the deliberate mixture of frame and terminal sizes when using cursor coordinates within term.c, like && curY (tty) == FrameRows (tty) - 1 and && curY (tty) + 1 == FRAME_LINES (f) So far this can have worked only by some strange magic assuring that FRAME_LINES always returns the same value as FrameRows. >> Wouldn't it be principally cleaner if we set FrameCols and FrameRows >> after calling get_tty_size only? > > You can't. get_tty_size reports the _physical_ dimensions of the > terminal screen, so it cannot support set-frame-size and its ilk, > which leave the physical dimensions unaltered. Does that mean `set-frame-size' should not set FrameCols/FrameRows? I'm still too silly to understand this: Please tell me whether FrameRows stands for the height of the terminal window as reported by get_tty_size or for the height of the frame as set by `set-frame-size'? martin