[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#18422: 24.3.93; Assertion violation when resizing mini-window on a T
bug#18422: 24.3.93; Assertion violation when resizing mini-window on a TTY
Wed, 10 Sep 2014 10:03:27 +0200
> 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