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

> Tomi Ollila <tomi.oll...@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

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

notmuch mailing list

Reply via email to