Re: Question about display engine

[Ergus <spacibba@aol.com>]

Hi Eli:

On Sun, Oct 13, 2019 at 12:46:10PM +0300, Eli Zaretskii wrote:
>> Date: Sun, 13 Oct 2019 00:23:05 +0200
>> From: Ergus <spacibba@aol.com>
>>
>> >I don't understand why would we want to add a call to handle_face_prop
>> >there.
>> >
>>
>> The call there is to emulate the part in our branch that produced the
>> issue. And isolate the source of the problem, independently of all the
>> other changes.
>>
>> Remember we modified handle_face_prop to be called here with the extra
>> parameter to filter.
>
>But handle_face_prop modifies some members of its IT argument, whereas
>the function called from extend_face_to_end_of_line (face_at_pos)
>should not do that, it should just return the face ID to use.
>
>I now see that face_at_pos modifies it->start_of_box_run_p and
>it->face_box_p.  This is wrong, you should do that outside of
>face_at_pos, in handle_face_prop itself.  Maybe this is the reason for
>the infloop?  If extend_face_to_end_of_line needs to manipulate these
>members (does it?), it needs to save and restore the old values.
>
Fixed now, but that's not the solution for the issue.

>> >Can you tell where it loops?  That is, describe the sequence of calls
>> >and the return values for a single iteration through the loop?
>>
>> It is a very long loop it jumps here and there in the code it is very
>> difficult to explain. But basically it stays going and coming in
>> display_line for ever.
>
>You don't have to explain it, just show me one iteration through the
>loop as you step through the code in GDB.
>
In GDB I have this bt:

#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.

What I can't understand is how the code can be in #1 that should always
filtered by the WINDOWP condition in tui right?

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.

On the other hand I don't understand how is this related with the call
of face_at_pos in the extend_face_to_end_of_line. Any idea?

>> Maybe you look at it and you find the issue in 5 seconds, but there
>> is still too much I ignore to get it.
>
>Unlikely.  And it is not wise to lose all the information you have
>already collected about this problem, it could help me quite a lot.
>At the very least please show a backtrace from inside the infloop, and
>tell whether we are iterating over a buffer or a string, and if the
>latter, what kind of string is that (overlay string, display string?).
>
>> Magit is available in melpa. Installing and using it is trivial.
>
>I don't need to install it, I just need to load it.
>
Then the command I send before should be enough.

>> Maybe Martin have something to say about this?
>
>You didn't CC Martin on this message.

My bad