[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 20:33:26 +0300
> Date: Wed, 10 Sep 2014 10:03:27 +0200
> From: martin rudalics <address@hidden>
> CC: address@hidden
> > 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.
Like I said: I don't think it's a good idea to give up on keeping the
"total" members valid at all times.
> > 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.
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
> > 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.
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.
> 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
That might be a good plan, but it' not for the release branch.