From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Question about display engine Date: Sun, 13 Oct 2019 19:06:18 +0300 Message-ID: <83a7a4ljet.fsf@gnu.org> References: <20191012222305.jpjinkd5y2lz6xiv@Ergus> <83mue5kmfx.fsf@gnu.org> <20191013154052.yzluijtwvf2ppvks@Ergus> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="241406"; mail-complaints-to="usenet@blaine.gmane.org" Cc: rudalics@gmx.at, emacs-devel@gnu.org To: Ergus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 13 18:07:04 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iJgOe-0010gL-00 for ged-emacs-devel@m.gmane.org; Sun, 13 Oct 2019 18:07:04 +0200 Original-Received: from localhost ([::1]:40868 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iJgOc-0006RM-Sq for ged-emacs-devel@m.gmane.org; Sun, 13 Oct 2019 12:07:02 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41770) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iJgO4-0006RF-3m for emacs-devel@gnu.org; Sun, 13 Oct 2019 12:06:29 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:60873) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iJgO3-0006Qg-B4; Sun, 13 Oct 2019 12:06:27 -0400 Original-Received: from [176.228.60.248] (port=3168 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iJgO2-0005pv-Ca; Sun, 13 Oct 2019 12:06:26 -0400 In-reply-to: <20191013154052.yzluijtwvf2ppvks@Ergus> (message from Ergus on Sun, 13 Oct 2019 17:40:52 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:240968 Archived-At: > Date: Sun, 13 Oct 2019 17:40:52 +0200 > From: Ergus > Cc: rudalics@gmx.at, emacs-devel@gnu.org > > #0 0x000055cb1453ac98 in redisplay_windows (window=0x55cb15e3bfb5) at ../../src/xdisp.c:16126 > #1 0x000055cb1453ac6d in redisplay_windows (window=0x55cb163ffc55) at ../../src/xdisp.c:16120 > #2 0x000055cb1455b35d in redisplay_internal () at ../../src/xdisp.c:15596 > #3 0x000055cb145fff3f in read_char (commandflag=1, map=0x55cb16838f93, prev_event=0x0, used_mouse_menu=0x7ffc1a89f4eb, end_time=0x0) at ../../src/keyboard.c:2473 > #4 0x000055cb1460278a in read_key_sequence > (keybuf=, prompt=0x0, dont_downcase_last=, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=) > at ../../src/keyboard.c:9527 > #5 0x000055cb14603e2c in command_loop_1 () at ../../src/lisp.h:1032 > #6 0x000055cb1466af87 in internal_condition_case > (bfun=bfun@entry=0x55cb14603c30 , handlers=handlers@entry=0x90, hfun=hfun@entry=0x55cb145fadc0 ) at ../../src/eval.c:1355 > #7 0x000055cb145f5b94 in command_loop_2 (ignore=ignore@entry=0x0) at ../../src/lisp.h:1032 > #8 0x000055cb1466aee1 in internal_catch (tag=tag@entry=0xd4a0, func=func@entry=0x55cb145f5b70 , arg=arg@entry=0x0) at ../../src/eval.c:1116 > #9 0x000055cb145f5b3b in command_loop () at ../../src/lisp.h:1032 > #10 0x000055cb145fa9d6 in recursive_edit_1 () at ../../src/keyboard.c:714 > #11 0x000055cb145fad02 in Frecursive_edit () at ../../src/keyboard.c:786 > #12 0x000055cb1451c957 in main (argc=18, argv=) at ../../src/emacs.c:2055 > > After some other tests I just did; I found that: > > #0 seems to be the root of the loop. redisplay_windows never ends (inf > loop) and I can't understand why. But at least this explains why in gui > it works but not in tui, because there is the WINDOWP test. The WINDOWP test has nothing to do with GUI vs TTY, it tests whether w->contents is a window or a buffer. > What I can't understand is how the code can be in #1 that should always > filtered by the WINDOWP condition in tui right? No, see above. This function is a simple depth-first tree traversal of the window tree, starting from the root window of a frame. Each leaf of the window tree has a buffer in its w->contents pointer, while intermediate nodes of the tree have windows in that pointer. > In any case the inf loop is there, but the recursions levels does not > grow... so after the first time it enters in #1, it goes in the other > branch if the if. If it goes to the other branch, it should descend the tree via the w->next pointer, and eventually get to a leaf node. Could it be that redisplay_window_0, or some function it calls, signals an error, which is caught by internal_condition_case_1? What happens if you put a breakpoint in signal_or_quit, does it get called from redisplay_window or some other function called by redisplay_windows?