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

[Eli Zaretskii]

> 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.