On 2010-03-29, Nicolas Williams <nicolas.willi...@sun.com> wrote:
> I saw in the archives that this is a bit of an FAQ, and it seems that to
> this day there's not much of an answer, sadly.
>
> The best I could do was to create an index macro that pipes the current
> message to a script that then: a) pipes stdin to formail, b) saves the
> result in a tmp file, c) starts a new instance of mutt -f that_file. Or
> perhaps using -H. But that's clearly not quite what I want, nor what
> the various users who have asked for this want.
>
> Ideas:
>
> - Add a function like <pipe-message> but which instead of piping the
> message puts the message in a temp file and then allows for expansion
> of several parameters in the command line, including:
>
> %f (the address of the sender of the message)
> %r (the To: addresses of the message)
> %c (the Cc: addresses of the message)
> %a (the To: and Cc: addresses of the message)
> %l (the To: and Cc: addresses of the message that are lists)
> %R (the Reply-To: address of the message)
> %s (the Subject: of the message, with "Re: " prefixed if not %already)
> %F (the name of the file containing the message)
>
> - Same as above but also provide a Unix domain socket/door/whatever
> that mutt can listen on for commands from the external command. The
> purpose of this is to support connection sharing and avoid having to
> re-type IMAP/SMTP passwords. The main sub-command would be to send
> the message found in a given file, and also to mark a message in a
> folder as replied. The name of the rendezvous would be set in an
> environment variable and mutt would support using it. All
> send/save/*-hooks would be applied in the primary mutt.
>
> (This is not really needed when using SASL/GSSAPI, of course. It's
> primrarily useful when there are passwords to type.)
>
> Where would I start if I was to try to implement the first of the above?
I think you can do all of your first idea with a macro. The basic
idea is:
1. Set 'editor' to something like 'true';
2. Set 'postponed' to a tmp file;
3. Reply to the message (which will take you immediately to the
compose menu);
4. Postpone the reply;
5. Reset 'postponed';
4. Reset 'editor';
5. Execute a script as you did before to start mutt on that
postponed message.
The tricky part is, and has always been in these discussions, making
sure the 'replied' flag on the original message is set properly.
That seems to require the primary mutt to listen on some sort of
IPC mechanism for a command to set the 'replied' flag on the message
of a specified Message-ID as you have outlined in your second idea
above. Mutt currently checks things like the presence of new mail
upon user input or the expiry of a timer, so it seems that it could
check the IPC mechanism the same way.
I think the solution to the second problem may influence the
solution to the first, so it would be my suggestion to work on the
second problem first.
My first thought is to have the primary mutt create a pipe, launch a
child process whose stdout goes to the pipe, and periodically listen
for input from the pipe. The only expected input is some sort of
command to set the affected message's replied flag.
The child process could be a wrapper around an instance of "mutt
-H". If that mutt exits with a status of 0, the wrapper writes the
"set replied for this Message-ID" command to stdout and exits.
Otherwise, it just exits. Rather than a wrapper, of course, it
would be nice to just invoke mutt with a flag that tells it to do
all that.
Before launching the child process, the primary mutt would just need
to construct a reply with all the headers required by "-H" and save
it to a tmp file.
Those are just some ideas anyway. I'm glad you're looking into
this.
I don't know where in the code to suggest that you start. I usually
run cscope on the source code directory tree, then run "vim -c 'grep
some_likely_string *.[hc]'" where some_likely_string is something I
expect to find associated with the code I'm interested in, and start
browsing the code from there.
Regards,
Gary
