From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#18136: 24.4.50; crash in redisplay when calling load-theme Date: Thu, 31 Jul 2014 20:55:11 +0300 Message-ID: <83d2cls9a8.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1406829387 24037 80.91.229.3 (31 Jul 2014 17:56:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 31 Jul 2014 17:56:27 +0000 (UTC) Cc: mvoteiza@udel.edu, 18136@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jul 31 19:56:20 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 1XCuaP-00077j-8f for geb-bug-gnu-emacs@m.gmane.org; Thu, 31 Jul 2014 19:56:17 +0200 Original-Received: from localhost ([::1]:58011 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XCuaO-0002oL-V9 for geb-bug-gnu-emacs@m.gmane.org; Thu, 31 Jul 2014 13:56:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55386) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XCuaG-0002nM-Pv for bug-gnu-emacs@gnu.org; Thu, 31 Jul 2014 13:56:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XCuaA-0006L4-IB for bug-gnu-emacs@gnu.org; Thu, 31 Jul 2014 13:56:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46277) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XCuaA-0006L0-FZ for bug-gnu-emacs@gnu.org; Thu, 31 Jul 2014 13:56:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XCua9-0002WY-PM for bug-gnu-emacs@gnu.org; Thu, 31 Jul 2014 13:56:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 31 Jul 2014 17:56: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.14068293019602 (code B ref 18136); Thu, 31 Jul 2014 17:56:01 +0000 Original-Received: (at 18136) by debbugs.gnu.org; 31 Jul 2014 17:55:01 +0000 Original-Received: from localhost ([127.0.0.1]:53220 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XCuZ9-0002Ug-DU for submit@debbugs.gnu.org; Thu, 31 Jul 2014 13:55:00 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:62825) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XCuZ6-0002UO-AK for 18136@debbugs.gnu.org; Thu, 31 Jul 2014 13:54:58 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0N9L00E007U7YY00@a-mtaout23.012.net.il> for 18136@debbugs.gnu.org; Thu, 31 Jul 2014 20:54:49 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N9L00E988FCWV50@a-mtaout23.012.net.il>; Thu, 31 Jul 2014 20:54:49 +0300 (IDT) In-reply-to: <53DA748D.4010201@gmx.at> X-012-Sender: halo1@inter.net.il 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:92009 Archived-At: > Date: Thu, 31 Jul 2014 18:53:33 +0200 > From: martin rudalics > CC: mvoteiza@udel.edu, 18136@debbugs.gnu.org > > >> 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? > > > > Yes. > > In the sense that the frame can get larger or smaller than the terminal > window? Yes. > So we internally work with say 100 frame lines although the > terminal can display only 80? 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. > >> 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? > > > > Allocate the glyph matrices, at the very least, I guess. > > OK. BTW doesn't adjust_frame_glyphs_for_frame_redisplay count the > menubar specially? It knows about it, yes: /* Add in menu bar lines, if any. */ matrix_dim.height += top_window_y; > >> 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? > > > > Maybe it shouldn't, when called from init_display. But we should at > > least leave an eassert there, in case we overlook something. > > Can I call adjust_frame_size directly from init_display? If all the rest is a no-op, yes, why not? > 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. > 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? > 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. > > 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? > BTW in an earlier mail you said that > > > E.g., with your suggested semantics, what would you expect from this: > > > > emacs -Q > > M-: (frame-height) RET > > M-x menu-bar-mode RET > > M-: (frame-height) RET > > > > Would you expect to see the 2 results of frame-height identical or > > different? > > > > The current trunk displays 2 identical results, and actually resizes > > the root window to be consistent with that, so that there's an unused > > empty line below the echo area. Is that intended? It looks like a > > misfeature to me. > > Where and how did you get that? I can't reproduce it here. 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. > >> Now please tell me one thing: Which calls of change_frame_size or > >> adjust_frame_size _should_ set FrameRows or FrameCols > > > > Any calls that actually change the frame size. > > Is turning off/on the TTY menubar one of them? No. > 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.