From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#71343: 30.0.50; TTY frame doesn't automatically redisplay itself after having closed another frame Date: Sun, 16 Jun 2024 09:33:06 +0300 Message-ID: <86o781s8gt.fsf@gnu.org> References: <86o78egucl.fsf@gnu.org> <86cyougp9b.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17399"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eggert@cs.ucla.edu, 71343@debbugs.gnu.org To: Daniel Clemente Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jun 16 08:34:26 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 1sIjT8-0004Fg-2D for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 16 Jun 2024 08:34:26 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sIjSl-0000Y6-VY; Sun, 16 Jun 2024 02:34:03 -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 1sIjSk-0000Xo-9J for bug-gnu-emacs@gnu.org; Sun, 16 Jun 2024 02:34:02 -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 1sIjSk-0005Fy-1G for bug-gnu-emacs@gnu.org; Sun, 16 Jun 2024 02:34:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sIjSk-0002P8-6m for bug-gnu-emacs@gnu.org; Sun, 16 Jun 2024 02:34:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 16 Jun 2024 06:34:02 +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.17185195999137 (code B ref 71343); Sun, 16 Jun 2024 06:34:02 +0000 Original-Received: (at 71343) by debbugs.gnu.org; 16 Jun 2024 06:33:19 +0000 Original-Received: from localhost ([127.0.0.1]:57306 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sIjS2-0002NG-9Y for submit@debbugs.gnu.org; Sun, 16 Jun 2024 02:33:18 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:42714) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sIjS0-0002Ms-4G for 71343@debbugs.gnu.org; Sun, 16 Jun 2024 02:33:16 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sIjRt-0005CO-GL; Sun, 16 Jun 2024 02:33:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=kAW3e60i76l+UG9Pg5ZbcroSEKzjHZAlU6se0Z9qRCQ=; b=q5xMJLguER1Fh0NMjRbh GeOIuFbX+uw6vgmckxr62UAeGHtRfXWuRBzvZOPkvPQqeCPxBPXHnBrQbDXPyjDxMXxnpI7+kCgOb C6x+6No8tK+kLBwcpg4By4SLSMQn31XYcTDI5ru1o8pXVa8cTHw6i/GAXFs2+XwjzAzixdQLi/s7V /Tmfx1+Ce8U9Z51fTWj6nWJYDvijv1zvfGs7BKDRQ5i/UUM4d8aHO5psHQMVe92Fh6JXoKR8cBQ8e gsg5DhfKoZPr1h9B7zSa4Wh1dXDrb7YTmwxKJflXunVn0TsfYwdXV4+9stQS2rhQu8Cg4CSK/kQ8B mjSyw0GgVv3g2g==; In-Reply-To: (message from Daniel Clemente on Sun, 16 Jun 2024 05:40:12 +0000) 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:287323 Archived-At: > From: Daniel Clemente > Date: Sun, 16 Jun 2024 05:40:12 +0000 > Cc: eggert@cs.ucla.edu, 71343@debbugs.gnu.org > > I have a new discovery (it's about „initial frame“), you can skip to > the gdb info below (line 16876). It's a problematic discovery from where I stand... > > > Random ideas, without knowing much about terminals. > > > - Can't an X terminal detect „I've been given X focus“ and pass this > > > signal to the program running inside it? > > > > You assume that it will be a terminal belonging to Emacs that will get > > focus? That is not given. > > I was thinking that maybe X always does this (X notifies the terminal > emulator, which notifies the program running inside it, whatever > program it is). 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? > > > - What if, when resizing the frame (something which Emacs detects), > > > Emacs knows/detects that a frame was closed, and decides not to delay > > > 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 normal conditions, resizing a frame calls: adjust_frame size, then > redisplay_internal, then clear_garbaged_frames, then redraw_frame > > But when I reproduce this bug (i.e. just after closing a frame), > resizing a frame calls: adjust_frame_size, then redisplay_internal. It > doesn't call the other two. > (Only later when I press a key, it calls redisplay_internal, then > clear_garbaged_frames, then redraw_frame) > In this scenario, why doesn't redisplay_internal reach the point where > it calls clear_garbaged_frames? > Because this happens: > Breakpoint 5, redisplay_internal () at xdisp.c:16831 > 16831 struct window *w = XWINDOW (selected_window); > (gdb) n > 16835 bool must_finish = false, match_p; > (gdb) > 16839 bool polling_stopped_here = false; > (gdb) > 16846 int hscroll_retries = 0; > (gdb) > 16854 int garbaged_frame_retries = 0; > (gdb) > 16862 bool update_miniwindow_p = false; > (gdb) > 16864 redisplay_trace ("redisplay_internal %d\n", redisplaying_p); > (gdb) > 16870 if (redisplaying_p) > (gdb) > 16876 if ((FRAME_INITIAL_P (SELECTED_FRAME ()) > (gdb) > 16877 && redisplay_skip_initial_frame) > (gdb) > 16879 return; > (gdb) > > > So, apparently it thinks that my frame is initial. And for a good reason: > Some more data about the looks-initial frame: > > (gdb) p *SELECTED_FRAME() > $102 = { > header = { > size = 4611686018595348501 > }, [...] > output_data = { > tty = 0x0, > x = 0x0, > w32 = 0x0, > ns = 0x0, > pgtk = 0x0, > haiku = 0x0, > android = 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 = make_terminal_frame (t); and make_terminal_frame does f->output_method = output_termcap; Somehow this frame escaped this code, so all kinds of weird things can happen with it. > 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 „No server buffers remain to edit“. > But C-x C-c does close it. Use "C-x 5 0" to delete the current frame.