Re: [Nmh-workers] iCalendar support

[David Levine]

Ken wrote:

> Some meta-thoughts:
>
> - 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?

> - What were you thinking in terms of implementation details?  Yes, I
>   understand about the mhical utility, but I was thinking of what
>   you'd need in all of the other tools to make it work.

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

I haven't thought much about composing a new event request,
mainly because I wouldn't use it.  I need to use a calendar
app to check schedules, anyway.  The calendar request itself
would be simple, but getting the start/stop times and
attendees from the user wouldn't be unless we just let the
user do it in their editor the way they do for any message.
We could provide a calendar event request template if
there's interest in that.

> - Are you sure you want to have a mhbuild directive in the reply?

That's a good question.  I started with that as a proof of
concept and something that everyone here could understand.
Also, I'd like to support reply to an calendar request without
editing.  None of this rules out the header approach, and I'm
willing to pursue it.

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

> We've never really figured out how to bridge the gap here very well.
> To be fair, nobody else seems to handle this really well either; a
> few things are special-cased in MUAs (like calendar requests,
> although in my experience what happens there is that you have to do
> something at message display time)

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?

> but mostly they don't deal with
> non-text parts for replies.  Maybe we should do better!
>
> 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?

> The more I use it, the more I think the attach command's general
> interface is more reasonable; headers already have special meaning,
> we have a specialized tool to manipulate them (anno) and it seems to
> work out well in practice.

I buy that.

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

David