> From: Daniel Clemente <n142857@gmail.com>
> Date: Fri, 31 May 2024 17:09:29 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>
>
> While playing with resizing the urxvt terminal size (X window), I
> found other bugs where Emacs doesn't know the real size of the
> terminal, or becomes unsynchronized with the actual terminal size.
> This may cause many of the other bugs I've seen (things in the style
> of: the GC message wants to use 2 minibuffer lines because it thinks
> there are 2 lines, but actually there's just 1, etc.).
>
> The two resizing bugs I found (but I don't have time to research them
> in detail yet) are:
> - if the X terminal has 4 visible rows, FrameRows(tty) reports 4. If
> 3, then 3. But if it has 2 or 1 rows, Emacs still sees 3. And editing
> is garbled
> - if I decrease the terminal size fast, e.g. 81→71→61→51→41→31→21→11→1
> lines, often Emacs doesn't notice all changes, and it may still report
> that FrameRows(tty) is e.g. 31 when it went further down to 1
> (31→21→11→1)
>
> - in addition there's a more complex refresh bug (not about resizing I
> think), in which the next frame I focus after having killed a frame
> won't be refreshed (e.g. I can resize the X window and it doesn't
> notice, new sections appear black) until I press a key or move the
> mouse. It's 100% reproducible but I need to research this better
> because it involves window managers and X
>
> However I didn't see a direct crash from these issues. But maybe a GC
> message in some of these conditions can cause the alert.
>
> I may report them as separate bugs but in a while; I'm reporting too
> many TTY bugs and too fast; I need time for other things.
>
> I also saw a new type of TTY+GC error (not sure if it's the same issue
> as this bug):

Please investigate what happens with our SIGWINCH handler (in
dispnew.c) in these cases.