bug#18422: 24.3.93; Assertion violation when resizing mini-window on a TTY

[martin rudalics <rudalics@gmx.at>]

 > I already tried this before reporting the bug.  It doesn't work,
 > because we then hit these assertions in fake_current_matrices:
 >
 > 	  eassert (m->matrix_h == WINDOW_TOTAL_LINES (w));
 > 	  eassert (m->matrix_w == WINDOW_TOTAL_COLS (w));

We would have to use pixel sizes there too and maybe elsewhere.

 > In general, I think it's a bad idea to have bogus values in
 > WINDOW_TOTAL_LINES and WINDOW_TOTAL_COLS, they are not documented to
 > be invalid under any circumstances, so the code relies on them.

Agreed.  The "total" values are bogus from the moment a function like
`resize-mini-window-internal' is executed until `window--pixel-to-total'
is executed.  Unfortunately, I currently adjust the frame glyphs right
in between.  I should either move the adjust_frame_glyphs call to
Fwindow_resize_apply_total or set the new total sizes before calling
window_resize_apply and have the latter call window_resize_apply_total.

 > What exactly frightens you in your first proposal?  Perhaps we should
 > install my patch on the emacs-24 branch and your window.el patch on
 > the trunk?

I'm afraid that the current bug is only the tip of an iceberg.  We
should close the window of vulnerability sketched above.  On the
emacs-24 branch.  Neither of the two schemes from the previous paragraph
is entirely trivial so using pixel values instead of character values
would put us more on the safe side.

Eventually, I intend to remove the total_lines/total_cols fields from
the frame structure and have FRAME_TOTAL_COLS and FRAME_TOTAL_LINES
calculate the values directly from the pixel sizes.  I refrained from
doing this already because I'm never sure how these values should get
rounded.

martin