Tomi Ollila <tomi.ollila@iki.fi> writes:


> if [ -n "$AUTO_DAEMON" -a -z "$CREATE_FRAME" ]; then
>     echo "$0: --auto-daemon is only applicable with --create-frame." >&2
>     exit 1       
> fi
>
> without this one may execute ./notmuch-emacs-mua --client --auto-daemon
> which yields starting emacs in daemon mode (in this example it is expected
> emacs is not running; otherwise --auto-daemon has no use in this example)
> -- but no ui to that newly-running emacs is provided. Similar behaviour
> can be observed by the following
>

I think what you propose is fine for a followup patch; note that the
scenario you worry about also needs --client to be a problem. Apparently
nothing is uncontroversial here, but if auto-daemon only works with
create frame, then perhaps the followup would be to have auto-daemon
imply create-frame

>>  
>> +# Kill the terminal/frame if we're creating one.
>> +if [ -z "$USE_EMACSCLIENT" -o -n "$CREATE_FRAME" -o -n "$NO_WINDOW" ]; then
>> +    ELISP="${ELISP} (setq message-exit-actions (list #'save-buffers-kill-terminal))"
>> +fi
>
> I am not very happy that message-exit-actions was added to $ELISP when
> not using emacsclient; when emacs is started its sole (initial) purpose is
> to serve mail sending (and not lending a frame in some other emacs) -- in
> this case it would be nice to be able to retrieve the sent mail buffer.

I'm somewhat less sympathetic here. AIUI, the goal of notmuch-emacs-mua
is to provide a drop in tool to replace mutt for sending mail in the
shell or from other programs. In this case, I think the most common
expectation is to terminate after sending mail (e.g. to return use of
the shell to the user, or allow the spawning program to continue).
However, it seems like this would be relatively easy to set up some
customization in notmuch-message-mode so that it could check if running
from the cli, and then either kill-or-not emacs depending on some
variable. So I think I'd like to keep the current behaviour as default,
and make it customizable at the emacs level.