Re: update_window: w->desired_matrix is a partial representation.

[Eli Zaretskii]

> Date: Thu, 17 Jan 2019 00:05:28 -0800
> From: Keith David Bershatsky <address@hidden>
> 
> *  The word-wrapped line in the first step increases in length from 4 screen 
> lines to 5 screen lines; followed by a hard return; followed by miscellaneous 
> lines.
> 
> 0.  My header-line format.
> 1.  12!34⤸
> 2.  56789⤸
> 3.  01234⤸
> 4.  56789⤸
> 5.  0
> 6.  
> 7.  Every good boy deserves fudge.
> 8.  Once upon a time there lived a ....
> 
> RESULT:
> 
> * All subsequent screen lines get pushed down one row to make room for the 
> new row (VPOS 5) that was inserted by the undo.
> 
> * update_window_line reports that VPOS lines 1 to 5 are changed_p.
> 
> * If we dump_glyph_row for each line of w->desired_matrix from within 
> update_window, we observe that the empty line between the first 6 screen 
> lines (including the header-line) and the subsequent miscellaneous lines is 
> _not_ present.  VPOS 6 is "Every good by deserves fudge."
> 
> ERRONEOUS EXPECTATION:  I expected VPOS 6 of w->desired_matrix to be the line 
> containing a visible line number 6, _not_ the subsequent line that contains 
> "Every good by deserves fudge."

When you examine glyph rows of a glyph matrix, pay attention to the
enabled_p flag of each row: a row whose enabled_p flag is reset does
not really reflect the desired contents of the screen, but some random
garbage.

If you are saying that row whose VPOS is 6 has its enabled_p flag set,
and its contents is not what eventually appears on the screen, then
I'd need a precise recipe, preferably without source-level changes to
the current code, to reproduce the situation.  In general, redisplay
in this case can update the screen via a method that scrolls the text
on the glass directly, so you might not see that if you are not
looking in the right place.  But that's just a hunch.

More generally, I don't think a display feature that relies on the
contents of the desired matrix is a good idea, because the desired
matrix is a tool for the display engine to update the screen, and is
not supposed to convey the entire contents of a window, nor even
describe reliably what will be actually updated.  Why did you need to
rely on the desired matrix for your feature?

> QUESTION #1:  From within update_window, is it possible to programmatically 
> access the glyph_row containing the visible line number 6?

You can look at glyph_matrix->rows[6], but the result is reliable only
if the enabled_p flag of that row is set.

> QUESTION #2:  From within update_window, is it possible to programmatically 
> test to see whether VPOS 6 and all subsequent screen lines have been pushed 
> downwards to make room for the new VPOS 5?

You'd need to compare with the current_matrix for that.  But why would
you need to know a thing like that?  Your code shouldn't care how
exactly the display engine decided to update the screen.