On Mon, Sep 28 2015, David Bremner <da...@tethera.net> wrote: > Tomi Ollila <tomi.oll...@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
Without --client --auto-daemon is no-op (as it is no-op in case emacs server is already running). I am (only) concerned about user experience when one runs --client --auto-daemon and user gets nothing (i.e. emacs server is running in the background w/o any clients connected to it. We could make --auto-daemon imply --create-frame, but then ./notmuch-emacs-mua --auto-daemon (i.e. w/o --client) starts new mail compose window to separate frame (even though user did not request it w/ --create-frame) (actually I already did the 'imply' option (easy, one line in script, another in namual), just that testing it gave this thought... ... therefore I'd rather make ./notmuch-emacs-mua --auto-daemon spit an error and exit -- but I can be convinced otherwise :) Tomi _______________________________________________ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch