From unknown Mon Aug 18 00:08:04 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#18136 <18136@debbugs.gnu.org> To: bug#18136 <18136@debbugs.gnu.org> Subject: Status: 24.4.50; crash in redisplay when calling load-theme Reply-To: bug#18136 <18136@debbugs.gnu.org> Date: Mon, 18 Aug 2025 07:08:04 +0000 retitle 18136 24.4.50; crash in redisplay when calling load-theme reassign 18136 emacs submitter 18136 Mark Oteiza severity 18136 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 28 20:36:44 2014 Received: (at submit) by debbugs.gnu.org; 29 Jul 2014 00:36:44 +0000 Received: from localhost ([127.0.0.1]:41451 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XBvPH-00051F-5o for submit@debbugs.gnu.org; Mon, 28 Jul 2014 20:36:44 -0400 Received: from eggs.gnu.org ([208.118.235.92]:48550) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XBvPF-000512-57 for submit@debbugs.gnu.org; Mon, 28 Jul 2014 20:36:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XBvP0-0003Rt-0J for submit@debbugs.gnu.org; Mon, 28 Jul 2014 20:36:35 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:47911) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XBvOz-0003Rp-T9 for submit@debbugs.gnu.org; Mon, 28 Jul 2014 20:36:25 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50260) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XBvOs-0005eB-5s for bug-gnu-emacs@gnu.org; Mon, 28 Jul 2014 20:36:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XBvOk-0003Qr-Kx for bug-gnu-emacs@gnu.org; Mon, 28 Jul 2014 20:36:18 -0400 Received: from mail-qa0-f41.google.com ([209.85.216.41]:57451) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XBvOk-0003Qj-G8 for bug-gnu-emacs@gnu.org; Mon, 28 Jul 2014 20:36:10 -0400 Received: by mail-qa0-f41.google.com with SMTP id j7so8601795qaq.0 for ; Mon, 28 Jul 2014 17:36:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-type; bh=Jvs0XLttto4oL4RM2h/rBc6RekvgDcdWo6V2p2dYFXI=; b=abubRpjNaVBGVFR8aPdNPYJeYUhfgBVhtncpLoctV/pj4VotMpl43cfuDLjt7pJbFb nnDPO4XcmFvslqPC3mJgSC6QGxO+Uq6jLvDC7Or78GyiiokcrCfqXeYMMUExn+jQI24x e7OL2LJVKRdKRBbUjp1NKPaWQDGrvgFiFTkpLPhcbCDUHRiJ9G3vm/0pPsu+r8FAKZsJ 5Sz15Pzz3F/OA7999G06um0RXnEUhwJVjSL1ostJ3Rn3Nfi6rDtlZV4NC9+R3fjjpwbb h8f6Mu3eikqHnOeWuDwTaaij0/6jU9fPjP9jXiyCavchNwqzKL8xae3d7h8KoreikrG3 ME1Q== X-Gm-Message-State: ALoCoQlbe2z+0LQFwFj3bvFXFeSAzqtxhi/ZatTVQ4/1vqcjl5erka6cjmD9LMDVY2ZGLZMOnK6B X-Received: by 10.140.44.67 with SMTP id f61mr66091209qga.44.1406594169607; Mon, 28 Jul 2014 17:36:09 -0700 (PDT) Received: from holos.localdomain (ip68-100-203-36.dc.dc.cox.net. [68.100.203.36]) by mx.google.com with ESMTPSA id 7sm24429008qgg.25.2014.07.28.17.36.08 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Jul 2014 17:36:09 -0700 (PDT) From: Mark Oteiza To: bug-gnu-emacs@gnu.org Subject: 24.4.50; crash in redisplay when calling load-theme Date: Mon, 28 Jul 2014 20:36:06 -0400 Message-ID: <87d2cpxaq1.fsf@holos.localdomain> MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) gdb emacs run -nw -Q M-x load-theme RET some-default-theme RET (gdb) xbacktrace al (C function)" (0xbbeea0) "redisplay_internal (C function)" (0xbbeea0) (gdb) bt #0 terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=40) at emacs.c:359 #1 0x00000000004fe2e3 in emacs_abort () at sysdep.c:2198 #2 0x00000000004a81c1 in cmcheckmagic (tty=0x13d82a0) at cm.c:120 #3 0x0000000000418225 in update_frame_line (f=f@entry=0xc0ab08, vpos=50) at dispnew.c:4839 #4 0x000000000041bb64 in update_frame_1 (f=f@entry=0xc0ab08, force_p=, force_p@entry=true, inhibit_id_p=inhibit_id_p@entry=false, set_cursor_p=set_cursor_p@entry=true) at dispnew.c:4509 #5 0x000000000041d11e in update_frame (f=0xc0ab08, force_p=, inhibit_hairy_id_p=) at dispnew.c:3110 #6 0x000000000044fccf in redisplay_internal () at xdisp.c:13869 #7 0x00000000004510a5 in redisplay () at xdisp.c:13115 #8 0x00000000004ef679 in read_char (commandflag=1, map=map@entry=19890598, prev_event=12545906, used_mouse_menu=used_mouse_menu@entry=0x7fffffffdb0b, end_time=end_time@entry=0x0) at keyboard.c:2560 #9 0x00000000004f0e05 in read_key_sequence (keybuf=keybuf@entry=0x7fffffffdbe0, prompt=12545906, dont_downcase_last=dont_downcase_last@entry=false, can_return_switch_frame=can_return_switch_frame@entry=true, fix_current_buffer=fix_current_buffer@entry=true, prevent_redisplay=prevent_redisplay@entry=false, bufsize=30) at keyboard.c:9120 #10 0x00000000004f2bb0 in command_loop_1 () at keyboard.c:1438 #11 0x00000000005570a7 in internal_condition_case (bfun=bfun@entry=0x4f29b0 , handlers=, hfun=hfun@entry=0x4e9960 ) at eval.c:1347 #12 0x00000000004e4eae in command_loop_2 (ignore=ignore@entry=12545906) at keyboard.c:1169 #13 0x0000000000556f8b in internal_catch (tag=12593330, func=func@entry=0x4e4e90 , arg=12545906) at eval.c:1111 #14 0x00000000004e9577 in command_loop () at keyboard.c:1148 #15 recursive_edit_1 () at keyboard.c:769 #16 0x00000000004e9890 in Frecursive_edit () at keyboard.c:840 #17 0x00000000004140f1 in main (argc=0, argv=0x7fffffffdf48) at emacs.c:1650 Lisp Backtrace: "redisplay_internal (C function)" (0xbbeea0) (gdb) In GNU Emacs 24.4.50.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw scroll bars) of 2014-07-28 on holos Configured using: `configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib --localstatedir=/var --with-x-toolkit=lucid 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4' CPPFLAGS=-D_FORTIFY_SOURCE=2 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro' Configured features: XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB Important settings: value of $LC_COLLATE: C value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Lisp Interaction Minor modes in effect: flycheck-mode: t company-mode: t winner-mode: t show-paren-mode: t tooltip-mode: t electric-indent-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t size-indication-mode: t column-number-mode: t line-number-mode: t Recent input: ESC [ > 8 4 ; 0 ; 0 c ESC x r e p o r t TAB RET Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. Load-path shadows: /usr/share/emacs/24.4.50/lisp/loaddefs hides /home/mvo/.emacs.d/site-lisp/loaddefs /usr/share/emacs/24.4.50/lisp/env hides /home/mvo/.emacs.d/site-lisp/expand-region/features/support/env Features: (shadow sort gnus-util mail-extr emacsbug message idna dired format-spec rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util help-fns mail-prsvr mail-utils xterm flycheck find-func help-mode easymenu rx f dash s company-files company-oddmuse company-keywords company-etags etags company-gtags company-dabbrev-code company-dabbrev company-capf company-cmake company-ropemacs company-xcode company-clang company-semantic company-eclim company-template company-css company-nxml company-bbdb company pcase easy-mmode cl-macs gv package windmove edmacro kmacro cl-loaddefs cl-lib saveplace winner ring time-date paren tooltip electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process dbusbind gfilenotify dynamic-setting system-font-setting font-render-setting x-toolkit x multi-tty emacs) Memory information: ((conses 16 126325 4289) (symbols 48 21390 0) (miscs 40 52 121) (strings 32 22506 4247) (string-bytes 1 610204) (vectors 16 10940) (vector-slots 8 372009 5422) (floats 8 89 369) (intervals 56 212 0) (buffers 976 11) (heap 1024 29754 891)) From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 29 05:05:06 2014 Received: (at 18136) by debbugs.gnu.org; 29 Jul 2014 09:05:06 +0000 Received: from localhost ([127.0.0.1]:41615 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XC3LF-0000Yw-G3 for submit@debbugs.gnu.org; Tue, 29 Jul 2014 05:05:05 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:59600) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XC3LA-0000Y0-TQ for 18136@debbugs.gnu.org; Tue, 29 Jul 2014 05:05:02 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0N9G00F00UITXM00@a-mtaout20.012.net.il> for 18136@debbugs.gnu.org; Tue, 29 Jul 2014 12:04:54 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N9G00FGYUK5RK50@a-mtaout20.012.net.il>; Tue, 29 Jul 2014 12:04:53 +0300 (IDT) Date: Tue, 29 Jul 2014 12:05:11 +0300 From: Eli Zaretskii Subject: Re: bug#18136: 24.4.50; crash in redisplay when calling load-theme In-reply-to: <87d2cpxaq1.fsf@holos.localdomain> X-012-Sender: halo1@inter.net.il To: Mark Oteiza , Martin Rudalics Message-id: <8338dkh6wo.fsf@gnu.org> References: <87d2cpxaq1.fsf@holos.localdomain> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18136 Cc: 18136@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Mark Oteiza > Date: Mon, 28 Jul 2014 20:36:06 -0400 > > > gdb emacs > run -nw -Q > > M-x load-theme RET some-default-theme RET > > (gdb) xbacktrace al (C function)" (0xbbeea0) > "redisplay_internal (C function)" (0xbbeea0) > (gdb) bt > #0 terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=40) at emacs.c:359 > #1 0x00000000004fe2e3 in emacs_abort () at sysdep.c:2198 > #2 0x00000000004a81c1 in cmcheckmagic (tty=0x13d82a0) at cm.c:120 > #3 0x0000000000418225 in update_frame_line (f=f@entry=0xc0ab08, vpos=50) at dispnew.c:4839 Martin, this is because of this change in the call to change_frame_size by init_display: @@ -6171,7 +6069,8 @@ init_display (void) t->display_info.tty->top_frame = selected_frame; change_frame_size (XFRAME (selected_frame), FrameCols (t->display_info.tty), - FrameRows (t->display_info.tty), 0, 0, 1, 0); + FrameRows (t->display_info.tty) + - FRAME_MENU_BAR_LINES (f), 0, 0, 1, 0); change_frame_size_1 then calls adjust_frame_size with the value one less than the terminal height, and adjust_frame_size plugs that value into FrameRows: if ((FRAME_TERMCAP_P (f) && !pretend) || FRAME_MSDOS_P (f)) FrameRows (FRAME_TTY (f)) = new_lines; This lies to Emacs about the terminal height, and cmcheckmagic catches that. I don't understand why you subtract FRAME_MENU_BAR_LINES, that sounds wrong at least for TTY frames. (We could add that back inside adjust_frame_size, but it's IMO a bad idea to spread this non-trivial logic between 2 functions.) From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 29 06:44:42 2014 Received: (at 18136) by debbugs.gnu.org; 29 Jul 2014 10:44:42 +0000 Received: from localhost ([127.0.0.1]:41656 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XC4td-00035V-Sy for submit@debbugs.gnu.org; Tue, 29 Jul 2014 06:44:42 -0400 Received: from mout.gmx.net ([212.227.15.18]:60347) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XC4tZ-00035C-0L for 18136@debbugs.gnu.org; Tue, 29 Jul 2014 06:44:38 -0400 Received: from [93.82.14.115] ([93.82.14.115]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MZkic-1WuxDG2HCo-00LXtJ; Tue, 29 Jul 2014 12:44:28 +0200 Message-ID: <53D77B06.8040907@gmx.at> Date: Tue, 29 Jul 2014 12:44:22 +0200 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii , Mark Oteiza Subject: Re: bug#18136: 24.4.50; crash in redisplay when calling load-theme References: <87d2cpxaq1.fsf@holos.localdomain> <8338dkh6wo.fsf@gnu.org> In-Reply-To: <8338dkh6wo.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:i1uVKkp8ne22F6IzEdjfQWq64lx9Hy9B7Rudr5J40uuvPN9DMC8 1+FyYsm6vxbnKnFCwbTwX9D3DvyPFJcqsU9RYygRWcwxgZ2uDauxha60H3M3TGusjS/4VJD NZ+orLbAZTMvGqFukymkJWSpsj376cLI+OKuhgkhPCslbX3UO3lNEPfJnul8qi/2A6rl5MD pirwP7LGNNiHRwijc7UTw== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 18136 Cc: 18136@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) >> (gdb) xbacktrace al (C function)" (0xbbeea0) >> "redisplay_internal (C function)" (0xbbeea0) >> (gdb) bt >> #0 terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=40) at emacs.c:359 >> #1 0x00000000004fe2e3 in emacs_abort () at sysdep.c:2198 >> #2 0x00000000004a81c1 in cmcheckmagic (tty=0x13d82a0) at cm.c:120 >> #3 0x0000000000418225 in update_frame_line (f=f@entry=0xc0ab08, vpos=50) at dispnew.c:4839 > > Martin, this is because of this change in the call to > change_frame_size by init_display: > > @@ -6171,7 +6069,8 @@ init_display (void) > t->display_info.tty->top_frame = selected_frame; > change_frame_size (XFRAME (selected_frame), > FrameCols (t->display_info.tty), > - FrameRows (t->display_info.tty), 0, 0, 1, 0); > + FrameRows (t->display_info.tty) > + - FRAME_MENU_BAR_LINES (f), 0, 0, 1, 0); > > change_frame_size_1 then calls adjust_frame_size with the value one > less than the terminal height, and adjust_frame_size plugs that value > into FrameRows: > > if ((FRAME_TERMCAP_P (f) && !pretend) || FRAME_MSDOS_P (f)) > FrameRows (FRAME_TTY (f)) = new_lines; > > This lies to Emacs about the terminal height, and cmcheckmagic catches > that. > > I don't understand why you subtract FRAME_MENU_BAR_LINES, that sounds > wrong at least for TTY frames. (We could add that back inside > adjust_frame_size, but it's IMO a bad idea to spread this non-trivial > logic between 2 functions.) All functions like change_frame_size or adjust_frame_size now expect the frame's text height as argument and menu and tool bars should not be part of it. I was expecting some breakage of this approach for TTY frames because I didn't fully understand the logic of how frames get assigned sizes. 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? martin From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 29 08:13:10 2014 Received: (at 18136) by debbugs.gnu.org; 29 Jul 2014 12:13:11 +0000 Received: from localhost ([127.0.0.1]:41736 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XC6HG-0007ed-Cm for submit@debbugs.gnu.org; Tue, 29 Jul 2014 08:13:10 -0400 Received: from mtaout27.012.net.il ([80.179.55.183]:46003) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XC6HD-0007e9-CI for 18136@debbugs.gnu.org; Tue, 29 Jul 2014 08:13:08 -0400 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0N9H00B002ZS3I00@mtaout27.012.net.il> for 18136@debbugs.gnu.org; Tue, 29 Jul 2014 15:07:55 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N9H006843172E50@mtaout27.012.net.il>; Tue, 29 Jul 2014 15:07:55 +0300 (IDT) Date: Tue, 29 Jul 2014 15:12:50 +0300 From: Eli Zaretskii Subject: Re: bug#18136: 24.4.50; crash in redisplay when calling load-theme In-reply-to: <53D77B06.8040907@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83tx60fjnh.fsf@gnu.org> References: <87d2cpxaq1.fsf@holos.localdomain> <8338dkh6wo.fsf@gnu.org> <53D77B06.8040907@gmx.at> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18136 Cc: mvoteiza@udel.edu, 18136@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 29 Jul 2014 12:44:22 +0200 > From: martin rudalics > CC: 18136@debbugs.gnu.org > > > I don't understand why you subtract FRAME_MENU_BAR_LINES, that sounds > > wrong at least for TTY frames. (We could add that back inside > > adjust_frame_size, but it's IMO a bad idea to spread this non-trivial > > logic between 2 functions.) > > All functions like change_frame_size or adjust_frame_size now expect the > frame's text height as argument and menu and tool bars should not be > part of it. 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. > I was expecting some breakage of this approach for TTY frames > because I didn't fully understand the logic of how frames get > assigned sizes. Please ask questions about what you don't understand. Having just completed a debugging session for bug #18112, which was all about assignment of TTY frame sizes, I think I can explain at least some of that. > 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. 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 29 10:02:41 2014 Received: (at 18136) by debbugs.gnu.org; 29 Jul 2014 14:02:41 +0000 Received: from localhost ([127.0.0.1]:42164 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XC7zA-0001xE-BM for submit@debbugs.gnu.org; Tue, 29 Jul 2014 10:02:40 -0400 Received: from mout.gmx.net ([212.227.17.21]:53951) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XC7z4-0001wt-I2 for 18136@debbugs.gnu.org; Tue, 29 Jul 2014 10:02:35 -0400 Received: from [62.46.213.117] ([62.46.213.117]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Mhej1-1WpOIw1jJD-00MtRk; Tue, 29 Jul 2014 16:02:21 +0200 Message-ID: <53D7A965.30700@gmx.at> Date: Tue, 29 Jul 2014 16:02:13 +0200 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#18136: 24.4.50; crash in redisplay when calling load-theme References: <87d2cpxaq1.fsf@holos.localdomain> <8338dkh6wo.fsf@gnu.org> <53D77B06.8040907@gmx.at> <83tx60fjnh.fsf@gnu.org> In-Reply-To: <83tx60fjnh.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Q8y5KnbZTVAhntiDLZT3pE2xjfDHIo/wBCPd39KTBRZZ6FXCTc9 N/4hBFx4UEUohNw/7U8ZD81VmjlpMA5b8VxuzudokpmPdO27RnW75DgXkkoY5OrETn6kiRi JhnimB0RkT9Uu2BjcQzYY4h704cyUKoZj1s6wsAeUFwJr1Ws1z53KQjlE1LGmQwwIOartoW v4GRkUV3SVELvWf7in1Sg== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 18136 Cc: mvoteiza@udel.edu, 18136@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > 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. > Please ask questions about what you don't understand. Having just > completed a debugging session for bug #18112, which was all about > assignment of TTY frame sizes, I think I can explain at least some of > that. > >> 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). > 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 and we shouldn't change them there. Or am I missing something? martin From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 29 10:47:48 2014 Received: (at 18136) by debbugs.gnu.org; 29 Jul 2014 14:47:48 +0000 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 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 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) 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) Date: Tue, 29 Jul 2014 17:47:47 +0300 From: Eli Zaretskii Subject: Re: bug#18136: 24.4.50; crash in redisplay when calling load-theme In-reply-to: <53D7A965.30700@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics 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> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18136 Cc: mvoteiza@udel.edu, 18136@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 29 11:42:21 2014 Received: (at 18136) by debbugs.gnu.org; 29 Jul 2014 15:42:21 +0000 Received: from localhost ([127.0.0.1]:42217 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XC9Xc-0004M6-1c for submit@debbugs.gnu.org; Tue, 29 Jul 2014 11:42:20 -0400 Received: from mout.gmx.net ([212.227.17.21]:60645) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XC9XV-0004Lm-65 for 18136@debbugs.gnu.org; Tue, 29 Jul 2014 11:42:14 -0400 Received: from [62.46.213.117] ([62.46.213.117]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MKt5A-1XC9XO2bIW-0001PY; Tue, 29 Jul 2014 17:42:02 +0200 Message-ID: <53D7C0C4.7070406@gmx.at> Date: Tue, 29 Jul 2014 17:41:56 +0200 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#18136: 24.4.50; crash in redisplay when calling load-theme 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> In-Reply-To: <83mwbste5o.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:qirJCoFT4leeJozGtQf6mm1NxMdW2o/vmYNeQE7sZVQRas/++Nu Lef/F/k/UJj4EmG+IaoKd8+Ytm/39mJlDg+8+WFf3mI/uCTLvDCY2HoLFzurygQAGSQx9q+ iprZwMvZh3Se+dT0Oa6vXnQcQuEid3h33a6EBZkJiAMbO8xymXl04PYbgu9Vo2ctWWQj41p SsGKZ+dA7d4+zIaJfYMFA== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 18136 Cc: mvoteiza@udel.edu, 18136@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > 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. The one use case I can think of is the following: Someone tries to do something special if a specific frame is not as high as needed for displaying some sort of text. In this case it would be nice to have a uniform behavior. But the point is rather moot since the object of reference in this regard is the window and the frame height also counts in the minibuffer and a modeline. So I have no strong feelings about this either. Note that this was an attempt to make the various toolkits behave more similar. But so far I failed in a number of aspects. For example, I was not able to keep the frame height constant when adding/removing the menubar in fullheight mode on a number of GUI builds. > 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? Ideally different in fullscreen/maximized/fullheight mode or with `frame-inhibit-implied-resize' non-nil, identical otherwise. > 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. My bad. For some reason I thought these were set in change_frame_size. Is calling change_frame_size necessary when switching frames? What a strange thing to do. martin From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 29 12:31:19 2014 Received: (at 18136) by debbugs.gnu.org; 29 Jul 2014 16:31:19 +0000 Received: from localhost ([127.0.0.1]:42229 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XCAJ1-0005Uz-MH for submit@debbugs.gnu.org; Tue, 29 Jul 2014 12:31:19 -0400 Received: from mtaout25.012.net.il ([80.179.55.181]:39806) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XCAIw-0005Ue-O6 for 18136@debbugs.gnu.org; Tue, 29 Jul 2014 12:31:14 -0400 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0N9H00B00EQFLJ00@mtaout25.012.net.il> for 18136@debbugs.gnu.org; Tue, 29 Jul 2014 19:26:23 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N9H00501EZYVR70@mtaout25.012.net.il>; Tue, 29 Jul 2014 19:26:23 +0300 (IDT) Date: Tue, 29 Jul 2014 19:31:21 +0300 From: Eli Zaretskii Subject: Re: bug#18136: 24.4.50; crash in redisplay when calling load-theme In-reply-to: <53D7C0C4.7070406@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83iomgt9d2.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> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18136 Cc: mvoteiza@udel.edu, 18136@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 29 Jul 2014 17:41:56 +0200 > From: martin rudalics > CC: mvoteiza@udel.edu, 18136@debbugs.gnu.org > > > 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? > > Ideally different in fullscreen/maximized/fullheight mode or with > `frame-inhibit-implied-resize' non-nil, identical otherwise. Shouldn't TTY frames behave as if they were fullscreen? That's what they (normally) are, right? > > 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. > > My bad. For some reason I thought these were set in change_frame_size. > Is calling change_frame_size necessary when switching frames? What a > strange thing to do. No, my bad, sorry. I confused this code with a similar one on do_switch_frame, which was added due to bug #17875. Obviously, do_switch_frame _is_ called when we switch frames. The code in change_frame_size_1 we are talking about was there since a very long time (I see it in Emacs 21), and its purpose is to update FrameRows and FrameCols when the user changes dimensions of a TTY frame (e.g., by calling set-frame-height). If you remove it, how can we update those attributes otherwise? From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 29 14:24:19 2014 Received: (at 18136) by debbugs.gnu.org; 29 Jul 2014 18:24:19 +0000 Received: from localhost ([127.0.0.1]:42275 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XCC4N-0008BW-34 for submit@debbugs.gnu.org; Tue, 29 Jul 2014 14:24:19 -0400 Received: from mout.gmx.net ([212.227.15.18]:61808) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XCC4G-0008BE-DL for 18136@debbugs.gnu.org; Tue, 29 Jul 2014 14:24:13 -0400 Received: from [93.82.10.169] ([93.82.10.169]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LvE2c-1WTP482x06-010MeU; Tue, 29 Jul 2014 20:23:58 +0200 Message-ID: <53D7E6B6.6070007@gmx.at> Date: Tue, 29 Jul 2014 20:23:50 +0200 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#18136: 24.4.50; crash in redisplay when calling load-theme 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> In-Reply-To: <83iomgt9d2.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:aCX4rxDwA2sbeWGqbIosJLPW4KTzbN/T041bRS3nMycFnM5V3Ty TIPhmqRETkiSzpMnFXgobrvWWalVbSVtAXAjufdJQDPGmi8xBEK7Jo5OJLewQPh2sxAG1HV 8m71ISPc+7Sq9aaQY3OVMNhnyMATcZr2fYrLFN7pRvV5PGSizZz5T9D//IMpb6B21R111EG VsVzr4D2jY3po6iOJ2caA== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 18136 Cc: mvoteiza@udel.edu, 18136@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > Shouldn't TTY frames behave as if they were fullscreen? That's what > they (normally) are, right? I think so, especially because that's how they behaved before. > The code in change_frame_size_1 we are talking about was there since a > very long time (I see it in Emacs 21), and its purpose is to update > FrameRows and FrameCols when the user changes dimensions of a TTY > frame (e.g., by calling set-frame-height). If you remove it, how can > we update those attributes otherwise? I wonder why this is done in this part of the code. Here we resize the windows of a frame but the frame's sizes remain unchanged. martin From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 29 14:29:11 2014 Received: (at 18136) by debbugs.gnu.org; 29 Jul 2014 18:29:12 +0000 Received: from localhost ([127.0.0.1]:42279 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XCC96-0008Ih-6q for submit@debbugs.gnu.org; Tue, 29 Jul 2014 14:29:11 -0400 Received: from mtaout26.012.net.il ([80.179.55.182]:39594) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XCC90-0008I9-RB for 18136@debbugs.gnu.org; Tue, 29 Jul 2014 14:29:06 -0400 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0N9H00E00K98W600@mtaout26.012.net.il> for 18136@debbugs.gnu.org; Tue, 29 Jul 2014 21:25:20 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N9H008OQKI83570@mtaout26.012.net.il>; Tue, 29 Jul 2014 21:25:20 +0300 (IDT) Date: Tue, 29 Jul 2014 21:29:13 +0300 From: Eli Zaretskii Subject: Re: bug#18136: 24.4.50; crash in redisplay when calling load-theme In-reply-to: <53D7E6B6.6070007@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83fvhkt3wm.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> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18136 Cc: mvoteiza@udel.edu, 18136@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 29 Jul 2014 20:23:50 +0200 > From: martin rudalics > CC: mvoteiza@udel.edu, 18136@debbugs.gnu.org > > > Shouldn't TTY frames behave as if they were fullscreen? That's what > > they (normally) are, right? > > I think so, especially because that's how they behaved before. If so, we agree, and this means the menu bar should be part of the TTY frame's dimensions. > > The code in change_frame_size_1 we are talking about was there since a > > very long time (I see it in Emacs 21), and its purpose is to update > > FrameRows and FrameCols when the user changes dimensions of a TTY > > frame (e.g., by calling set-frame-height). If you remove it, how can > > we update those attributes otherwise? > > I wonder why this is done in this part of the code. Here we resize the > windows of a frame but the frame's sizes remain unchanged. No, we resize the frame and then redistribute the frame dimensions between its windows. When change_frame_size_1 is called with the same dimensions as the current frame's dimensions, it simply does nothing and returns. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 30 12:45:22 2014 Received: (at 18136) by debbugs.gnu.org; 30 Jul 2014 16:45:22 +0000 Received: from localhost ([127.0.0.1]:52047 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XCX0D-0006hX-UK for submit@debbugs.gnu.org; Wed, 30 Jul 2014 12:45:22 -0400 Received: from mout.gmx.net ([212.227.17.20]:51905) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XCX0A-0006hI-JR for 18136@debbugs.gnu.org; Wed, 30 Jul 2014 12:45:19 -0400 Received: from [93.82.11.55] ([93.82.11.55]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MaE4a-1WsoIA2C0e-00Jtme; Wed, 30 Jul 2014 18:45:10 +0200 Message-ID: <53D9210E.2030800@gmx.at> Date: Wed, 30 Jul 2014 18:45:02 +0200 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#18136: 24.4.50; crash in redisplay when calling load-theme 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> In-Reply-To: <83fvhkt3wm.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:RnD1O/AwMv9/0u48OQnZ/Pm4ksHdLJyHOw5k+q87Z0KAl2fu0Wj s+tYBGm439ZG77/Z3Qs+Y/05IqRw3bb2htR+gSgmGKJQOQ8ZeDCfOJmj2V/DOyEKtOLJcIB pvQDLNCLgue757WiduYqxeiG367441M6SW1TtdblybfOyrHZMTvOjogRcuzAONCsIFswHcL CR0DVJWpNstzQQT5loNlA== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 18136 Cc: mvoteiza@udel.edu, 18136@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) >> I think so, especially because that's how they behaved before. > > If so, we agree, and this means the menu bar should be part of the TTY > frame's dimensions. Just that for a GUI frame the menubar is never counted in the text height. > No, we resize the frame and then redistribute the frame dimensions > between its windows. When change_frame_size_1 is called with the same > dimensions as the current frame's dimensions, it simply does nothing > and returns. change_frame_size_1 _always_ calls adjust_frame_size now. And the later does (almost) nothing only if the following condition holds: if (new_text_width == old_text_width && new_text_height == old_text_height && new_windows_width == old_windows_width && new_windows_height == old_windows_height && new_pixel_width == old_pixel_width && new_pixel_height == old_pixel_height) /* No change. Sanitize window sizes and return. */ martin From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 30 13:18:08 2014 Received: (at 18136) by debbugs.gnu.org; 30 Jul 2014 17:18:08 +0000 Received: from localhost ([127.0.0.1]:52060 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XCXVv-0007UG-FT for submit@debbugs.gnu.org; Wed, 30 Jul 2014 13:18:07 -0400 Received: from mtaout25.012.net.il ([80.179.55.181]:53778) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XCXVr-0007Tj-MQ for 18136@debbugs.gnu.org; Wed, 30 Jul 2014 13:18:05 -0400 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0N9J00300BQWYF00@mtaout25.012.net.il> for 18136@debbugs.gnu.org; Wed, 30 Jul 2014 20:13:17 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N9J003KRBU4O800@mtaout25.012.net.il>; Wed, 30 Jul 2014 20:13:16 +0300 (IDT) Date: Wed, 30 Jul 2014 20:18:16 +0300 From: Eli Zaretskii Subject: Re: bug#18136: 24.4.50; crash in redisplay when calling load-theme In-reply-to: <53D9210E.2030800@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <8361ieu5nr.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> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18136 Cc: mvoteiza@udel.edu, 18136@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Wed, 30 Jul 2014 18:45:02 +0200 > From: martin rudalics > CC: mvoteiza@udel.edu, 18136@debbugs.gnu.org > > >> I think so, especially because that's how they behaved before. > > > > If so, we agree, and this means the menu bar should be part of the TTY > > frame's dimensions. > > Just that for a GUI frame the menubar is never counted in the text > height. Yes, I agree. > > No, we resize the frame and then redistribute the frame dimensions > > between its windows. When change_frame_size_1 is called with the same > > dimensions as the current frame's dimensions, it simply does nothing > > and returns. > > change_frame_size_1 _always_ calls adjust_frame_size now. And the later > does (almost) nothing only if the following condition holds: > > if (new_text_width == old_text_width > && new_text_height == old_text_height > && new_windows_width == old_windows_width > && new_windows_height == old_windows_height > && new_pixel_width == old_pixel_width > && new_pixel_height == old_pixel_height) > /* No change. Sanitize window sizes and return. */ OK, but that's the moral equivalent of what I described (based on what the code did previously). Right? From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 30 13:36:18 2014 Received: (at 18136) by debbugs.gnu.org; 30 Jul 2014 17:36:18 +0000 Received: from localhost ([127.0.0.1]:52068 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XCXnV-0007vc-KN for submit@debbugs.gnu.org; Wed, 30 Jul 2014 13:36:17 -0400 Received: from mout.gmx.net ([212.227.17.20]:65164) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XCXnS-0007vO-Qf for 18136@debbugs.gnu.org; Wed, 30 Jul 2014 13:36:15 -0400 Received: from [93.82.11.55] ([93.82.11.55]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MWkZL-1WxSrk491v-00XqnN; Wed, 30 Jul 2014 19:36:08 +0200 Message-ID: <53D92D00.7070600@gmx.at> Date: Wed, 30 Jul 2014 19:36:00 +0200 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#18136: 24.4.50; crash in redisplay when calling load-theme 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> In-Reply-To: <8361ieu5nr.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Uo5LhXC/RsRRczqjOk2jhDfhR7VQp2yyMlKE1YNta6FLgqJyxpO jM0po3ZI46x1Aa/g00Dtf3ZcE/sCplGNzkQr2y6hFqTuSNMD2n9BTiw+cumLI2ewtk2/4y3 Ve4h+DXU64znzlqAuEJrg+x+o7TyzN1XpbaFgng/eX5JC8mabMygHf9ugGAnjOYinOyB2U6 weEwrboHPqV2CpCQC+KiA== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 18136 Cc: mvoteiza@udel.edu, 18136@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) >> > No, we resize the frame and then redistribute the frame dimensions >> > between its windows. When change_frame_size_1 is called with the same >> > dimensions as the current frame's dimensions, it simply does nothing >> > and returns. >> >> change_frame_size_1 _always_ calls adjust_frame_size now. And the later >> does (almost) nothing only if the following condition holds: >> >> if (new_text_width == old_text_width >> && new_text_height == old_text_height >> && new_windows_width == old_windows_width >> && new_windows_height == old_windows_height >> && new_pixel_width == old_pixel_width >> && new_pixel_height == old_pixel_height) >> /* No change. Sanitize window sizes and return. */ > > OK, but that's the moral equivalent of what I described (based on what > the code did previously). Right? I'm not good in morals but if I remove the menubar and the "frame dimensions" remain the same, the above conjunct does not hold because the new text height is larger than the old one and the new windows height too. martin From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 30 13:52:37 2014 Received: (at 18136) by debbugs.gnu.org; 30 Jul 2014 17:52:37 +0000 Received: from localhost ([127.0.0.1]:52076 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XCY3I-0008Jc-76 for submit@debbugs.gnu.org; Wed, 30 Jul 2014 13:52:36 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:60945) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XCY3F-0008JL-Fs for 18136@debbugs.gnu.org; Wed, 30 Jul 2014 13:52:34 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0N9J00400DMJAM00@a-mtaout22.012.net.il> for 18136@debbugs.gnu.org; Wed, 30 Jul 2014 20:52:27 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N9J004E8DNE7I10@a-mtaout22.012.net.il>; Wed, 30 Jul 2014 20:52:27 +0300 (IDT) Date: Wed, 30 Jul 2014 20:52:47 +0300 From: Eli Zaretskii Subject: Re: bug#18136: 24.4.50; crash in redisplay when calling load-theme In-reply-to: <53D92D00.7070600@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <831tt2u428.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> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18136 Cc: mvoteiza@udel.edu, 18136@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Wed, 30 Jul 2014 19:36:00 +0200 > From: martin rudalics > CC: mvoteiza@udel.edu, 18136@debbugs.gnu.org > > >> > No, we resize the frame and then redistribute the frame dimensions > >> > between its windows. When change_frame_size_1 is called with the same > >> > dimensions as the current frame's dimensions, it simply does nothing > >> > and returns. > >> > >> change_frame_size_1 _always_ calls adjust_frame_size now. And the later > >> does (almost) nothing only if the following condition holds: > >> > >> if (new_text_width == old_text_width > >> && new_text_height == old_text_height > >> && new_windows_width == old_windows_width > >> && new_windows_height == old_windows_height > >> && new_pixel_width == old_pixel_width > >> && new_pixel_height == old_pixel_height) > >> /* No change. Sanitize window sizes and return. */ > > > > OK, but that's the moral equivalent of what I described (based on what > > the code did previously). Right? > > I'm not good in morals but if I remove the menubar and the "frame > dimensions" remain the same, the above conjunct does not hold because the > new text height is larger than the old one and the new windows height too. 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 31 04:49:34 2014 Received: (at 18136) by debbugs.gnu.org; 31 Jul 2014 08:49:34 +0000 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 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 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 Message-ID: <53DA0307.6040004@gmx.at> Date: Thu, 31 Jul 2014 10:49:11 +0200 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#18136: 24.4.50; crash in redisplay when calling load-theme 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> In-Reply-To: <831tt2u428.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:sBmGd2q2r5eDMW4Bu5UBEqMKpEFuWaznG31N3BhYuJGFOYit2BE 3e7NEbjRPajNvoP2q8M4SC9vD1pfY4FJRi7mFeCMKZgc0pu6sY0xNA4pSchMdJ4rTJfais7 mjysS7SXksL/9yFA1BQrW/nVKcndWcp/DUqzu6EDoaUQhqEVydZ7UTdnUY3BiTK96+fPtIQ Hcq7ROJr2nz6TMjA3SXTA== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 18136 Cc: mvoteiza@udel.edu, 18136@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > 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 From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 31 06:52:31 2014 Received: (at 18136) by debbugs.gnu.org; 31 Jul 2014 10:52:31 +0000 Received: from localhost ([127.0.0.1]:52561 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XCnyI-0007sm-Ge for submit@debbugs.gnu.org; Thu, 31 Jul 2014 06:52:30 -0400 Received: from mtaout25.012.net.il ([80.179.55.181]:48158) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XCnyD-0007sS-VX for 18136@debbugs.gnu.org; Thu, 31 Jul 2014 06:52:27 -0400 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0N9K00A00OEDGU00@mtaout25.012.net.il> for 18136@debbugs.gnu.org; Thu, 31 Jul 2014 13:47:39 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N9K00BE2ONFGN00@mtaout25.012.net.il>; Thu, 31 Jul 2014 13:47:39 +0300 (IDT) Date: Thu, 31 Jul 2014 13:52:40 +0300 From: Eli Zaretskii Subject: Re: bug#18136: 24.4.50; crash in redisplay when calling load-theme In-reply-to: <53DA0307.6040004@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics Message-id: <83oaw5ssuf.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> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18136 Cc: mvoteiza@udel.edu, 18136@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Thu, 31 Jul 2014 10:49:11 +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. > 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. > 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. 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. > 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. > and how can I distinguish them? You already do, if I understand your description. You already avoid calling adjust_frame_size unless the size really changes. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 31 12:53:57 2014 Received: (at 18136) by debbugs.gnu.org; 31 Jul 2014 16:53:57 +0000 Received: from localhost ([127.0.0.1]:53193 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XCtc4-00011r-GF for submit@debbugs.gnu.org; Thu, 31 Jul 2014 12:53:57 -0400 Received: from mout.gmx.net ([212.227.17.20]:57874) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XCtc1-00011Z-KO for 18136@debbugs.gnu.org; Thu, 31 Jul 2014 12:53:54 -0400 Received: from [188.22.37.103] ([188.22.37.103]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M7DVi-1WIIZl2zf4-00x3aL; Thu, 31 Jul 2014 18:53:43 +0200 Message-ID: <53DA748D.4010201@gmx.at> Date: Thu, 31 Jul 2014 18:53:33 +0200 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#18136: 24.4.50; crash in redisplay when calling load-theme 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> In-Reply-To: <83oaw5ssuf.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Ykx0a/OWjLKt41mrHcHgg6DKcPtMu5Aq1muWL5Ub67jJrtY4EdD cS6KYRUZbH2NR9iO6IbH5NLzWQPFT1r5rjDufiF5tFCpUpkL8gqE10GTZzdbY+aIIXKQeH7 5tuMGNiAOjeYR3KMT2jtFCub0SbIDmmKf+H3OL7W75Cvm+xcSHdThXg8kMk81NEzpKt0r1O f4DMi1syN1tL7qWYoXk9A== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 18136 Cc: mvoteiza@udel.edu, 18136@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) >> 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? So we internally work with say 100 frame lines although the terminal can display only 80? Or am I missing something? >> 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? What is top_window_y = FRAME_TOP_MARGIN (f); for? >> 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? 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. Still it seems to me contrived to set FrameCols/FrameRows when adjusting the sizes of a frame's windows. And setting FrameCols when called from init_display is certainly not TRT IMHO. > 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. 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. >> 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? I think not. Yet we set FrameCols. Wouldn't it be principally cleaner if we set FrameCols and FrameRows after calling get_tty_size only? martin From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 31 13:55:01 2014 Received: (at 18136) by debbugs.gnu.org; 31 Jul 2014 17:55:01 +0000 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 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 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) 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) Date: Thu, 31 Jul 2014 20:55:11 +0300 From: Eli Zaretskii Subject: Re: bug#18136: 24.4.50; crash in redisplay when calling load-theme In-reply-to: <53DA748D.4010201@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics 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> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18136 Cc: mvoteiza@udel.edu, 18136@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 01 04:57:27 2014 Received: (at 18136) by debbugs.gnu.org; 1 Aug 2014 08:57:27 +0000 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 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 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 Message-ID: <53DB5662.8020909@gmx.at> Date: Fri, 01 Aug 2014 10:57:06 +0200 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#18136: 24.4.50; crash in redisplay when calling load-theme 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> In-Reply-To: <83d2cls9a8.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:p6g9A/pbgTgoLO15aT5t3kBK9dhbXr/IOhFeMGag0gHQ2vusXME dvCjgW7VzNpTBKMduyLjuVRiNbq7oVLsXrlWVAzrRpgFnYtrg4v2Cl3L+LJi6/jZN7obkQz u2gWAuPDtdXwpbvQT71qNi/V37RRFMOjHgMvTMUf5fuFHUO1mGVCquPkgVdOQmgO5jn11E9 v9/GBnRsP3ywWSzXlb4sg== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 18136 Cc: mvoteiza@udel.edu, 18136@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 01 08:55:25 2014 Received: (at 18136) by debbugs.gnu.org; 1 Aug 2014 12:55:25 +0000 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 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 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) 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) Date: Fri, 01 Aug 2014 15:55:10 +0300 From: Eli Zaretskii Subject: Re: bug#18136: 24.4.50; crash in redisplay when calling load-theme In-reply-to: <53DB5662.8020909@gmx.at> X-012-Sender: halo1@inter.net.il To: martin rudalics 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> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18136 Cc: mvoteiza@udel.edu, 18136@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > 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. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 04 13:23:23 2014 Received: (at 18136) by debbugs.gnu.org; 4 Aug 2014 17:23:23 +0000 Received: from localhost ([127.0.0.1]:57512 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XELyk-0000JH-P5 for submit@debbugs.gnu.org; Mon, 04 Aug 2014 13:23:23 -0400 Received: from mout.gmx.net ([212.227.15.15]:60128) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XELyh-0000J2-Pd for 18136@debbugs.gnu.org; Mon, 04 Aug 2014 13:23:20 -0400 Received: from [88.117.51.195] ([88.117.51.195]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MPlY2-1X9QI34A0A-004zBH; Mon, 04 Aug 2014 19:23:10 +0200 Message-ID: <53DFC179.1000306@gmx.at> Date: Mon, 04 Aug 2014 19:23:05 +0200 From: martin rudalics MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#18136: 24.4.50; crash in redisplay when calling load-theme 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> <8361ics72p.fsf@gnu.org> In-Reply-To: <8361ics72p.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:ZEvfBbIC3K1suifcA0CzHRzR7C/YlOVpDV/Zr0rJlR4+rwavwgL Ym1gniDNpulfhH1dJ3ZUy1k8O+PWP2zmFsHAdwKuAY7qjtk0AMdzM3cPhHU23XjXHfN8BnN d/iovNA5oDJ+StaLgb56gFZOU7AS34tlNB6++dUZEtZbdePUb5KiBCHoNAeVo6ERxNuar9C OESKnKt93OIVQaOKCaKsQ== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 18136 Cc: mvoteiza@udel.edu, 18136@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > 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. We agreed that the total (pixel) height of the frame should not change and the frame's windows should get resized when the menubar is turned off and on. But the problem is that you want that the frame's text height should not change either and this is much more difficult to achieve. In principle, I have to lie about the text height, for example, in this part of frame.c new_text_height = FRAME_PIXEL_TO_TEXT_HEIGHT (f, new_pixel_height); and I'm not yet sure how to do that :-( IIUC it amounts to changing FRAME_PIXEL_TO_TEXT_HEIGHT and FRAME_TEXT_TO_PIXEL_HEIGHT for TTYs but I'm afraid that that is not sufficient. In any case, the change will be substantial. martin From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 05 05:00:52 2014 Received: (at control) by debbugs.gnu.org; 5 Aug 2014 09:00:52 +0000 Received: from localhost ([127.0.0.1]:58257 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XEabz-0008R8-MI for submit@debbugs.gnu.org; Tue, 05 Aug 2014 05:00:51 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:59701 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XEabx-0008R0-L5 for control@debbugs.gnu.org; Tue, 05 Aug 2014 05:00:50 -0400 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1XEabx-0005Ko-1T for control@debbugs.gnu.org; Tue, 05 Aug 2014 05:00:49 -0400 Date: Tue, 05 Aug 2014 05:00:49 -0400 Message-Id: Subject: control message for bug 18196 To: X-Mailer: mail (GNU Mailutils 2.1) From: Glenn Morris X-Spam-Score: -5.7 (-----) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.7 (-----) merge 18136 18196 From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 13 11:57:20 2014 Received: (at control) by debbugs.gnu.org; 13 Aug 2014 15:57:20 +0000 Received: from localhost ([127.0.0.1]:42097 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XHavQ-0008LW-1M for submit@debbugs.gnu.org; Wed, 13 Aug 2014 11:57:20 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:40773 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XHavO-0008LN-6K for control@debbugs.gnu.org; Wed, 13 Aug 2014 11:57:19 -0400 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1XHavN-0007Es-He for control@debbugs.gnu.org; Wed, 13 Aug 2014 11:57:17 -0400 Date: Wed, 13 Aug 2014 11:57:17 -0400 Message-Id: Subject: control message for bug 18196 To: X-Mailer: mail (GNU Mailutils 2.1) From: Glenn Morris X-Spam-Score: -5.7 (-----) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.7 (-----) close 18196 From unknown Mon Aug 18 00:08:04 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 11 Sep 2014 11:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator