- What were your thoughts in terms of what the interface would look like
at the "repl" level? Just a new switch? Did you want to make it more
generic?
Yeah, just a switch, something like:
-calendar accept | tentative | decline | cancel
Is there a way to make that more generic?
Hrm. It just seems ... if you want to make that more generic, you'd want
to be able to pass switches down to the modules that generate the reply
content. I'm not sure what that would look like. Just thinking out
loud!
Here's an idea. pick allows --component to refer to an arbitrary header.
Maybe use two dashes to indicate a argument to a module?
mhshow/mhstore: no code changes, just add -text/calendar
entries to mhn.defaults. I have started playing with a format
file for display, and it looks like it'll work with what we
already have in the format engine. (Thank you for fmttest :-)
Glad you found it useful!
I haven't thought much about composing a new event request,
mainly because I wouldn't use it.
I'm with you there as well. Might be nice to have that capability, but
definitely don't need it now.
Now, replying to a message is kind of an unholy combination of
displaying and composition.
Is it? I don't view reply as incorporating display, other
than to make sure I'm replying to the message I think I'm
replying to. When I reply to a message that's has pdf or
html or whatever attachments, I don't read them again.
I'm just thinking of the general case. In a reply, you generally
want to "process" the original content somehow and incorporate it in
your outgoing message. Okay, fine, for things that are traditional
"attachments" you mostly don't care, but you normally want to take text
and prepare it for quoting, and now we have a case of wanting to process
a calendar request and send it in the reply. I'm sure there are other
things that would be useful as well.
It might be nice to be able to hit a key when viewing a
calendar request to accept, deny, or tentative it, but I don't
think that's a job for nmh. Front ends certainly could. Or
are you referring to something else?
I was just commenting on what other MUAs do. I'm with you; this sounds
more like a job for the reply step.
The question is ... what do we do? A general thought is that we
shouldn't have nmh commands output mhbuild directives into drafts. That
just seems like the wrong approach; it gives special meaning to the
message body and it requires the user to know to run the "mime" command
at the WhatNow? prompt.
Doesn't nmh 1.6 run "mime" if the user didn't?
Not exactly. It runs mhbuild -auto; that doesn't process mhbuild directives
by default (it also silently exits if the draft has MIME headers).
So it occurs to me that maybe we should have some mechanism to allow
repl to insert generic headers into the reply draft that mhbuild could
later process.
What would it need to do that annotate() doesn't already?
It would use the annotate() function, certainly. I was just more thinking
of how to indicate from inside of something like mhical that we need to
add a special header.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers