bug#48162: 28.0.50; Resizing using set-frame-width doesn't expand mode-line

[Alan Third <alan@idiocy.org>]

On Sun, May 02, 2021 at 06:12:45PM +0200, martin rudalics wrote:
> > This is occurring on MacOS build. Branch: master.
> > Steps:
> > 1. ./src/emacs -Q
> > 2. M-x set-frame-width RET 160 RET
> >
> > Result: Frame size is increased but mode-line still has original width.
> 
> Could you please try the patch below.
> 
> Thanks, martin
> 
> 
> diff --git a/src/nsterm.m b/src/nsterm.m
> index 6e7ab1266b..b089146e64 100644
> --- a/src/nsterm.m
> +++ b/src/nsterm.m
> @@ -7310,9 +7310,9 @@ - (void)viewDidResize:(NSNotification *)notification
> 
>    /* Don't want to do anything when the view size hasn't changed. */
>    if ((oldh == newh && oldw == neww)
> -      || (emacsframe->new_size_p
> -          && newh == emacsframe->new_height
> -          && neww == emacsframe->new_width))
> +      && (!emacsframe->new_size_p
> +          || (newh == emacsframe->new_height
> +	      && neww == emacsframe->new_width)))
>      {
>        NSTRACE_MSG ("No change");
>        return;

This patch reintroduces the infinite loop I was trying to avoid.

viewDidResize is called every time the view's "frame" is touched. Most
of the time this happens when nothing has changed, but calling
change_frame_size, even when nothing has changed, appears to cause the
toolbar to redraw, which causes viewDidResize to be called again, and
so on ad infinitum.

So I put in the check whether the new frame size that's reported is
actually the same as the previous frame size, and if so do nothing.
Then realised that I need to check the new_height and new_width
settings in case the change is already pending.

I'm not sure where new_size_p comes into it, perhaps we don't even
need to check it in viewDidResize, because all we care about is the
final outcome?

Maybe this really isn't the way to do it and I need to keep track of
the frame size separately, which is something I was hoping to avoid.
-- 
Alan Third