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

[martin rudalics]

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

This analysis was downright silly.  If it were accurate, then
adjust_frame_glyphs would have choked immediately and everywhere.  When
I assign pixel sizes I also assign the total sizes as an estimate in the
sense that partially visible characters are counted as full.

Later I have to recalculate sizes to make sure that the individual total
sizes of subwindows sum up to the total size of their parent window.
This is needed to make some older functions (in particular those from
windmove) work and can result in some windows getting a smaller total
size than at the time adjust_frame_glyphs was called.  This is, however,
not an issue for -nw since there are no partial visible characters.

> Please do one or the other, I don't think we can leave the release
> branch in its current state.  It's all too easy to trigger this
> problem.

I checked in a fix for the bug.  It was entirely restricted to manually
resizing the minibuffer window, something apparently nobody tried since
last year with -nw.

>> 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.
>
> I think the iceberg whose tip you envision includes the invalidity of
> the "total" values.  IOW, this is imaginary safety, more bugs are
> lurking out there.

Hopefully, the iceberg melt by now.

>> 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.
>
> That might be a good plan, but it' not for the release branch.

It would neither help nor work anyway.

martin