From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Clemente Newsgroups: gmane.emacs.bugs Subject: bug#71343: 30.0.50; TTY frame doesn't automatically redisplay itself after having closed another frame Date: Fri, 21 Jun 2024 10:47:07 +0000 Message-ID: References: <86o78egucl.fsf@gnu.org> <86cyougp9b.fsf@gnu.org> <86o781s8gt.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15648"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eggert@cs.ucla.edu, 71343@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jun 21 18:34:28 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sKhDX-0003uq-E6 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 21 Jun 2024 18:34:27 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sKhDA-0006a9-FD; Fri, 21 Jun 2024 12:34:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sKhD9-0006WN-2f for bug-gnu-emacs@gnu.org; Fri, 21 Jun 2024 12:34:03 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sKhD8-0006B7-Pz for bug-gnu-emacs@gnu.org; Fri, 21 Jun 2024 12:34:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sKhD8-0000rb-0j for bug-gnu-emacs@gnu.org; Fri, 21 Jun 2024 12:34:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Clemente Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 21 Jun 2024 16:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 71343 X-GNU-PR-Package: emacs Original-Received: via spool by 71343-submit@debbugs.gnu.org id=B71343.17189875833253 (code B ref 71343); Fri, 21 Jun 2024 16:34:01 +0000 Original-Received: (at 71343) by debbugs.gnu.org; 21 Jun 2024 16:33:03 +0000 Original-Received: from localhost ([127.0.0.1]:43177 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sKhCA-0000q7-8m for submit@debbugs.gnu.org; Fri, 21 Jun 2024 12:33:02 -0400 Original-Received: from mail-pf1-f173.google.com ([209.85.210.173]:49467) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sKhC8-0000pl-EV for 71343@debbugs.gnu.org; Fri, 21 Jun 2024 12:33:01 -0400 Original-Received: by mail-pf1-f173.google.com with SMTP id d2e1a72fcca58-7023b6d810bso1706162b3a.3 for <71343@debbugs.gnu.org>; Fri, 21 Jun 2024 09:33:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718987515; x=1719592315; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=1ZL+zDTEhDPH7bSrRoaOTwD1FDW5yY1T77/0YwELdeM=; b=PvUST/ymDLGfl5lquSvnO53c0G2NJZZ97X40FMD2IAKj/R2Dl7WGvLY4Lp3rV3m3Wz dzm6zFt8l6KmNNMErCPTJ9uCa8fIHK3sL2/lry1Rw58IZv1eax8X5mxNXJ9zCp1x8naW IvKnLy/h5BWyJYgVdk5U7Im5w7LV3/XHroS+7oQF00j4lpVMIB2lLowc+lndYiaNQ7x4 klfFVWLlFm8dCc9WQP8cNztzxMsMdtix5ojrRt85FGm9mKPvIiv7PupbRt2o1w1qUF/2 TaaQHYDrMv9w+XCyQqKBGjThjpUdU7ro94e/CaE8ZF3n9se3/kVLk35T5Z8+GQJj1lTS 0MtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718987515; x=1719592315; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=1ZL+zDTEhDPH7bSrRoaOTwD1FDW5yY1T77/0YwELdeM=; b=DwVthfXxzg09yUSFh3Edi1opP2B4WHTg73mwlSaKWr4hV8lr15fCSYwykXUuL1KXRY 6/JKcgh/v1ldfN7Pbm8eJEIKK+eoSEfmIFwWSyD1ytjXqejjDB8sI+ssdcXdmYrNTHYb i8O/+VTP+pcjXF4crsyPGTvQzDtXL/1sR5O008i/Ksv4DqECX2juzJcTza02Cre4CWp3 Hrq/Wg+HDoV6lYNrTqO6i1NkbHvACmgOKBWtJl6CmWagCnJf73V/7OMeycofamH+sx0T Qd8BYBDhwyE8odqm4ZnMTNXExepGRVrXEj9kuEpcDa6oVw7ELLXkjSFf7PhMBsZx8Pc0 CcaA== X-Forwarded-Encrypted: i=1; AJvYcCWTGqWSSOyD35V+dQDT3DbPLdFIPG5nSq2YjfPgjUtboCBRyzGWLaTcs/dCu/cjJYDWOXamJJyQIUtIM2g4CVreVUmARc8= X-Gm-Message-State: AOJu0Yygggm4Pw1lYTyn8av0+2/BoK60T/GDTlDu+ocLCdhPwr5yz4xx 49tOHiwBxfTKuaG6pF0XBwTQKnTrlUDvs2oyxfBkRmdrJ6cFHYdPnI9TSkAX5898A53qghNXs90 Lor4hkuz6fLCo68gvjpE234SBn60taTzY X-Google-Smtp-Source: AGHT+IEAq5BPbo5734GbL2A0n5l7l8uYs4gtEspBExugrCUaPSHpAhLldnSvZbuYwVvxSwWPg1+fgAj3GaXG05dqlOg= X-Received: by 2002:a67:f347:0:b0:48f:3c3b:6a39 with SMTP id ada2fe7eead31-48f3c3b6bb8mr541107137.11.1718966855833; Fri, 21 Jun 2024 03:47:35 -0700 (PDT) In-Reply-To: <86o781s8gt.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:287621 Archived-At: > Emacs doesn't really talk to the terminal emulator, unless the > emulator supports known protocols of doing so. You will see in > lisp/term/xterm.el that Emacs supports that for xterm that is new > enough. Don't know what happens with urxvt, but did you try using > xterm and saw the same problems? I tried with xterm and I don't see the same problem. There's more flickering and slowness but the frame I'm resizing gets redrawn. I'm using: xterm -e "emasclient" "-c" & I just installed other terminals: mlterm, cool-retro-term, Eterm. They show the problem, just like urxvt. The frame being resized (just after closing another frame) isn't redrawn. To simplify testing I'm using for i in `seq 2`; do mlterm -e "emacsclient" "-c" "-e" '(dired "~")' & sleep 1; done and closing the second one and resizing the first one.. I also saw 2 other SIGSEGV with xterm and others, that show possibly corrupted memory. I reported them as separate bugs but I don't know whether they're related to this one. > > > > > - What if, when resizing the frame (something which Emacs detects), > > > > Emacs knows/detects that a frame was closed, and decides not to del= ay > > > > the redisplay? > > > > > > Redisplay of which frame? Emacs only redisplays a frame if some > > > change in buffer text justifies that. > > > > I propose it should repaint/redisplay the frame whose size changed. > > When a frame is resized, it is redisplayed, yes. But that requires > Emacs to know that it is resized. > > > Don't we know which frame is the one being resized? It should be f in > > adjust_frame_size. It realizes that e.g. it's being resized from 72 to > > 61 columns. > > I need a backtrace showing the call to adjust_frame_size, of a frame > that is not redrawn. I don't think I saw such a backtrace. In this one, I made a frame less wide (it was around 70 columns, I made it 60 columns) in the conditions when redraw doesn't happen. Breakpoint 2, adjust_frame_size (f=3D0x6210000ede00, new_text_width=3D60, new_text_height=3D49, inhibit=3D5, pretend=3Dfalse, parameter=3DXIL(0x4= 0e0)) at frame.c:646 646 int unit_width =3D FRAME_COLUMN_WIDTH (f); (gdb) bt #0 adjust_frame_size (f=3D0x6210000ede00, new_text_width=3D60, new_text_height=3D49, inhibit=3D5, pretend=3Dfalse, parameter=3DXIL(0x4= 0e0)) at frame.c:646 #1 0x00005555564e04c3 in change_frame_size_1 (f=3D0x6210000ede00, new_width=3D60, new_height=3D50, pretend=3Dfalse, delay=3Dfalse, safe= =3Dfalse) at dispnew.c:6054 #2 0x00005555564e0526 in change_frame_size (f=3D0x6210000ede00, new_width=3D60, new_height=3D50, pretend=3Dfalse, delay=3Dfalse, safe= =3Dfalse) at dispnew.c:6087 #3 0x00005555564df618 in do_pending_window_change (safe=3Dfalse) at dispnew.c:6014 #4 0x0000555556e479ee in wait_reading_process_output (time_limit=3D0, nsecs=3D0, read_kbd=3D-1, do_display=3Dtrue, wait_for_cell=3DXIL(0), wait_proc=3D0x0, just_wait_proc=3D0) at process.c:5784 #5 0x00005555569b57da in kbd_buffer_get_event (kbp=3D0x7fffffffca50, used_mouse_menu=3D0x7fffffffd4f0, end_time=3D0x0) at keyboard.c:4079 #6 0x00005555569a6c45 in read_event_from_main_queue (end_time=3D0x0, local_getcjmp=3D0x7fffffffd110, used_mouse_menu=3D0x7fffffffd4f0) at keyboard.c:2330 #7 0x00005555569a75b1 in read_decoded_event_from_main_queue ( end_time=3D0x0, local_getcjmp=3D0x7fffffffd110, prev_event=3DXIL(0), used_mouse_menu=3D0x7fffffffd4f0) at keyboard.c:2394 #8 0x00005555569adaa6 in read_char (commandflag=3D1, map=3DXIL(0x7fffec72ab93), prev_event=3DXIL(0), used_mouse_menu=3D0x7fffffffd4f0, end_time=3D0x0) at keyboard.c:3015 #9 0x00005555569e9ca2 in read_key_sequence (keybuf=3D0x7fffffffd7e0, prompt=3DXIL(0), dont_downcase_last=3Dfalse, can_return_switch_frame=3Dtrue, fix_current_buffer=3Dtrue, prevent_redisplay=3Dfalse, disable_text_conversion_p=3Dfalse) at keyboard.c:10728 --Type for more, q to quit, c to continue without paging-- #10 0x000055555699b122 in command_loop_1 () at keyboard.c:1429 #11 0x0000555556cbb678 in internal_condition_case ( bfun=3D0x55555699a22d , handlers=3DXIL(0x90), hfun=3D0x555556998204 ) at eval.c:1613 #12 0x0000555556999797 in command_loop_2 (handlers=3DXIL(0x90)) at keyboard.c:1168 #13 0x0000555556cb84d8 in internal_catch (tag=3DXIL(0xfb40), func=3D0x555556999767 , arg=3DXIL(0x90)) at eval.c:1292 #14 0x000055555699969a in command_loop () at keyboard.c:1146 #15 0x0000555556996e7a in recursive_edit_1 () at keyboard.c:754 #16 0x0000555556997531 in Frecursive_edit () at keyboard.c:837 #17 0x0000555556989057 in main (argc=3D3, argv=3D0x7fffffffdee8) at emacs.c:2629 (gdb) bt full #0 adjust_frame_size (f=3D0x6210000ede00, new_text_width=3D60, new_text_height=3D49, inhibit=3D5, pretend=3Dfalse, parameter=3DXIL(0x4= 0e0)) at frame.c:646 unit_width =3D 1458155539 unit_height =3D 21845 old_native_width =3D 1492352256 old_native_height =3D 21845 new_native_width =3D 0 new_native_height =3D 0 min_inner_width =3D -1 min_inner_height =3D -1 r =3D 0x7ffff4f2b8e4 old_inner_width =3D -1 old_inner_height =3D 32767 new_inner_width =3D 0 new_inner_height =3D 1718964966 old_text_cols =3D 247 old_text_lines =3D 0 new_text_cols =3D 0 new_text_lines =3D 0 old_text_width =3D 0 old_text_height =3D 0 inhibit_horizontal =3D false inhibit_vertical =3D false frame =3D make_fixnum(23456254819227) #1 0x00005555564e04c3 in change_frame_size_1 (f=3D0x6210000ede00, new_width=3D60, new_height=3D50, pretend=3Dfalse, delay=3Dfalse, safe= =3Dfalse) at dispnew.c:6054 No locals. #2 0x00005555564e0526 in change_frame_size (f=3D0x6210000ede00, --Type for more, q to quit, c to continue without paging-- new_width=3D60, new_height=3D50, pretend=3Dfalse, delay=3Dfalse, safe= =3Dfalse) at dispnew.c:6087 tail =3D frame =3D #3 0x00005555564df618 in do_pending_window_change (safe=3Dfalse) at dispnew.c:6014 f =3D 0x6210000ede00 tail =3D XIL(0x7fffec71a083) frame =3D XIL(0x6210000ede05) #4 0x0000555556e479ee in wait_reading_process_output (time_limit=3D0, [=E2=80=A6] > > (gdb) p *SELECTED_FRAME() > > $102 =3D { > > header =3D { > > size =3D 4611686018595348501 > > }, > [...] > > output_data =3D { > > tty =3D 0x0, > > x =3D 0x0, > > w32 =3D 0x0, > > ns =3D 0x0, > > pgtk =3D 0x0, > > haiku =3D 0x0, > > android =3D 0x0 > > }, > > This zero value exactly means this frame is "initial" it has not yet > been set up as a terminal frame. That setup happens inside > make-terminal-frame, here: > > f =3D make_terminal_frame (t); > > and make_terminal_frame does > > f->output_method =3D output_termcap; > > Somehow this frame escaped this code, so all kinds of weird things can > happen with it. It seems that under normal Emacs operation, the emacs daemon creates an initial frame which has no output_data->tty. In addition there are non-initial frames, created by make_terminal_frame; one for each frame opened by the user. Could it be that adjust_frame_size is wrongly running on the initial frame, instead of on the terminal frame? Mmm=E2=80=A6 apparently no, it's not that; I just verified it with the commands below. There's the initial frame (F1) and the visible one (F5), and f matches F5. (gdb) list 641 */ 642 void 643 adjust_frame_size (struct frame *f, int new_text_width, int new_text_height, 644 int inhibit, bool pretend, Lisp_Object parameter) 645 { 646 int unit_width =3D FRAME_COLUMN_WIDTH (f); 647 int unit_height =3D FRAME_LINE_HEIGHT (f); 648 int old_native_width =3D FRAME_PIXEL_WIDTH (f); 649 int old_native_height =3D FRAME_PIXEL_HEIGHT (f); 650 int new_native_width, new_native_height; (gdb) p f $34 =3D (struct frame *) 0x6210000ede00 (gdb) p f->name $35 =3D XIL(0x619000159144) (gdb) xpr Lisp_String $36 =3D (struct Lisp_String *) 0x619000159140 "F5" (gdb) p Vframe_list $37 =3D XIL(0x7fffec71a083) (gdb) xcons $38 =3D (struct Lisp_Cons *) 0x7fffec71a080 { u =3D { s =3D { car =3D XIL(0x6210000ede05), u =3D { cdr =3D XIL(0x7ffff18f00f3), chain =3D 0x7ffff18f00f3 } }, gcaligned =3D 0x5 } } (gdb) nextcons $39 =3D XIL(0x7ffff18f00f3) $40 =3D (struct Lisp_Cons *) 0x7ffff18f00f0 { u =3D { s =3D { car =3D XIL(0x621000003f05), u =3D { cdr =3D XIL(0), chain =3D 0x0 } }, gcaligned =3D 0x5 } } (gdb) p 0x6210000ede05 $41 =3D 107820859973125 (gdb) xpr Lisp_Vectorlike PVEC_FRAME $42 =3D (struct frame *) 0x6210000ede00 "F5" No symbol "PVEC_TS_QUERY" in current context. (gdb) p 0x621000003f05 $43 =3D 107820859014917 (gdb) xpr Lisp_Vectorlike PVEC_FRAME $44 =3D (struct frame *) 0x621000003f00 "F1" No symbol "PVEC_TS_QUERY" in current context. (gdb) > > By the way, C-x # isn't enough to close any Emacs frame. If I have > > opened it by running urxvtcd -e 'emacsclient' '-nw', then later C-x > > # doesn't close it, it just says =E2=80=9ENo server buffers remain to e= dit=E2=80=9C. > > But C-x C-c does close it. > > Use "C-x 5 0" to delete the current frame. Ok. The problem reported in this bug report also happens if I use C-x 5 0