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: Tue, 29 Jul 2014 17:47:47 +0300 Message-ID: <83mwbste5o.fsf@gnu.org> References: <87d2cpxaq1.fsf@holos.localdomain> <8338dkh6wo.fsf@gnu.org> <53D77B06.8040907@gmx.at> <83tx60fjnh.fsf@gnu.org> <53D7A965.30700@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1406645306 22944 80.91.229.3 (29 Jul 2014 14:48:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Jul 2014 14:48:26 +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 Tue Jul 29 16:48:18 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 1XC8hM-00063o-Sj for geb-bug-gnu-emacs@m.gmane.org; Tue, 29 Jul 2014 16:48:17 +0200 Original-Received: from localhost ([::1]:46419 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XC8hM-0008Ov-Ie for geb-bug-gnu-emacs@m.gmane.org; Tue, 29 Jul 2014 10:48:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42376) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XC8hD-0008J5-Ue for bug-gnu-emacs@gnu.org; Tue, 29 Jul 2014 10:48:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XC8h8-0002aT-Rn for bug-gnu-emacs@gnu.org; Tue, 29 Jul 2014 10:48:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46930) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XC8h8-0002aJ-Oa for bug-gnu-emacs@gnu.org; Tue, 29 Jul 2014 10:48:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XC8h8-00034L-76 for bug-gnu-emacs@gnu.org; Tue, 29 Jul 2014 10:48: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: Tue, 29 Jul 2014 14:48: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.140664526811774 (code B ref 18136); Tue, 29 Jul 2014 14:48:02 +0000 Original-Received: (at 18136) by debbugs.gnu.org; 29 Jul 2014 14:47:48 +0000 Original-Received: from localhost ([127.0.0.1]:42196 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XC8gq-00033n-6a for submit@debbugs.gnu.org; Tue, 29 Jul 2014 10:47:47 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:34143) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XC8gj-00033T-Q5 for 18136@debbugs.gnu.org; Tue, 29 Jul 2014 10:47:41 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0N9H00B00ADIS500@a-mtaout22.012.net.il> for 18136@debbugs.gnu.org; Tue, 29 Jul 2014 17:47:31 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N9H00A3HAF6UQC0@a-mtaout22.012.net.il>; Tue, 29 Jul 2014 17:47:31 +0300 (IDT) In-reply-to: <53D7A965.30700@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:91945 Archived-At: > Date: Tue, 29 Jul 2014 16:02:13 +0200 > From: martin rudalics > CC: mvoteiza@udel.edu, 18136@debbugs.gnu.org > > > Why does it make sense to do that for TTY frames? The terminal screen > > cannot be resized from within Emacs, so the arguments for treating the > > menu bar as an add-on are not really valid in this case. > > The idea is that `frame-height' should have the same semantics on all > platforms. If you think we can ignore this difference for TTY frames > I'm obviously OK with it. I don't have strong feelings about it, and will probably adapt if we stay with this semantics. But it feels strange, as on a TTY the menu bar is a line just like any other line, and when the menu bar is not displayed, I'd expect that line to be used for text. 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. > >> Probably this assignment > >> > >> if ((FRAME_TERMCAP_P (f) && !pretend) || FRAME_MSDOS_P (f)) > >> FrameCols (FRAME_TTY (f)) = new_cols; > >> > >> is completely misplaced and should be either removed or inhibited when > >> called from change_frame_size_1, that is when INHIBIT equals 5. Can you > >> tell me what this assignment is for? > > > > It cannot be removed or inhibited. > > Inhibited exclusively for the case that this function is called from > change_frame_size (that is when INHIBIT equals 5). You can't: this case is _precisely_ the case where we do need to update FrameCols and FrameRows. > > It was introduced to fix a bug > > (#17875). The problem is that different TTY frames on the same > > terminal can potentially have different dimensions, and OTOH FrameCols > > and FrameRows are "normally" set only at terminal initiation and in > > response to a SIGWINCH signal. These assignments take care of keeping > > FrameCols and FrameRows in sync with frame dimensions in all other > > cases, because they all go through change_frame_size. > > Which means FrameCols and FrameRows always have the correct values when > entering adjust_frame_size No, they don't, at least not necessarily. If they did, what would be the point of adding that to fix the bug? Again, FrameRows and FrameCols updates are triggered in 3 possible ways: . when the terminal is created . when we get SIGWINCH . when we call change_frame_size The last one was missing, which caused bug #17875, whereby switching to a different frame on the same terminal failed to update FrameRows and FrameCols, because neither of the first 2 triggers happened.