Re: Question about display engine

[Eli Zaretskii]

> Date: Sun, 13 Oct 2019 17:40:52 +0200
> From: Ergus <address@hidden>
> Cc: address@hidden, address@hidden
> 
> #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=<optimized out>, prompt=0x0, dont_downcase_last=<optimized out>, 
> can_return_switch_frame=true, fix_current_buffer=true, 
> prevent_redisplay=<optimized out>)
>     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 <command_loop_1>, 
> handlers=handlers@entry=0x90, hfun=hfun@entry=0x55cb145fadc0 <cmd_error>) 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 <command_loop_2>, 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=<optimized out>) 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?