Re: [PATCH v4 5/5] notmuch-emacs-mua: do not create a frame by default with --client
On Sat, Aug 15 2015, Jani Nikula j...@nikula.org wrote:
Make the default behaviour for --client the same as emacsclient
default: do not create a new frame. Add a new option --create-frame,
passing the same option to emacsclient to create a frame.
---
v2: fix killing frame with --create-frame
v3: fix --create-frame w/o --client parameter check
v4: fix kill terminal logic, document behaviour with daemon mode
---
doc/man1/notmuch-emacs-mua.rst | 6 ++
notmuch-emacs-mua | 14 ++
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/doc/man1/notmuch-emacs-mua.rst b/doc/man1/notmuch-emacs-mua.rst
index 89a2fead17b1..c3689eb82c8a 100644
--- a/doc/man1/notmuch-emacs-mua.rst
+++ b/doc/man1/notmuch-emacs-mua.rst
@@ -45,6 +45,12 @@ Supported options for **notmuch-emacs-mua** include
Automatically start Emacs in daemon mode, if the Emacs server
is not running. Applicable with ``--client``.
+``--create-frame``
+Create a new frame instead of trying to use the current Emacs
+frame. Applicable with ``--client``. This will be required
+when Emacs is running (or automatically started with
+``--auto-daemon``) in daemon mode.
+
``--print``
Output the resulting elisp to stdout instead of evaluating it.
diff --git a/notmuch-emacs-mua b/notmuch-emacs-mua
index ac03a4a60d56..b51d8d0e2c5b 100755
--- a/notmuch-emacs-mua
+++ b/notmuch-emacs-mua
@@ -37,11 +37,10 @@ PRINT_ONLY=
NO_WINDOW=
USE_EMACSCLIENT=
AUTO_DAEMON=
-CREATE_FRAME=-c
+CREATE_FRAME=
# The crux of it all: construct an elisp progn and eval it.
ELISP=(prog1 'done (require 'notmuch) (notmuch-mua-new-mail)
-ELISP=${ELISP} (setq message-exit-actions (list
#'save-buffers-kill-terminal))
# Short options compatible with mutt(1).
while getopts :s:c:b:i:h opt; do
@@ -65,7 +64,7 @@ while getopts :s:c:b:i:h opt; do
opt=${opt%%=*}
;;
# Long options without arguments.
- --help|--print|--no-window-system|--client|--auto-daemon)
+
--help|--print|--no-window-system|--client|--auto-daemon|--create-frame)
;;
*)
echo $0: unknown long option ${opt}, or argument
mismatch. 2
@@ -103,7 +102,6 @@ while getopts :s:c:b:i:h opt; do
;;
--no-window-system)
NO_WINDOW=-nw
- CREATE_FRAME=
;;
--client)
USE_EMACSCLIENT=yes
@@ -111,6 +109,9 @@ while getopts :s:c:b:i:h opt; do
--auto-daemon)
AUTO_DAEMON=--alternate-editor=
;;
+ --create-frame)
+ CREATE_FRAME=-c
+ ;;
*)
# We should never end up here.
echo $0: internal error (option ${opt}). 2
This looks pretty good now; I player quite a bit with --client,
--create-frame and --auto-daemon
(with and without setting EMACSCLIENT='echo emacsclient')
Based on that I think this check should be added here (after option
parsing):
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
$ emacsclient --eval '(kill emacs) ;; but beware! '
$ emacsclient --alternate-editor= --eval '(find-file /etc/passwd)'
(side note: using this --alternate-editor= is pretty nifty way to get it done)
emacs --daemon is executed which loaded /etc/passwd but w/o ui
Note the difference in:
emacsclient --alternate-editor= /etc/passwd
now emacs --daemon is executed *and* ui where /etc/passwd is available is
provided!
otoh,
emacsclient --alternate-editor= -c [-nw] --eval '(find-file /etc/passwd)'
works fine, albeit a bit different than the one where /etc/passwd was given
as a simple filename argument.
comparative to ./notmuch-emacs-mua --client --create-frame --auto-daemon
@@ -128,6 +129,11 @@ for arg; do
ELISP=${ELISP} (message-goto-to) (insert \${arg}, \)
done
+# 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.
perhaps the above could be changed to just
if [ -n $CREATE_FRAME ]; then
ELISP=${ELISP} (setq message-exit-actions (list
how to make return follow hyperlink?
How do I make it so that hitting RET on a hyperlink follows it? Is there a setting analogous to org-return-follows-link? I often have links in incoming emails, and I'd like to be able to open them in my browser with one keystroke. Thanks! ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v2] devel/release-checks: added checking of copyright year in documentation
Check that copyright year will be current year in generated documentation.
Checking is done my matching that copyright line contains current year
as a substring which is good enough approximation in this context.
---
v2 of id:1438511187-11321-1-git-send-email-tomi.oll...@iki.fi, perhaps
addressing comments in id:87r3niwan6@maritornes.cs.unb.ca
devel/release-checks.sh | 15 +++
1 file changed, 15 insertions(+)
diff --git a/devel/release-checks.sh b/devel/release-checks.sh
index 8604a9f7d10b..5802942aa975 100755
--- a/devel/release-checks.sh
+++ b/devel/release-checks.sh
@@ -175,6 +175,21 @@ case $news_date in
append_emsg Date '$news_date' in NEWS file is not in format
(-mm-dd)
esac
+year=`exec date +%Y`
+echo -n Checking that copyright in documentation contains $year...
+# Read the value of variable `copyright' defined in 'doc/conf.py'.
+# As __file__ is not defined when python command is given from command line,
+# it is defined before contents of 'doc/conf.py' (which dereferences __file__)
+# is executed.
+copyrightline=`exec python -c with open('doc/conf.py') as cf: __file__ = '';
exec(cf.read()); print(copyright)`
+case $copyrightline in
+ *$year*)
+ echo Yes. ;;
+ *)
+ echo No.
+ append_emsg The copyright in doc/conf.py line '$copyrightline'
does not contain '$year'
+esac
+
if [ -n $emsgs ]
then
echo
--
2.0.0
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2/2] emacs: add function to resend message to new recipients
The new function notmuch-show-message-resend re-sends message to new recipients using #'message-resend. Recipients are read from minibuffer as a comma-separated string (with some keyboard support including tab completion). Final confirmation before sending is asked. --- Note that notmuch-show-message-resend is not (yet) bound to any keybindings in notmuch-show-mode-map (nor notmuch-tree-mode-map!). I remember that Emacs VM might have had 'b' bound to this functionality but I cannot be sure. A few weeks ago I looked gnus, rmail mh-e to figure out whether 'b' would have been bound to similar functionality there but I cannot find it... A future patch will be done when we've decide where to bind this. Also, I simplified keybindings in notmuch-address-from-minibuffer -- latest version used to bind ',' in both minibuffer-local-map and minibuffer-local-completion-map to do some magic. I'll send an RFC patch having that later. emacs/notmuch-address.el | 19 +++ emacs/notmuch-show.el| 8 2 files changed, 27 insertions(+) diff --git a/emacs/notmuch-address.el b/emacs/notmuch-address.el index 6c93b2a7a820..b08a78f2db46 100644 --- a/emacs/notmuch-address.el +++ b/emacs/notmuch-address.el @@ -119,4 +119,23 @@ (defun notmuch-address-locate-command (command) ;; +(defun notmuch-address-from-minibuffer (prompt) + (if (not (notmuch-address--message-insinuated)) + (read-string prompt) +(let ((rmap (copy-keymap minibuffer-local-map)) + (omap minibuffer-local-map)) + ;; Configure TAB to start completion when executing read-string. + ;; Original minibuffer keymap is restored just before calling + ;; notmuch-address-expand-name as it may also use minibuffer-local-map + ;; (completing-read probably does not but if something else is used there). + (define-key rmap \C-i (lambda () ;; TAB + (interactive) + (let ((enable-recursive-minibuffers t) +(minibuffer-local-map omap)) +(notmuch-address-expand-name + (let ((minibuffer-local-map rmap)) + (read-string prompt) + +;; + (provide 'notmuch-address) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 848ec2c870c4..62aa696224ca 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -1806,6 +1806,14 @@ (defun notmuch-show-forward-message (optional prompt-for-sender) (with-current-notmuch-show-message (notmuch-mua-new-forward-message prompt-for-sender))) +(defun notmuch-show-resend-message (addresses) + Resend the current message. + (interactive (list (notmuch-address-from-minibuffer Resend to: ))) + (when (yes-or-no-p (concat Confirm resend to addresses )) +(notmuch-show-view-raw-message) +(message-resend addresses) +(bury-buffer))) + (defun notmuch-show-next-message (optional pop-at-end) Show the next message. -- 2.0.0 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/2] emacs: add defsubst notmuch-address--message-insinuated
This inline function is currently used in notmuch-address-message-insinuate (to not enable address completion if it is already enabled). In some functions later this will be called to know whether address completion can be used there, too. --- Previous version of this 2-patch series is at id:1423229911-14784-1-git-send-email-...@guru.guru-group.fi emacs/notmuch-address.el | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/emacs/notmuch-address.el b/emacs/notmuch-address.el index fde3c1b2b861..6c93b2a7a820 100644 --- a/emacs/notmuch-address.el +++ b/emacs/notmuch-address.el @@ -54,8 +54,11 @@ (defvar notmuch-address-message-alist-member (defvar notmuch-address-history nil) +(defsubst notmuch-address--message-insinuated () + (memq notmuch-address-message-alist-member message-completion-alist)) + (defun notmuch-address-message-insinuate () - (unless (memq notmuch-address-message-alist-member message-completion-alist) + (unless (notmuch-address--message-insinuated) (setq message-completion-alist (push notmuch-address-message-alist-member message-completion-alist -- 2.0.0 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: muchsync files renames
Hi David, (Resending, because I forgot to Cc mailing list.) David Mazieres dm-list-email-notm...@scs.stanford.edu writes: 3. I run muchsync SERVER. 4. When it lasted much longer then initialization I canceled it by single SIGINT (^c). Interesting. I wish I knew why this was taking much longer than running it on the server, and whether the delay was caused by client activity or server activity. I think there was something happening on server side because with --noup it has been completed in few seconds. I don't suppose you'd be willing to make a copy of your mail database to repeat the experiment without any risk of messing up your real maildir? I would try it, but unfortunately I would have to make a bit more space for having second copy of my mail. I am testing muchsync on the same machine between different users home directories, so it already takes some space. I'll try the experiment some day this week, I hope. 5. I rerun muchsync SERVER and then it notified me that notmuch identified files names changes - more than 1000. Were the link changes on the client (sent) or the server (received) side? On the server side. That's why I am worried. I don't think that will change things. maildir.synchronized_flags will make things slower, but it shouldn't affect the SUMMARY numbers you see at the end of muchsync, other than maybe files moving from .../new to .../cur. But presumably most of your mail files were already in cur directories. So what would happen on my machine is that first client initialization took place. During this stage muchsync moved some files from new/ to cur/. Later running muchsync SERVER tried to reflect client changes on server by pushing renames requests to server. Is it what actually could happend? -- Amadeusz Żołnowski signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] cli/lib: remove support for GMime 2.4
David Bremner da...@tethera.net writes: It's becoming a maintenance burden to do anything things with the crypto glue code twice, once for 2.4 and once for 2.6. I don't have any 2.4 version available to test on my development machine anymore, so the 2.4 specific code paths are likely not very well tested. I have pushed this change, along with a minimal note in NEWS d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
