emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs making questions while starting in daemon mode


From: Dan Nicolaescu
Subject: Re: Emacs making questions while starting in daemon mode
Date: Tue, 06 Jul 2010 12:44:59 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)

Óscar Fuentes <address@hidden> writes:

> Dan Nicolaescu <address@hidden> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]