bug#48406: 28.0.50; Emacs stuck in infinite loop in wait_reading_process_output when opening in fullscreen (NS)

[Eli Zaretskii <eliz@gnu.org>]

> From: Illia Ostapyshyn <ilya.ostapyshyn@gmail.com>
> Date: Fri, 14 May 2021 11:22:30 +0200
> Cc: 48406@debbugs.gnu.org
> 
> > On May 14, 2021, at 08:22, Eli Zaretskii <eliz@gnu.org> wrote:
> > 
> >> From: Illia Ostapyshyn <ilya.ostapyshyn@gmail.com>
> >> Date: Thu, 13 May 2021 22:39:55 +0200
> >> 
> >> When starting with
> >> 
> >>    (push '(fullscreen . fullboth) default-frame-alist)
> >> 
> >> in early-init.el, apparently Emacs get stuck in an infinite loop after calling [EmacsView waitFullScreenTransition]. Please see the attached backtrace. I also tried moving that command around: in init.el, in emacs-startup-hook, all yield the same result. 
> > 
> > Why did you put that in early-init.el? why not in .emacs or init.el?
> 
> I figured that way I wouldn't see an unconfigured frame for a fraction of a second when starting Emacs and it worked for me on other systems. Are there any caveats to it?

Yes, the caveat is that you do this too early.  I'm not sure I want to
tweak Emacs to support these settings in early-init.el just to avoid
the momentary display of the original frame.  As documented,
early-init.el is for stuff that _must_ be there, or else it won't
work at all.

> Like I mentioned, with this line in init.el Emacs exhibits the same behavior.
> 
> emacs -Q --execute "(push '(fullscreen . fullboth) default-frame-alist)"
> doesn't work as well.

"Doesn't work" in what sense?  What did you expect to happen and what
did indeed happen?

And the above line is definitely not for init.el, it's a command for
invoking Emacs from the shell prompt.  So I'm not sure I understand
what exactly did you try with that command.