GNU bug report logs - #13697
A way to tell if Emacs can interact with the user

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13697 in the body.
You can then email your comments to 13697 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #3 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: submit <at> debbugs.gnu.org
Subject: A way to tell if Emacs can interact with the user
Date: Tue, 12 Feb 2013 12:02:30 -0500

Package: emacs
Version: 24.3
Severity: wishlist

It's possible to run Emacs in such in way that it cannot interact with
the user. Either in batch mode or in daemon mode with no open display.
Emacs can hang waiting for user input in such cases (eg bug#6567).

You need to detect such cases before asking the user for input that they
will never be able to give. I came up with (based on server.el):

(or noninteractive
    (and (daemonp)
         (null (cdr (frame-list)))
         (eq (selected-frame) terminal-frame)))

but this is not very obvious. I think there should be a standard
function for this. emacs-interactive-p?

(As an aside, maybe yes-or-no-p etc should abort in such cases rather
than waiting for ever.)

Message #6 received at 13697 <at> debbugs.gnu.org (full text, mbox):

From: Trey Ethan Harris <treyharris <at> gmail.com>
To: 13697 <at> debbugs.gnu.org
Subject: Reopening
Date: Wed, 3 Apr 2019 17:01:38 -0400

[Message part 1 (text/plain, inline)]

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.

[Message part 2 (text/html, inline)]

Message #9 received at 13697 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Trey Ethan Harris <treyharris <at> gmail.com>
Cc: 13697 <at> debbugs.gnu.org
Subject: Re: bug#13697: A way to tell if Emacs can interact with the user
Date: Wed, 03 Apr 2019 18:56:26 -0400

Trey Ethan Harris <treyharris <at> gmail.com> writes:

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

[I've restored the original bug title as the subject, since "reopened"
is a bit lacking in context.  And by the way, this bug was never closed
in the first place]

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

Hmm, I'm not sure where all these threads you're talking about will come
from.  Emacs is still mostly single-threaded, and we still have stuff
like Bug#25214 "Interacting with user from threads other than the
primary" open.

Message #12 received at 13697 <at> debbugs.gnu.org (full text, mbox):

From: Trey Ethan Harris <treyharris <at> gmail.com>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 13697 <at> debbugs.gnu.org
Subject: Re: bug#13697: A way to tell if Emacs can interact with the user
Date: Wed, 3 Apr 2019 19:25:11 -0400

[Message part 1 (text/plain, inline)]

On Wed, Apr 3, 2019 at 6:56 PM Noam Postavsky npostavs <at> gmail.com
<http://mailto:npostavs <at> gmail.com> wrote:


>
> Hmm, I'm not sure where all these threads you're talking about will come
> from.  Emacs is still mostly single-threaded, and we still have stuff
> like Bug#25214 "Interacting with user from threads other than the
> primary" open.
>
Curious; when I start Emacs interactively and it gets stuck on, say, a
desktop lock file (the most common thing that interrupts startup for me),
initialization continues even as the yes-or-no-p waits. I assumed that
meant there was threading. If it does not, then can whatever asynchronicity
does let this continuation happen be substituted for “threads” in my
suggestion above?

[Message part 2 (text/html, inline)]

Message #15 received at 13697 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Trey Ethan Harris <treyharris <at> gmail.com>
Cc: 13697 <at> debbugs.gnu.org
Subject: Re: bug#13697: Reopening
Date: Thu, 04 Apr 2019 15:59:27 +0300

> From: Trey Ethan Harris <treyharris <at> gmail.com>
> Date: Wed, 3 Apr 2019 17:01:38 -0400
> 
> 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.

The problem in desktop.el was fixed in Emacs 26.1, and it didn't
require any complications with threads.  What other problems like that
are there?  Please report each such problem as a separate bug, and
please let the Emacs developers decide whether they need a single
unified solution, like the one proposed in this bug report, or
different solutions.  And in any case, just detecting that Emacs
cannot interact does not yet tell what to do in each such case (and
I'm not sure a single solution will fit all).

Message #18 received at 13697 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 13697 <at> debbugs.gnu.org
Subject: Re: bug#13697: A way to tell if Emacs can interact with the user
Date: Sat, 13 Feb 2021 04:31:25 -0500

8 years later, inhibit-interaction from ca024b0 seems related to this
request.

Message #21 received at 13697 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 13697 <at> debbugs.gnu.org
Subject: Re: bug#13697: A way to tell if Emacs can interact with the user
Date: Sat, 13 Feb 2021 12:38:26 +0100

Glenn Morris <rgm <at> gnu.org> writes:

> 8 years later, inhibit-interaction from ca024b0 seems related to this
> request.

Yup -- I think that fixes the request, so I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.