bug#46155: 28.0.50; Regression: buffer contents flicker on macOS frames when

[Aaron Jensen]

On Tue, Feb 9, 2021 at 2:08 PM Alan Third <alan@idiocy.org> wrote:
>
> On Tue, Feb 09, 2021 at 06:29:22PM +0200, Andrii Kolomoiets wrote:
> > Alan Third <alan@idiocy.org> writes:
> >
> > > On Tue, Feb 09, 2021 at 11:05:08AM +0000, Alan Third wrote:
> > >>
> > >> The patch Aaron and Andrii are using calls redisplay() just before the
> > >> frame is drawn, but only if it is garbaged.
> > >
> > > I see from a subsequent email that Andrii isn't using the NS port, so
> > > that bit of my message is wrong.
> >
> > Sorry for kind of misleading you.  I indeed use NS port. The receipt for
> > minibuffer-only frame flickering was made on nearly recent master
> > version with your patch applied.  (I must say resizing and fullscreen
> > transition looks awesome now, thanks!)
> >
> > I used GTK port under X in the VirtualBox to test the issue with the
> > minibuffer-only frame resized more than once even if the text is not
> > changed.
>
> Ah, OK. I guess it probably is exclusive to NS then.
>
> The obvious solution IMO is to retain a copy of the old frame contents
> and draw them in after resizing, before we try calling redisplay().
>
> On the other hand, it would be nice to know why redisplay() isn't
> drawing anything...

inhibit-redisplay appears to be t when miniframes are asked to resize.
Could that be related? I tried letting it to nil and that didn't help.

It also happens that setting the resize to happen via run-with-timer
fixes the flicker:
https://github.com/muffinmad/emacs-mini-frame/pull/32/files#diff-8289c4c5300044ca6d7f9f6f60067a1b5e0d61b6ad0b58720a7c694662ea13abR207

Unfortunately, that prevents resizing when displaying a prompt like
`yes-or-no-p`.

The other different thing about the minibuffer resizing is it all
happens within `read-from-minibuffer`