[PATCH 1/2] emacs: add defsubst notmuch-address--message-insinuated

[PATCH 1/2] emacs: add defsubst notmuch-address--message-insinuated

[Tomi Ollila]

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-too@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

[PATCH 2/2] emacs: add function to resend message to new recipients

[Tomi Ollila]

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

Re: [PATCH 2/2] emacs: add function to resend message to new recipients

[David Bremner]

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

> 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).
>

I couldn't get the tab completion to work, at least if I go

  M-x notmuch-show-resend-message

nor when evaluating (notmuch-address-from-minibuffer "foo:")

Do I need to bind a key to test this?

> 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...

mutt uses 'b'. AFAICT, gnus uses some sequence ending in b to resend
bounced messages (i.e. from mailer-daemon).

quoting the manual:

S D b

    If you have sent a mail, but the mail was bounced back to you for
    some reason (wrong address, transient failure), you can use this
    command to resend that bounced mail
    (gnus-summary-resend-bounced-mail). [...]
    
S D r

    Not to be confused with the previous command,
    gnus-summary-resend-message will prompt you for an address to send
    the current message off to, and then send it to that place. [...]

Be that as it may, we already use 'r' for reply, and I'm not sure we
want to go (more) in the way of multi-letter sequences.

Re: [PATCH 2/2] emacs: add function to resend message to new recipients

[Tomi Ollila]

On Sun, Aug 30 2015, David Bremner <david@tethera.net> wrote:

> Tomi Ollila <tomi.ollila@iki.fi> writes:
>
>> 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).
>>
>
> I couldn't get the tab completion to work, at least if I go
>
>   M-x notmuch-show-resend-message
>
> nor when evaluating (notmuch-address-from-minibuffer "foo:")
>
> Do I need to bind a key to test this?

Nope. both of the above should work -- and worked for me just now
(this is how I tested just now:

  emacs -q -L $PWD/emacs -l emacs/notmuch.el -f notmuch --eval '(progn (setq notmuch-address-command "nottoomuch-addresses.sh") (notmuch-address-message-insinuate))'

)

>> 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...
>
> mutt uses 'b'. AFAICT, gnus uses some sequence ending in b to resend
> bounced messages (i.e. from mailer-daemon).
>
> quoting the manual:
>
> S D b
>
>     If you have sent a mail, but the mail was bounced back to you for
>     some reason (wrong address, transient failure), you can use this
>     command to resend that bounced mail
>     (gnus-summary-resend-bounced-mail). [...]
>     
> S D r
>
>     Not to be confused with the previous command,
>     gnus-summary-resend-message will prompt you for an address to send
>     the current message off to, and then send it to that place. [...]
>
> Be that as it may, we already use 'r' for reply, and I'm not sure we
> want to go (more) in the way of multi-letter sequences.

I agree that we don't want to to multi-letter sequences (early). I
personally would be fine w/ 'b'...

Tomi

Re: [PATCH 2/2] emacs: add function to resend message to new recipients

[David Bremner]

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

>
>   emacs -q -L $PWD/emacs -l emacs/notmuch.el -f notmuch --eval '(progn (setq notmuch-address-command "nottoomuch-addresses.sh") (notmuch-address-message-insinuate))'
>
Ah, I missed notmuch-address-message-insinuate; it does work if I run
that. I wonder if this can be simplified at all now that
notmuch-message-mode exists. In general I'm leery of running code when
we load notmuch*.el, as this has a history of causing problems for
people using notmuch e.g. as a search tool for gnus.

The completion interface takes a little getting used to, but it's
definitely usable. And of course much better than what we have now ;).

One thing I noticed which I _think_ is a bug, is that after calling
notmuch-show-resend-message, notmuch-view-raw-message doesn't work
anymore, complaining about a read-only buffer.

d

Re: [PATCH 2/2] emacs: add function to resend message to new recipients

[Tomi Ollila]

On Mon, Aug 31 2015, David Bremner <david@tethera.net> wrote:

> Tomi Ollila <tomi.ollila@iki.fi> writes:
>
>>
>>   emacs -q -L $PWD/emacs -l emacs/notmuch.el -f notmuch --eval '(progn (setq notmuch-address-command "nottoomuch-addresses.sh") (notmuch-address-message-insinuate))'
>>

> Ah, I missed notmuch-address-message-insinuate; it does work if I run
> that. I wonder if this can be simplified at all now that
> notmuch-message-mode exists. In general I'm leery of running code when we
> load notmuch*.el, as this has a history of causing problems for people
> using notmuch e.g. as a search tool for gnus.

Currently as both setting notmuch-address-command and
notmuch-address-message-insinunate us required I would not attempt to do any
"magic" there. Whenever we get built-in address completion (i.e built-in
is used when notmuch-address-command is kept nil we could consider to add
some defcustom which can be used to activate address completion -- but 
as there are these *-insinunate -commands in many elisp packages it is
probably best to investigate whether this really can be "automated".
Perhaps some lazy initialization could be in place, then.

> The completion interface takes a little getting used to, but it's
> definitely usable. And of course much better than what we have now ;).
>
> One thing I noticed which I _think_ is a bug, is that after calling
> notmuch-show-resend-message, notmuch-view-raw-message doesn't work
> anymore, complaining about a read-only buffer.

That is interesting in a sense that I could not reproduce. I think I know
exactly why this happens: notmuch-view-raw-message creates read-only buffer
which is not removed after message is resent: re-running
notmuch-view-raw-message on same message will `get-buffer-create' with
same name and pick the old read-only buffer; inserting data to that buffer
fails -- just that in my tests (V C-x b RET V) I could not get the same
outcome.

The simplest change is to change (bury-buffer) with (kill-buffer). The raw
message buffer that was used to send should not be interesting; more
interesting is the current (same) message in notmuch-show buffer -- and 'V'
can be used to re-view the raw message. 
What could be added is printing the message id of the message resent to
*Messages* buffer. This way re-sender can verify what was resent if being
unsure. Just that in the case I've used this I have not looked back...

So, probably I make applicable RFC patch of this feature...


>
> d

Tomi

Re: [PATCH 2/2] emacs: add function to resend message to new recipients

[David Bremner]

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

> That is interesting in a sense that I could not reproduce. I think I know
> exactly why this happens: notmuch-view-raw-message creates read-only buffer
> which is not removed after message is resent: re-running
> notmuch-view-raw-message on same message will `get-buffer-create' with
> same name and pick the old read-only buffer; inserting data to that buffer
> fails -- just that in my tests (V C-x b RET V) I could not get the same
> outcome.

This test actually reproduces the problem for me. Maybe it's emacs
version specific? I mainly 24.5.1, but I can't duplicate the problem in
emacs23.

d

Re: [PATCH 1/2] emacs: add defsubst notmuch-address--message-insinuated

[David Bremner]

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

> +(defsubst notmuch-address--message-insinuated ()
> +  (memq notmuch-address-message-alist-member message-completion-alist))
> +

Is there some advantage to defsubst other than (maybe?) performance?  It
just seems like one more construct for people to get up to speed with
the codebase.

d

Re: [PATCH 1/2] emacs: add defsubst notmuch-address--message-insinuated

[Tomi Ollila]

On Sun, Aug 30 2015, David Bremner <david@tethera.net> wrote:

> Tomi Ollila <tomi.ollila@iki.fi> writes:
>
>> +(defsubst notmuch-address--message-insinuated ()
>> +  (memq notmuch-address-message-alist-member message-completion-alist))
>> +
>
> Is there some advantage to defsubst other than (maybe?) performance?  It
> just seems like one more construct for people to get up to speed with
> the codebase.

No advantage. The reason for defsubst may originally be that I did it for
least execution chance -- and iirc I was reading some (gnus?) code that
had quite a few defsubsts which infected my coding. Now that I checked
there is no (other) defsubsts code in notmuch-emacs... so that can be
just be changed to `defun' to be consistent in that sense.

>
> d

Tomi