bug#13697: Reopening

[Trey Ethan Harris <treyharris@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2498 bytes --]

As described in the Emacs Stack Exchange question,
https://emacs.stackexchange.com/questions/32692/daemon-mode-defer-interactive-prompts-on-startup/
, this bug seems to be applicable and should be reopened.

Many people seem to be attempting to run `emacs --daemon` as part of their
system on login startup--mostly as a way to improve emacsclient
initialization time when Emacs is first needed--but they run into trouble
because systemd or other startup system or the GUI login process is
non-interactive. If Emacs attempts to interact in any way at startup time,
then the daemon startup hangs.

There is no way AFAIK to respond to such an interaction--the Emacs server
hasn't started yet, so emacsclient can't be used.

The issue can exacerbate system issues, especially after abnormal exit. If
the user uses the empty-string form of ALTERATE_EDITOR, they may
unwittingly start up multiple Emacs daemons that will all hang at the same
point in startup. If they so configure their startup system with a watchdog
functionality, they may repeatedly kill and restart the Emacs daemon, doing
nothing but drawing useless CPU and IO.

One can workaround the issue in a piecemeal fashion by overriding or
advising functions in startup packages that may interact (for instance,
advising `desktop-restore-file-buffer` so that it will not block if the
daemon is being restarted from a crash and a desktop lockfile still
exists). However, this is not a general solution--one can never know for
certain from where an interaction might arise.

Of course Emacs itself can't supply a 100% solution--the user could always
put something in initialization which blocks on interaction, even if it's
specific Elisp to do so or a call out to a shell program.

But Emacs _could,_ I think, provide a 99% solution:

1. Intercept interaction functions like `yes-or-no-p` and password prompts
running in asynchronous threads, allowing them to block their thread
2. Automatically convert interaction in other threads into a warning failure
3. Continue execution of other threads so that the server can start
4. Upon first connection with an emacsclient, display the warnings
(presumably by popping up *Warnings*) so that the user is aware of what may
have failed in initialization due to inability to interact
5. Take the user through the queued blocked threads so they can complete
the threaded interactions.

I have tried to do this in a pure user-side Elisp way, but I don't think
it's possible without Emacs' assistance.

[-- Attachment #2: Type: text/html, Size: 4227 bytes --]