Emacs making questions while starting in daemon mode

Emacs making questions while starting in daemon mode

[Óscar Fuentes]

I've just detected the second instance of a problem that consists on
asking questions to the user while emacs is starting in daemon mode (see
bug#6567) Unless the user is starting emacs from a console, he can't
notice the question and emacs sits there forever waiting for an
answer. From the POV of the user, the emacs daemon hangs.

Maybe all the features that request input from the user should bail out
if they are invoked while in daemon mode and there is no console nor
frame where to interact?  I'm thinking of y-or-n-p, ask-user-about*,
read-from-minibuffer, read-password, etc

Re: Emacs making questions while starting in daemon mode

[Dan Nicolaescu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> I've just detected the second instance of a problem that consists on
> asking questions to the user while emacs is starting in daemon mode (see
> bug#6567) Unless the user is starting emacs from a console, he can't

You can avoid that one by customizing `vc-follow-symlinks'.
Maybe you can make an argument in that bug report for changing the
default for the above variable...

> notice the question and emacs sits there forever waiting for an
> answer. From the POV of the user, the emacs daemon hangs.

If "emacs --daemon" asks a question when starting, one should be able
to answer it from the terminal, the same way it is done when emacs is
started in batch mode.
In general such a question is due to what the user has in .emacs, we
can't really prevent the user from shooting himself in the foot.


> Maybe all the features that request input from the user should bail out
> if they are invoked while in daemon mode and there is no console nor
> frame where to interact?  I'm thinking of y-or-n-p, ask-user-about*,
> read-from-minibuffer, read-password, etc

This assumes that there's a default correct answer to any of these
questions, which is doubtful.

Re: Emacs making questions while starting in daemon mode

[Óscar Fuentes]

Dan Nicolaescu <dann@gnu.org> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> I've just detected the second instance of a problem that consists on
>> asking questions to the user while emacs is starting in daemon mode (see
>> bug#6567) Unless the user is starting emacs from a console, he can't
>
> You can avoid that one by customizing `vc-follow-symlinks'.

Good to know. Thanks!

> Maybe you can make an argument in that bug report for changing the
> default for the above variable...

Maybe, but I worry about the general case, because I'm pretty sure that
it will happen again somewhere else as soon as I forget about this
pitfall.

>> notice the question and emacs sits there forever waiting for an
>> answer. From the POV of the user, the emacs daemon hangs.
>
> If "emacs --daemon" asks a question when starting, one should be able
> to answer it from the terminal, the same way it is done when emacs is
> started in batch mode.

I'm thinking on the case where there is no terminal, or you can not
assume that there is a human watching it.

> In general such a question is due to what the user has in .emacs, we
> can't really prevent the user from shooting himself in the foot.
>
>> Maybe all the features that request input from the user should bail out
>> if they are invoked while in daemon mode and there is no console nor
>> frame where to interact?  I'm thinking of y-or-n-p, ask-user-about*,
>> read-from-minibuffer, read-password, etc
>
> This assumes that there's a default correct answer to any of these
> questions, which is doubtful.

The absolutely wrong answer is to hang until the user figures out that
emacs' initialization froze and starts pulling his hair about the
cause. Then, if the cause is on emacs's own code, he needs to find a
workaround.

IMO, an acceptable "answer" on those cases is to act as if the user
pressed C-g to abort the question, leave some notice on *Messages* and
keep going with the initialization.

Is there a predicate that tells if emacs is initializing?

Re: Emacs making questions while starting in daemon mode

[Dan Nicolaescu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Dan Nicolaescu <dann@gnu.org> writes:
>
>> Óscar Fuentes <ofv@wanadoo.es> writes:
>>
>>> notice the question and emacs sits there forever waiting for an
>>> answer. From the POV of the user, the emacs daemon hangs.
>>
>> If "emacs --daemon" asks a question when starting, one should be able
>> to answer it from the terminal, the same way it is done when emacs is
>> started in batch mode.
>
> I'm thinking on the case where there is no terminal, or you can not
> assume that there is a human watching it.

If there's no terminal, the only absolutely safe way is to use:
emacs -Q --daemon

>> In general such a question is due to what the user has in .emacs, we
>> can't really prevent the user from shooting himself in the foot.
>>
>>> Maybe all the features that request input from the user should bail out
>>> if they are invoked while in daemon mode and there is no console nor
>>> frame where to interact?  I'm thinking of y-or-n-p, ask-user-about*,
>>> read-from-minibuffer, read-password, etc
>>
>> This assumes that there's a default correct answer to any of these
>> questions, which is doubtful.
>
> The absolutely wrong answer is to hang until the user figures out that
> emacs' initialization froze and starts pulling his hair about the
> cause. Then, if the cause is on emacs's own code, he needs to find a
> workaround.

Can you show a case where it's hanging?  It should not detach from the
tty until .emacs is processed.

> IMO, an acceptable "answer" on those cases is to act as if the user
> pressed C-g to abort the question, leave some notice on *Messages* and
> keep going with the initialization.

How is that different than having a default answer of "no" (or "yes")?

> Is there a predicate that tells if emacs is initializing?

after-init-time might be, depends on what you need.

Re: Emacs making questions while starting in daemon mode

[Óscar Fuentes]

Dan Nicolaescu <dann@gnu.org> writes:

>> I'm thinking on the case where there is no terminal, or you can not
>> assume that there is a human watching it.
>
> If there's no terminal, the only absolutely safe way is to use:
> emacs -Q --daemon

This is precisely to avoid the case where emacs asks for user input
while initializing, isn't it?

>>> This assumes that there's a default correct answer to any of these
>>> questions, which is doubtful.
>>
>> The absolutely wrong answer is to hang until the user figures out that
>> emacs' initialization froze and starts pulling his hair about the
>> cause. Then, if the cause is on emacs's own code, he needs to find a
>> workaround.
>
> Can you show a case where it's hanging?  It should not detach from the
> tty until .emacs is processed.

If you start emacs --daemon from KRunner, for instance, there is no
visible console. (KRunner is a KDE tool used for executing applications
by its name. I guess Gnome has something similar.)

>> IMO, an acceptable "answer" on those cases is to act as if the user
>> pressed C-g to abort the question, leave some notice on *Messages* and
>> keep going with the initialization.
>
> How is that different than having a default answer of "no" (or "yes")?

"yes" and "no" can express very different intentions depending on the
question ("are you sure you want to launch the ICBM?" "start process for
establishing world peace?") C-g means "cancel," which arguably can cause
confussion too, but less so, I hope.

>> Is there a predicate that tells if emacs is initializing?
>
> after-init-time might be, depends on what you need.

Thanks.

Re: Emacs making questions while starting in daemon mode

[Dan Nicolaescu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Dan Nicolaescu <dann@gnu.org> writes:
>
>>> I'm thinking on the case where there is no terminal, or you can not
>>> assume that there is a human watching it.
>>
>> If there's no terminal, the only absolutely safe way is to use:
>> emacs -Q --daemon
>
> This is precisely to avoid the case where emacs asks for user input
> while initializing, isn't it?

More precisely is to prevent the user from shooting himself in the foot.

>>>> This assumes that there's a default correct answer to any of these
>>>> questions, which is doubtful.
>>>
>>> The absolutely wrong answer is to hang until the user figures out that
>>> emacs' initialization froze and starts pulling his hair about the
>>> cause. Then, if the cause is on emacs's own code, he needs to find a
>>> workaround.
>>
>> Can you show a case where it's hanging?  It should not detach from the
>> tty until .emacs is processed.
>
> If you start emacs --daemon from KRunner, for instance, there is no
> visible console. (KRunner is a KDE tool used for executing applications
> by its name. I guess Gnome has something similar.)

What happens if you start any other program that requires tty input in
the same conditions?

>>> IMO, an acceptable "answer" on those cases is to act as if the user
>>> pressed C-g to abort the question, leave some notice on *Messages* and
>>> keep going with the initialization.
>>
>> How is that different than having a default answer of "no" (or "yes")?
>
> "yes" and "no" can express very different intentions depending on the
> question ("are you sure you want to launch the ICBM?" "start process for
> establishing world peace?") C-g means "cancel," which arguably can cause
> confussion too, but less so, I hope.

What does C-g mean for `yes-or-no-p'?
How hard it is to do something that the user does not expect based on that?

Re: Emacs making questions while starting in daemon mode

[Óscar Fuentes]

Dan Nicolaescu <dann@gnu.org> writes:

>>>> I'm thinking on the case where there is no terminal, or you can not
>>>> assume that there is a human watching it.
>>>
>>> If there's no terminal, the only absolutely safe way is to use:
>>> emacs -Q --daemon
>>
>> This is precisely to avoid the case where emacs asks for user input
>> while initializing, isn't it?
>
> More precisely is to prevent the user from shooting himself in the foot.

In this case, the user did nothing stupid. It is emacs' fault if some
package asks the user about something on circunstances where it is not
appropiate.

emacs -Q is a very limited experience. If I had to use -Q with --daemon
I would ditch --daemon at once.

>> If you start emacs --daemon from KRunner, for instance, there is no
>> visible console. (KRunner is a KDE tool used for executing applications
>> by its name. I guess Gnome has something similar.)
>
> What happens if you start any other program that requires tty input in
> the same conditions?

KRunner & friends does not show a tty. `less some-file', for instance,
detects that it does not have a tty and just terminates. Apparently it
is the same case for other tools, although not for vim in text mode.

Adding `emacs --daemon' to init scripts is problematic for the same
reason. Usually, daemons are started by init scripts, which run
unattended. Is it considered okay for a daemon to ask questions while
starting?

>>>> IMO, an acceptable "answer" on those cases is to act as if the user
>>>> pressed C-g to abort the question, leave some notice on *Messages* and
>>>> keep going with the initialization.
>>>
>>> How is that different than having a default answer of "no" (or "yes")?
>>
>> "yes" and "no" can express very different intentions depending on the
>> question ("are you sure you want to launch the ICBM?" "start process for
>> establishing world peace?") C-g means "cancel," which arguably can cause
>> confussion too, but less so, I hope.
>
> What does C-g mean for `yes-or-no-p'?

Abort?

> How hard it is to do something that the user does not expect based on that?

I'm not saying that C-g is the rigth response. It is just much better
than hanging.

Re: Emacs making questions while starting in daemon mode

[Dan Nicolaescu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Dan Nicolaescu <dann@gnu.org> writes:
>
>>>>> I'm thinking on the case where there is no terminal, or you can not
>>>>> assume that there is a human watching it.
>>>>
>>>> If there's no terminal, the only absolutely safe way is to use:
>>>> emacs -Q --daemon
>>>
>>> This is precisely to avoid the case where emacs asks for user input
>>> while initializing, isn't it?
>>
>> More precisely is to prevent the user from shooting himself in the foot.
>
> In this case, the user did nothing stupid. It is emacs' fault if some
> package asks the user about something on circunstances where it is not
> appropiate.

The user did, it added something to his emacs that asks a question during startup.
The user should test emacs --daemon in a terminal before using it without a terminal. 

>>> If you start emacs --daemon from KRunner, for instance, there is no
>>> visible console. (KRunner is a KDE tool used for executing applications
>>> by its name. I guess Gnome has something similar.)
>>
>> What happens if you start any other program that requires tty input in
>> the same conditions?
>
> KRunner & friends does not show a tty. `less some-file', for instance,
> detects that it does not have a tty and just terminates. Apparently it
> is the same case for other tools, although not for vim in text mode.
>
> Adding `emacs --daemon' to init scripts is problematic for the same
> reason. Usually, daemons are started by init scripts, which run
> unattended. Is it considered okay for a daemon to ask questions while
> starting?

It's a design decision that was considered the best thing to do after
a few discussions on this list.


>>>>> IMO, an acceptable "answer" on those cases is to act as if the user
>>>>> pressed C-g to abort the question, leave some notice on *Messages* and
>>>>> keep going with the initialization.
>>>>
>>>> How is that different than having a default answer of "no" (or "yes")?
>>>
>>> "yes" and "no" can express very different intentions depending on the
>>> question ("are you sure you want to launch the ICBM?" "start process for
>>> establishing world peace?") C-g means "cancel," which arguably can cause
>>> confussion too, but less so, I hope.
>>
>> What does C-g mean for `yes-or-no-p'?
>
> Abort?

Return value?

Re: Emacs making questions while starting in daemon mode

[Óscar Fuentes]

Dan Nicolaescu <dann@gnu.org> writes:

>>> More precisely is to prevent the user from shooting himself in the foot.
>>
>> In this case, the user did nothing stupid. It is emacs' fault if some
>> package asks the user about something on circunstances where it is not
>> appropiate.
>
> The user did, it added something to his emacs that asks a question
> during startup.  The user should test emacs --daemon in a terminal
> before using it without a terminal.

It is not so simple. Consider ido-mode, for instance. You can add
ido-mode to your .emacs, test the daemon and see it working without
problems. Then, after some time emacs --daemon starts asking for a
password on startup. This is because you visited some buffer with
tramp/ssh, exited emacs (which means that ido-mode saves a list of
visited files) and when you restarted emacs, on startup ido-mode checked
the existence of the files you visited on the previous session, which
triggers tramp and asks for a password.

The bug report that motivated this thread arised when I moved a
versioned file to a directory and created a symlink to it on the
original directory.

This examples shows that the user can not rely on emacs --daemon
starting without questions, as apparently trivial actions can trigger
the problem anytime.

>>> What does C-g mean for `yes-or-no-p'?
>>
>> Abort?
>
> Return value?

C-g signal an error, which means that wathever is waiting for a return
value is aborted as well.

The final outcome with that approach is that the user sees an emacs that
did not complete the initialization, which is similar to the effects of
a faulty .emacs.

Re: Emacs making questions while starting in daemon mode

[Chad Brown]

On Jul 6, 2010, at 8:55 AM, Óscar Fuentes wrote:

> C-g signal an error, which means that wathever is waiting for a return
> value is aborted as well.
> 
> The final outcome with that approach is that the user sees an emacs that
> did not complete the initialization, which is similar to the effects of
> a faulty .emacs.

There are probably roughly as many annoying corner cases in the `bull ahead' strategy as there are in the `wait for input' strategy.  Rather than trying to weigh and balance exceptional cases, why don't we look into having emacs open a window to ask those questions (or at least ask about bull-ahead-or-hang) if it's run --daemon?  The existing code used if you try to quit emacs using a mouse and the menu-bar (assuming a customized confirm-kill-emacs) ought to be a usable guide.

I don't (at the moment) have good access to a system where emacs --daemon is a useful option, which is my excuse for offering ideas rather than code.  My apologies.

*Chad

Re: Emacs making questions while starting in daemon mode

[Stephen J. Turnbull]

Chad Brown writes:

 > There are probably roughly as many annoying corner cases in the
 > `bull ahead' strategy as there are in the `wait for input'
 > strategy.  Rather than trying to weigh and balance exceptional
 > cases, why don't we look into having emacs open a window to ask
 > those questions (or at least ask about bull-ahead-or-hang) if it's
 > run --daemon?

Because in many cases you won't find.  At least one of the systems I
run Emacsen on is headless.

I think Dan is right -- this is basically a user error.  And I think
that Óscar is also right ... anything that tries to access a
non-existent console should signal an error.  As Óscar says, this will
terminate the load of .emacs, and this is justified because it is a
user error -- it's not Emacs's responsibility.

There will be no return value; unless .emacs does condition-case
itself, the signal should result in a throw to top level.  The error
message(s) can be collected in a special buffer for that purpose, or
in " *Message-Log*", which will be popped up along with *scratch* when
the first console and window are opened by the user.

Re: Emacs making questions while starting in daemon mode

[Dan Nicolaescu]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Chad Brown writes:
>
>  > There are probably roughly as many annoying corner cases in the
>  > `bull ahead' strategy as there are in the `wait for input'
>  > strategy.  Rather than trying to weigh and balance exceptional
>  > cases, why don't we look into having emacs open a window to ask
>  > those questions (or at least ask about bull-ahead-or-hang) if it's
>  > run --daemon?
>
> Because in many cases you won't find.  At least one of the systems I
> run Emacsen on is headless.
>
> I think Dan is right -- this is basically a user error.  And I think
> that Óscar is also right ... anything that tries to access a
> non-existent console should signal an error.

That happens already:

$ cat .emacs
(yes-or-no-p "Question?")
$ emacs --daemon < /dev/null
 emacs --daemon < /dev/null
("emacs")
Question?(yes or no) Warning (initialization): An error occurred while loading `/home/dann/.emacs':

error: Error reading from stdin

To ensure normal operation, you should investigate and remove the
cause of the error in your initialization file.  Start Emacs with
the `--debug-init' option to view a complete error backtrace.
Starting Emacs daemon.

I suspect that the tool he uses to start emacs provides some bogus
stdin and emacs dutifully waits for input from there.

Re: Emacs making questions while starting in daemon mode

[Jan Djärv]

Dan Nicolaescu skrev 2010-07-06 19.29:
>
> That happens already:
>
> $ cat .emacs
> (yes-or-no-p "Question?")
> $ emacs --daemon<  /dev/null
>   emacs --daemon<  /dev/null
> ("emacs")
> Question?(yes or no) Warning (initialization): An error occurred while loading `/home/dann/.emacs':
>
> error: Error reading from stdin
>
> To ensure normal operation, you should investigate and remove the
> cause of the error in your initialization file.  Start Emacs with
> the `--debug-init' option to view a complete error backtrace.
> Starting Emacs daemon.
>
> I suspect that the tool he uses to start emacs provides some bogus
> stdin and emacs dutifully waits for input from there.

So emacs --daemon should behave more like a "proper" daemon, i.e. close 
stdin/out/err and setsid and the whole works?

	Jan D.

Re: Emacs making questions while starting in daemon mode

[Dan Nicolaescu]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Dan Nicolaescu skrev 2010-07-06 19.29:
>>
>> That happens already:
>>
>> $ cat .emacs
>> (yes-or-no-p "Question?")
>> $ emacs --daemon<  /dev/null
>>   emacs --daemon<  /dev/null
>> ("emacs")
>> Question?(yes or no) Warning (initialization): An error occurred while loading `/home/dann/.emacs':
>>
>> error: Error reading from stdin
>>
>> To ensure normal operation, you should investigate and remove the
>> cause of the error in your initialization file.  Start Emacs with
>> the `--debug-init' option to view a complete error backtrace.
>> Starting Emacs daemon.
>>
>> I suspect that the tool he uses to start emacs provides some bogus
>> stdin and emacs dutifully waits for input from there.
>
> So emacs --daemon should behave more like a "proper" daemon,
> i.e. close stdin/out/err and setsid and the whole works?

It does that, but only after processing .emacs.
The original implementation was closing all descriptors from the
start, it was changed to the current one after some discussion on the list.

Re: Emacs making questions while starting in daemon mode

[Chad Brown]

On Jul 6, 2010, at 9:53 AM, Stephen J. Turnbull wrote:

> Chad Brown writes:
> 
>> There are probably roughly as many annoying corner cases in the
>> `bull ahead' strategy as there are in the `wait for input'
>> strategy.  Rather than trying to weigh and balance exceptional
>> cases, why don't we look into having emacs open a window to ask
>> those questions (or at least ask about bull-ahead-or-hang) if it's
>> run --daemon?
> 
> Because in many cases you won't find.  At least one of the systems I
> run Emacsen on is headless.

I think that I might have been unclear -- what I'm suggesting is just that we could try using the window system to ask questions (or post errors) in situations where using a tty is expected to fail.  Chong Yidong's observation that we might hit the questions/errors before we're set up to use the window system is a telling blow, though -- there are probably cases where using the window system would still help, but it's clearly just a marginal improvement, since the opposite cases are probably at least as common.

Ah, well.  I suppose the answer of `fix KRunner to stop shooting itself in the foot' is still a viable answer.

*Chad

Re: Emacs making questions while starting in daemon mode

[Jan Djärv]

Chad Brown skrev 2010-07-06 18.27:
> On Jul 6, 2010, at 8:55 AM, Óscar Fuentes wrote:
>
>> C-g signal an error, which means that wathever is waiting for a return
>> value is aborted as well.
>>
>> The final outcome with that approach is that the user sees an emacs that
>> did not complete the initialization, which is similar to the effects of a
>> faulty .emacs.
>
> There are probably roughly as many annoying corner cases in the `bull
> ahead' strategy as there are in the `wait for input' strategy.  Rather than
> trying to weigh and balance exceptional cases, why don't we look into
> having emacs open a window to ask those questions (or at least ask about
> bull-ahead-or-hang) if it's run --daemon?  The existing code used if you
> try to quit emacs using a mouse and the menu-bar (assuming a customized
> confirm-kill-emacs) ought to be a usable guide.

You can start emacs --daemon in a non-GUI environment and then connect to it 
from a GUI or non-GUI environment.  So opening a window may not be possible 
for the --daemon instance.

It may be hard, but if emacs is started with --daemon, it could perhaps delay 
running .emacs until the first connection to it is made?  That way 
errors/questions can be shown to the first client.

	Jan D.

Re: Emacs making questions while starting in daemon mode

[Chong Yidong]

Jan Djärv <jan.h.d@swipnet.se> writes:

> It may be hard, but if emacs is started with --daemon, it could
> perhaps delay running .emacs until the first connection to it is made?
> That way errors/questions can be shown to the first client.

The init file may contain customizations that affect how connections are
made, such as `server-use-tcp', etc.

Re: Emacs making questions while starting in daemon mode

[Jan Djärv]

Chong Yidong skrev 2010-07-06 19.26:
> Jan Djärv<jan.h.d@swipnet.se>  writes:
>
>> It may be hard, but if emacs is started with --daemon, it could
>> perhaps delay running .emacs until the first connection to it is made?
>> That way errors/questions can be shown to the first client.
>
> The init file may contain customizations that affect how connections are
> made, such as `server-use-tcp', etc.

Didn't think of that.

	Jan D.

Re: Emacs making questions while starting in daemon mode

[Dan Nicolaescu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Dan Nicolaescu <dann@gnu.org> writes:
>
>>>> More precisely is to prevent the user from shooting himself in the foot.
>>>
>>> In this case, the user did nothing stupid. It is emacs' fault if some
>>> package asks the user about something on circunstances where it is not
>>> appropiate.
>>
>> The user did, it added something to his emacs that asks a question
>> during startup.  The user should test emacs --daemon in a terminal
>> before using it without a terminal.
>
> It is not so simple. Consider ido-mode, for instance. You can add
> ido-mode to your .emacs, test the daemon and see it working without
> problems. Then, after some time emacs --daemon starts asking for a
> password on startup. This is because you visited some buffer with
> tramp/ssh, exited emacs (which means that ido-mode saves a list of
> visited files) and when you restarted emacs, on startup ido-mode checked
> the existence of the files you visited on the previous session, which
> triggers tramp and asks for a password.

You might want to make an argument for changing what tramp/ido-mode do
in this case.

> The bug report that motivated this thread arised when I moved a
> versioned file to a directory and created a symlink to it on the
> original directory.
>
> This examples shows that the user can not rely on emacs --daemon
> starting without questions, as apparently trivial actions can trigger
> the problem anytime.
>
>>>> What does C-g mean for `yes-or-no-p'?
>>>
>>> Abort?
>>
>> Return value?
>
> C-g signal an error, which means that wathever is waiting for a return
> value is aborted as well.

Why don't you write some code using yes-or-no-p, you might realize
that abort can be just as dangerous as using yes or no as a default.

That's one of the reasons for the current design: if input is
required, there's no way we can provide the correct one by default,
that's why we try to interact with the user.

> The final outcome with that approach is that the user sees an emacs that
> did not complete the initialization, which is similar to the effects of
> a faulty .emacs.

That's was considered, and it was deemed preferable to interact with the user.

Re: Emacs making questions while starting in daemon mode

[Óscar Fuentes]

Óscar Fuentes <ofv@wanadoo.es> writes:

> IMO, an acceptable "answer" on those cases is to act as if the user
> pressed C-g to abort the question, leave some notice on *Messages* and
> keep going with the initialization.
>
> Is there a predicate that tells if emacs is initializing?

Nevermind, after-init-time provides that info.

It doesn't sound right to limit the time where questions are disregarded
to initialization time, though. Something like this pseudocode seems
more correct:

(when (and (daemonp) (no frames) (no console))
      (message "aborting question %s" question-text)
      (signal 'quit nil))

Does that look like an improvement over the current behavior?