> Thanks, but could you tell how that change could have affected this
> assertion violation?

I attach the patch now, sorry for not doing it earlier.

IIUC we are talking about this assertion

          eassert (frame_size_change_delayed (XFRAME (w->frame))
                   || glyph_row_slice_p (window_row, frame_row));

Right?  If so, then this violation might be caused by the fact that we
(1) did resize windows according to the new sizes but (2) did not update
the frame sizes accordingly.  Which seems to match one observation that
the assertion gets violated when we increase the terminal height after
making it very small and not before.

> AFAICT, adjust_frame_glyphs is not in the
> backtrace, so how could moving code inside of it affect what happens
> here?

I don't understand what you mean here.

martin



      • b... Eli Zaretskii
        • ... Bug reports for GNU Emacs, the Swiss army knife of text editors
          • ... Eli Zaretskii
          • ... Eli Zaretskii
          • ... Bug reports for GNU Emacs, the Swiss army knife of text editors
          • ... Bug reports for GNU Emacs, the Swiss army knife of text editors
          • ... Eli Zaretskii
          • ... Eli Zaretskii
      • b... Daniel Clemente
        • ... Bug reports for GNU Emacs, the Swiss army knife of text editors
  • bug#73022:... Bug reports for GNU Emacs, the Swiss army knife of text editors
    • bug#7... Eli Zaretskii
      • b... Bug reports for GNU Emacs, the Swiss army knife of text editors
        • ... Eli Zaretskii
          • ... Bug reports for GNU Emacs, the Swiss army knife of text editors
          • ... Daniel Clemente
          • ... Eli Zaretskii
          • ... Bug reports for GNU Emacs, the Swiss army knife of text editors
          • ... Daniel Clemente
          • ... Bug reports for GNU Emacs, the Swiss army knife of text editors
          • ... Eli Zaretskii

Reply via email to