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: Fri, 01 Aug 2014 15:55:10 +0300 Message-ID: <8361ics72p.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> <83d2cls9a8.fsf@gnu.org> <53DB5662.8020909@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1406897785 23208 80.91.229.3 (1 Aug 2014 12:56:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 1 Aug 2014 12:56:25 +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 Fri Aug 01 14:56:17 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 1XDCNd-0000cs-4A for geb-bug-gnu-emacs@m.gmane.org; Fri, 01 Aug 2014 14:56:17 +0200 Original-Received: from localhost ([::1]:39013 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XDCNc-0002iu-FX for geb-bug-gnu-emacs@m.gmane.org; Fri, 01 Aug 2014 08:56:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33121) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XDCNU-0002hq-3R for bug-gnu-emacs@gnu.org; Fri, 01 Aug 2014 08:56:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XDCNP-00065o-BP for bug-gnu-emacs@gnu.org; Fri, 01 Aug 2014 08:56:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46804) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XDCNP-00065c-7w for bug-gnu-emacs@gnu.org; Fri, 01 Aug 2014 08:56:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XDCNO-0006pf-EG for bug-gnu-emacs@gnu.org; Fri, 01 Aug 2014 08:56:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 Aug 2014 12:56: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.140689772526215 (code B ref 18136); Fri, 01 Aug 2014 12:56:02 +0000 Original-Received: (at 18136) by debbugs.gnu.org; 1 Aug 2014 12:55:25 +0000 Original-Received: from localhost ([127.0.0.1]:53747 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XDCMl-0006oh-Gu for submit@debbugs.gnu.org; Fri, 01 Aug 2014 08:55:24 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:34981) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XDCMg-0006oJ-2U for 18136@debbugs.gnu.org; Fri, 01 Aug 2014 08:55:20 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0N9M00G00OG29G00@a-mtaout21.012.net.il> for 18136@debbugs.gnu.org; Fri, 01 Aug 2014 15:55:10 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N9M00GIEP7Y8850@a-mtaout21.012.net.il>; Fri, 01 Aug 2014 15:55:10 +0300 (IDT) In-reply-to: <53DB5662.8020909@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:92030 Archived-At: > Date: Fri, 01 Aug 2014 10:57:06 +0200 > From: martin rudalics > CC: mvoteiza@udel.edu, 18136@debbugs.gnu.org > > > 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. Which I'd expect, since resizing the terminal window is equivalent to resizing the TTY frames on that terminal. > > /* Add in menu bar lines, if any. */ > > matrix_dim.height += top_window_y; > > Doesn't this add an extra glyph row? Yes (if menu-bar-mode is turned on; otherwise top_window_y is zero). But, crucially, it does not update FrameRows for the frame's terminal. > >> 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? No, I mean if everything else does nothing, in which case you call adjust_frame_size already. Maybe I don't understand what bothers you in this scenario that caused you to ask that question. > >> 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. OK, and...? Both SIGWINCH and set-frame-size change the frame dimensions. The difference is that the former gets the new dimensions from get_tty_size, which queries the terminal driver, while the latter gets the dimensions from the caller. > >> 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. FrameCols/FrameRows communicates the terminal size to cursor-motion commands in cm.c. When we want to use a frame smaller than the terminal screen, we modify these values accordingly. > 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. IMO, FRAME_LINES for the TTY frame that is currently displayed on its terminal should always equal to FrameRows for that terminal (and similarly for FrameCols). I thought we previously agreed on this, since a TTY frame usually behaves as a maximized frame. > >> 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? No, it means the opposite: any change in dimensions of a TTY frame should be mirrored in 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'? Neither. FrameRows stands for the cm.c notion of the terminal's height. Its value can be modified either (1) by handle_window_change_signal, which queries the terminal via get_tty_size, or (2) by some Lisp that calls set-frame-size, which should eventually call adjust_frame_size.