Re: Question about display engine

[Ergus <spacibba@aol.com>]

On Tue, Sep 03, 2019 at 10:45:46AM +0200, martin rudalics wrote:
>> Could any of you give a look to the patch
>
>I cannot build Emacs on Windows with the patch due to
>
>
>  CC       w32select.o
>../../src/w32term.c: In function 'w32_draw_glyph_string':
>../../src/w32term.c:2482:20: error: 'struct face' has no member named 'underline_p'; did you mean 'underline'?
>       if (s->face->underline_p)
>                    ^~~~~~~~~~~
>                    underline
>../../src/w32term.c:2484:24: error: 'struct face' has no member named 'underline_type'; did you mean 'underline_color'?
>           if (s->face->underline_type == FACE_UNDER_WAVE)
>                        ^~~~~~~~~~~~~~
>                        underline_color
>../../src/w32term.c:2495:29: error: 'struct face' has no member named 'underline_type'; did you mean 'underline_color'?
>           else if (s->face->underline_type == FACE_UNDER_LINE)
>                             ^~~~~~~~~~~~~~
>                             underline_color
>../../src/w32term.c:2500:45: error: 'struct face' has no member named 'underline_p'; did you mean 'underline'?
>               if (s->prev && s->prev->face->underline_p
>                                             ^~~~~~~~~~~
>                                             underline
>../../src/w32term.c:2501:23: error: 'struct face' has no member named 'underline_type'; did you mean 'underline_color'?
>     && s->prev->face->underline_type == FACE_UNDER_LINE)
>                       ^~~~~~~~~~~~~~
>                       underline_color
>make[1]: *** [Makefile:402: w32term.o] Fehler 1
>make[1]: *** Es wird auf noch nicht beendete Prozesse gewartet....
>make[1]: Verzeichnis ???/c/emacs/trunk/non-64/src??? wird verlassen
>make: *** [Makefile:424: src] Fehler 2
>
>
>and since I don't understand the underline_p/_type rationale I have no
>good idea how to proceed.
>
Ohh sorry. My bad I made a code simplify and removed this member. I will
fix it now.

>> to detect what is failing at
>> least to triger the merge and extend?
>> Probably the initialization. (which btw the lisp glue code may be buggy
>> for sure.)
>
>I'd run Emacs under gdb to find out whether merge_extend_glyph_face
>gets called in the first place.  And if it doesn't get called, I would
>continue investigating the places where it should get called.
>
>martin
>
>
After a while I made it to be called, so, forget the patch I will email
a different one in a while.

I found also that we where very concerned about what happen when
merging, but there was not any comment about face_id changes in other
cases (like reassign).

For example, when we select a word in the middle of a line. The
extend_face will be set to the region face when the iterator iterates
throw the word, but then it shouldn't be extended at EOL.

So we are dealing with a 2D problem here. Iterate on X (the line) vs
merging on Y (the face).

So I am not sure we have a criteria about when to propagate the extend
in both dimensions; because as I see in most of the cases the face_id in
X changes due to reassign associated to text properties. So we have been
talking all the time about the Y problem?

maybe we should test only the last face in the line before EOL to check
for the extend flag; but then the extend_face_id will be again an
intrinsic parameter of that face.

I feel I am missing something for sure.