On Mon, Mar 29, 2010 at 08:05:26PM -0700, Gary Johnson wrote:
> I think you can do all of your first idea with a macro. The basic
> idea is:
It won't do:
> [...]
> 5. Execute a script as you did before to start mutt on that
> postponed message.
First, this is a bad UI since I'll have to hit 'r' (or 'g', or ...) to
reply to the message in the spawned instance of mutt. This might be
fixable using the -e CLI option.
Second, and this is worse, is:
> The tricky part is, and has always been in these discussions, making
> sure the 'replied' flag on the original message is set properly.
Exactly.
> 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.
If mutt had CLI options naming a specific message in a specific folder
to immediately reply to then the replied flag could get set correctly
and then the original instance of mutt could eventually sync up.
But that has the problem that there's no connection sharing and no
password caching. The latter is yet more bad UI.
This problem screams for a specific solution rather than trying to bend
existing facilities of mutt. The archives are littered with incomplete
and unsatisfying solutions. Yours sounds better than all the previous
ones, and still, it's not satisfying.
> 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.
I'm thinking along the same lines. But I want this to be simple.
I'm thinking of doing something with Unix domain sockets (to be
portable, else I'd use Solaris doors :) like so:
- one main socket
- spawned instances connect to the parent's main socket and request any
of:
- another socket on which to talk SMTP/SUBMIT or IMAP to some server
In both cases the parent would hand back to the child a pipe which
the parent would proxy to the real server. The parent would do
all TLS and SASL work. In the case of IMAP the parent could share
a single connection with its children, making sure to remap the
IMAP request XIDs to avoid conflicts (or perhaps the parent could
hand each child an XID namespace for itself). (IIRC IMAP requests
and replies have an XID picked by the client.)
- tell the parent to sync its view of some message or folder
- other commands?
> 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.
Yes. But I want a more complete solution.
> 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.
Unfortunately I'm very busy. I may not get to this any time soon. But
I may start by reading the code. Cscope is one of my favorite tools.
Thanks,
Nico
--
